우선 저는 마스터 브랜치에서 무작위로 진화하는 개발 환경에 있던 개발자입니다.
이것이 매우 잘못된 것임을 깨닫고 분기 관리 및 커밋 규칙을 다음과 같이 요약했습니다.
https://www.notion.so/gwo0o/Git-Branch-Rule-Commit-Naming-Rule-91ec49ed82ad4eafa5750e36d10f61a3
Git 분기 규칙/커밋 명명 규칙
분기 규칙.
www.notion.so
내가 중요하게 생각한 것은 분기 분류와 버전 설명이었습니다.
결국 지점 관리는 협업의 효율성을 높이고 업무 환경을 복잡하게 만들지 않아야 합니다.
따라서 리팩터링, 개발브랜치 등 다양한 분류가 이루어지지 않았다.
개발 – 기능
수정 – 수정 / 핫픽스
배포 – 릴리스
꼭 필요하다고 생각되는 세 가지만 부서에 가져 왔습니다.
다음 단계는 버전이지만 각 버전마다 무엇을 개발하고 무엇을 변경해야 하는지는 명시되어 있지 않습니다. 그러다가 각 버전에서 누가 무엇을 개발했는지에 대한 명확한 기준과 각 버전에 대한 관리가 있어야 한다고 생각했습니다.
그래서 각 브런치의 어떤 버전이 작업되고 있는지 표시하여 여러분과 다른 사람들이 어떤 부분을 작업했는지 알 수 있도록 정리했습니다.
– 물론 해당 규정이 완벽한 것은 아니며, 작업환경에 적합한 규정을 재정의할 필요가 있다.
