Git Branch Naming Convention
The best practices of the Git branch naming convention
Mondrian AI는 기본적으로 git-flow를 따른다.
- 브랜치의 수명은 최대한 짧게 가져가는 것이 좋고, 기능 단위로 개발하는 것이 좋다. 긴 브랜치 수명은 더 많은 잠재적 충돌 위험성을 내포한다.
- 브랜치에서 만든 코드의 결과물이 좋지 않을 경우 / 쓸모없어질 경우, 브랜치를 빠르게 삭제하는 것을 추천한다.
Branch naming rule
혼자 하는 경우에는 상관없지만, 협업을 하는 경우에는 네이밍 컨벤션이 상당히 중요하다. Mondrian AI는 다음과 같은 규칙으로 브랜치를 관리한다.
| name | description |
|---|---|
| feature/<feature_name> | 어떤 새로운 기능이 추가되어야 할 때 사용되는 branch이다. 개발이 완료되면, parent인 develop branch로 merge된다. |
| develop | develop branch는 product로 release를 할 준비가 된 가장 안정적인 branch라고 보면 된다.(즉, master로 merge하기 전) 개발된 모든 feature가 develope에 merge된다. |
| release | develop branch에서 어느 정도 feature들을 merge하고 이 쯤에서 release 해야겠다 싶을 때, 생성하는 branch이다. 당연히 develop branch에서 release branch로 merge하고, release가 완료 되면, 다음 release cycle을 진행한다. |
| release/alpha | alpha 테스트를 위한 branch이다. |
| release/beta | beta 테스트를 위한 branch이다. |
| hotfix/<hotfix_name> | release된 product에서 발생한 버그같은 것을 수정해야 할 때 사용되는 branch이다. 수정이 완료된 후에는 수정사항을 반영하기 위해 master와 develop branch에 모두 merge된다. |
| master | 가장 core가 되는 branch는 master와 develop이다. 그 중 master는 product로 release하는 branch이다. 모든 변경사항이 결국은 master로 merge되어야 한다. |
- 브랜치 이름은 케밥케이스(kebab-case)로 진행한다.
- Git Flow를 기반으로 하여 약간의 변형을 주고 있다.
- 원격 저장소에 push는 오늘 개발한 브랜치에 대해 하루에 최소 한 번씩 진행한다. 개발한 내역이 없다면 상관 없지만, 적어도 오늘 한 작업을 다른 사람들에게 공유하는 것이 좋다.
- 기존 Git flow의 feature 브랜치는 개발자의 저장소에서만 존재하고, 원격저장소에는 등록되지 않는다. 하지만 Bitbucket의 경우, Jira로 먼저 브랜치를 만들고 그 브랜치로 체크아웃 해서 개발하는 방식을 채택한다. Mondrian AI은 Bitbucket의 방식을 채택하며, 개발이 끝난 브랜치는 merge시 삭제한다.
feature/YEN-123
// TODO: Git Tag 가이드