개발자 협업을 위한 브랜치 전략 정하기

정하기에 앞서.

브랜치 전략을 정하기에 앞서 브랜치란 무엇이고 브랜치 전략은 무엇인지 간단하게 알아보자.

먼저 브랜치라는 것은

팀 내에서 개발자들이 중앙 집중식 저장소 내에서 독립적인 코드를 작성하고 통합하게 해 협업을 지원하기 위한 코드 베이스[#2]

를 의미한다. 이는 독립적인 코드 베이스기 때문에 팀 메이트에게 영향을 주지 않고 원하는 기능 개발을 할 수 있다.

브랜치 전략이란 여러 개발자가 협업할 때 Git 저장소를 효과적으로 활용하기 위한 규칙의 집합이자 Workflow라 소개된다.

이 전략을 활용해 회사 마다 다양한 방식으로 소스 코드를 관리하고 배포하고 있다.

브랜치 전략을 사용하면 어떤 브랜치를 기준으로 수정하고 배포해야 할지 쉽게 알 수 있고, 변경 사항에 대한 이력 추적에도 도움이 된다고 한다.

그게 왜 도움이 되는지 사례가 있으면 이해하기 좋았을 텐데 찾지 못해 아쉬웠다. 대신에 참고할 만한 좋은 글이 있어 공유 해본다.

이 브랜치 전략에는 대표적으로 두 가지 방식이 있다.

하나는 Git Flow이며, 다른 하나는 GitHub Flow이다.

Git Flow.

Git Flow는 프로젝트가 장기간 개발되며 주기적으로 배포해야 하는 상황에서 적합하다. 테크 기업에서 주로 채택해 사용되는 브랜치 전략 중에 하나이고, 브랜치 전략의 초기 모델 중 하나이다. [#1]

이 전략 모델은 master, hotfix, release, develop, feature라는 총 5가지 브랜치로 나뉘고, master와 develop는 주요 브랜치, release, feature, hotfix는 보조 브랜치라고 한다.

주요 브랜치.

master: 혹은 main 브랜치라고도 하며, 최종적으로 제품으로 출시될 수 있는 브랜치이다.
develop: 다음 출시 버전을 개발하기 위한 출시 준비 브랜치이다.

보조 브랜치.

release: 이번에 출시를 준비해야 할 버전의 브랜치이다.
- 통합 테스트 및 QA를 진행할 수 있다.
- 여기서 오류가 발생하면, 여기서 수정한다.
- master로 통합할 때, 수정사항이 있었다면 develop에도 통합한다.
hotfix: 출시 버전(master)에서 발생한 버그를 수정할 때 사용하는 브랜치다.
- 버그 픽스가 끝나면 develop과 master에 통합한다.

Git Flow의 흐름.

먼저, 팀에서 master 브랜치를 생성한다.
생성된 master 브랜치에서 보조 브랜치인 develop 브랜치를 생성한다.
develop 브랜치에서 가능한 작은 단위로 기능 개발을 위한 feature 브랜치를 생성하고, 작업한다.
기능 개발이 완료된 feature에서 develop으로 리뷰 및 통합한다.
출시를 위해 작업 내역을 release로 옮기고, 테스트한다.
테스트를 통해 발견된 이슈를 release에서 수정하고, master와 develop으로 통합한다.
master에서 최종 테스트를 진행하면서 버그가 발생하면 hotfix 브랜치를 생성해 수정한다
수정 내역을 master 뿐만 아니라, develop에도 통합한다.

GitHub Flow.

GitHub Flow는 굉장히 단순한 전략 모델중 하나로, 복잡하지 않기 때문에 관리가 용이해야 하거나 작은 규모의 프로젝트에서 유용하다.

빠른 속도로 릴리즈되어야 하고, 지속적으로 테스트하고 배포가 가능해야 하는 팀이라면 GitHub Flow를 사용하는 것이 적합하다.

이 전략은 master 브랜치과 PR(Pull Request)만을 이용한 전략이다. Git Flow와 대비해 master 브랜치가 최신 버전 유지와 릴리즈 역할을 모두 한다.

기능을 개발하거나 버그를 고쳐야할 때, 어떤 이유로든 코드 베이스에 변경이 일어나야 한다면 브랜치를 새로 생성해 작업을 해야 한다. 이 때, master 브랜치 외에는 정해진 체계가 없기 때문에 아래와 같은 사항을 잘 지켜나가야 한다.

체계적인 분류가 없기 때문에 의도가 잘 드러나도록 브랜치명을 작성한다.
커밋 메시지를 충분히 상세하게 작성해서 PR 한다.
반드시 코드 리뷰와 토의를 거쳐서 실제 서버와 테스트 환경에 배포해야 한다.
이상이 없다면 마스터에 통합해 즉시 배포한다.

과제에서 어떤 브랜치 전략을 적용해야 할까.

과제의 규모가 크지 않고, 홀로 개발해야 하기 때문에 단순한 전략인 GitHub Flow를 사용해 보기로 했다.

다만 master와 그외 의도에 맞는 브랜치만 생성할 것이 아니라, 중간에 develop 브랜치를 둬서 이 브랜치를 통합 테스트 용도로 사용하려고 한다. 그리고 feature 브랜치의 경우에는 통합된 후에 자동 제거되도록 운영할 것이다.

따라서 아래와 같은 흐름으로 브랜치 전략이 작동할 것 같다.

master 브랜치 생성과 이를 기반으로 생성된 develop 브랜치
develop 브랜치에서 가능한 작은 단위로 기능 개발을 위한 feature 브랜치 생성
feature 브랜치에서 충분한 테스트를 거치고 PR을 통해 꼼꼼히 리뷰/토의
PR이 완료되면 develop으로 통합하고 해당 feature 브랜치 삭제
develop에서 개발 환경으로 배포하고, 통합 테스트 진행
통합 테스트 시에 버그가 발생된 사항에 대해서는 develop에서 수정
통합 테스트 및 수정 완료되면 master 브랜치로 통합 및 운영 환경에 배포

References.

#1. [우테코 - 웨지의 깃 브랜치 전략] https://www.youtube.com/watch?v=jeaf8OXYO1g

#2. [아틀라시안 -소프트웨어 개발과 브랜치] https://www.atlassian.com/ko/agile/software-development/branching

#3. [삼쩜삼 - 깃 브랜치 전략 개선기] https://blog.3o3.co.kr/231101-insight/

#4. [SK Enterprise - 깃 브랜치 전략 비교] https://www.sktenterprise.com/bizInsight/blogDetail/dev/8122

#5. [에프랩 - 효율적인 깃 브랜치 전략 선택하기] https://f-lab.kr/insight/effective-git-branch-strategy

#6. [우아한 기술블로그 - 우린 Git-flow를 사용하고 있어요] https://f-lab.kr/insight/effective-git-branch-strategy