Git 브랜치 전략에 대하여

회사가 작다보니 정해진 Git 브랜치 전략이 없었는데 여유가 좀 생긴 시기에 브랜치 전략을 정해보자는 이야기가 나왔다. 나도 이런 협업 규칙들이나 컨벤션에 관심이 많아서 이 기회에 찾아본 것들을 나름대로 정리해보려고 한다.

Git Flow

브랜치 네이밍 규칙

• master: 제품으로 출시될 수 있는 브랜치
• feature: 기능을 개발하는 브랜치 featrue/{구현기능명} (ex. feature/login)
• develop: 다음 출시 버전을 개발하는 브랜치
• release: 이번 출시 버전을 준비하는 브랜치
• hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

브랜치 관리 규칙

• feature: feature 브랜치는 기능의 구현을 담당한다. feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지된다. 머지된 후에는 해당 브랜치가 삭제된다.
• develop: develop 브랜치는 개발을 진행할 때 중심 브랜치다. 하나의 feature 브랜치는 기능 개발이 완료된 후 develop 브랜치에 머지된다. develop 브랜치는 배포할 수준의 기능이 갖춰지면 release 브랜치로 머지된다.
• release: release 브랜치는 develop 브랜치에서 개발이 완료된 사항을 검토하는 브랜치다. 충분한 테스트를 통해 버그를 검사하고 수정해 배포할 준비가 완전히 되었다고 판단되면 master로 머지해 배포한다.
• hotfix: hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치다. release 브랜치를 거쳐 버그 검사를 했지만 예상치 못하게 배포 후 발견된 버그들에 대해서 수정한다.
• master: master 브랜치는 최종적으로 배포되는 가장 중심의 브랜치다.

Github Flow

Github Flow는 Git Flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략이다. Github Flow는 master 브랜치 하나만을 가지고 진행하는 방식이다. master 브랜치는 어떤 기능이 구현되든, 오류가 수정되든 모두 master에서 머지되어 항상 update된 상태를 유지한다.

 

1. master 브랜치에서 개발이 시작된다.

2. 기능 구현이나 버그가 발생하면 feature/{구현기능명} 브랜치에서 개발을 하고, commit log를 작성한다.

3. push를 하면 pull request를 날릴 수 있다.

4. pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정이 진행된다. release 브랜치가 없으므로 이 과정이 꼼꼼하게 진행되어야 한다.

5. 모든 리뷰와 테스트가 마치면 master 브랜치에 머지한다.

 

Github Flow는 과정을 많이 줄인 만큼 단순하지만 pull request에서 팀원 간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 자체에서 버그가 발생할 수 있으므로 주의해야 한다.