깃 브랜치 전략 고민 - Github Flow / Git Flow

들어가며

간단한 토이 프로젝트를 진행하면서 Git 브랜치 전략에 대해 고민하는 시간을 가졌고 그 과정에서 Git flow와 Github-flow 전략에 대해 알아보고 Github-flow를 채택하였다. 왜 해당 flow를 채택하였는지 작성하겠습니다.

Git 브랜치 전략

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow이다.

Git-flow 전략에 대해

• 기본적인 가지의 이름은 아래의 5가지로 구분한다.
• feature > develop > release > hotfix > master
• 위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 hotfix 등 모든 가지들에 있는 커밋들도 병합하도록 구성하게 된다.
• 5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구분된다.

Git-flow 브랜치 구조

• master : 라이브 서버에서 제품으로 출시되는 브랜치
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치
• feature : 추가 기능 개발 브랜치, develop 브랜치에 들어간다.
• release : 다음 버전 출시를 준비하는 브랜치, develop 브랜치를 release 브랜치로 옮기는 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치

Github-Flow 전략에 대해

• Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식이다.
• 자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되지 않은 곳에서만 수동으로 진행하면 된다.
• Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.
• 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장한다.

1. 브랜치 생성

• 새로운 브랜치를 생성할 때 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 중요하다.
  • 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해준다.
• 새로운 브랜치는 항상 master 브랜치에서 만든다.

2. 개발 & 커밋 & 푸쉬

• 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요하다.
• 원격 브랜치로 수시로 push 하자

3. PR(Pull Request) 생성

• pull request는 코드 리뷰를 도와주는 시스템
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

4. 리뷰 & 토의

• pull request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.

5. 테스트

• 리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.
• 배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

6. 최종 Merge

• 라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행한다.
• 대부분의 Github-flow에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.

⇒ master로 merge되고 push 되었을 때는, 즉시 배포되어야 한다.

Github-flow 핵심 master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI/CD)

그래서 나는 ?

우리 프로젝트는 MVP 모델을 적용하기로 하였다. 그래서 MVP 모델을 적용하여 빠르게 개발하고 배포 후, 고도화 작업과 최적화, 유저 피드백을 반영하는 프로젝트에서는 Github-flow가 더 적합하다도 생각했다. 이유는 다음과 같다.

1. 빠른 개발 및 배포 : MVP 모델에서는 빠른 피드백 수집에 중요하다. Github-flow는 빠른 배포 주기를 지원한다.
2. 단순성 유지 : 초기에는 최소 기능만 개발하기 때문에 복잡한 브랜치 관리가 필요하지 않다.
3. 유연한 작업 방식 : 배포 후 고도화 및 최적화를 빠르게 반복할 수 있다.

마치며

프로젝트를 진행하기 전에 브랜치 전략에 대해 고민하고 채택하는 시간을 가져봤는데 실제로 Github-flow를 적용하고 느낀점에 대해서도 추후에 작성하겠습니다.