왜 필요할까?
만약, 프로젝트에서 하나의 브랜치에서 다수의 개발자가 서로 다른 기능을 개발한다면, 기능이 완성되기 전까지 main 브랜치의 코드가 불완전한 상태로 존재하게 되고, 내가 작성한 코드를 다른 사람이 건드린다는 등 여러 가지 문제점이 발생합니다.
브랜치를 사용하여 프로젝트 기준 코드인 main 브랜치로부터 독립적인 작업 공간을 만들어준다면, 여러 개발자가 각각의 기능을 서로의 작업에 영향을 주지않는 독립적인 환경에서 개발할 수 있게 됩니다.
하지만, 프로젝트 규모가 커지고 다수의 개발자가 협업하는 상황에서 브랜치에 대한 아무런 규칙이 없다면 여러 혼란을 불러올 수 있습니다.
‘이 브랜치는 어떤 목적으로 생성된거지?’, ‘이 브랜치는 어떤 커밋에서 분기된거지?’, ‘어떤 브랜치에서 내 브랜치를 생성해야하지?’, ‘내 브랜치는 어디에 병합해야지?’, ‘어떤 브랜치가 최신이지?’, ‘어떤 브랜치가 배포된 버전이지?’
이러한 상황을 최소화하기 위해 사용되는 것이 깃 브랜치 전략입니다. 즉, 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow입니다.
여러 가지 깃 브랜치 전략이 있지만 가장 널리 활용되고 있는 git-flow 전략과 github-flow 전략에 대해서 알아보겠습니다.
Git flow
Git flow는 현재 많은 기업에서 표준으로 사용하는 브랜치 전략으로 크게 5개의 브랜치를 운영하며 관리합니다.
- 메인 브랜치 : master, develop
- 보조 브랜치 : feature, release, hotfix
배포 주기가 길고 팀의 여럭이 있는 경우 적합합니다.
git flow 브랜치 구조
feature
추가 기능 구현을 담당하는 브랜치입니다.
보통 feature/{구현기능명} 형식의 컨벤션을 가집니다. ex) feature/login
feature 브랜치는 develop 브랜치에서 생성되어 작업을 완료한 후, develop 브랜치로 머지됩니다. 머지된 후에는 해당 브랜치를 삭제합니다.
develop
다음 출시 버전을 대비하여 개발하는 브랜치입니다.
하나의 feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능을 더해가며, develop 브랜치가 배포할 수준의 기능을 갖추면 release 브랜치로 머지됩니다.
release
다음 버전 출시를 준비하는 브랜치입니다.
브랜치명은 release-* 형식으로 설정합니다.
QA와 테스트를 거쳐 버그를 수정한 후, 배포할 준비가 되었다고 판단하면 master로 머지해 배포합니다. 또한 변경 사항을 develop 브랜치에도 반영합니다.
hotfix
master 브랜치에서 발생한 버그를 수정하는 브랜치입니다.
브랜치명은 hotfix-* 형식으로 설정합니다.
release 브랜치에서 예상하지 못한, 배포 후에 발견된 버그들에 대해 수정합니다.
hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, master 브랜치에 수정 사항을 반영합니다.
master
라이브 서버에 제품으로 출시되는 브랜치로 배포 가능한 상태만을 관리하는 브랜치입니다.
git flow 흐름
1. 신규 기능 개발
개발자는 새로운 기능 개발을 위한 업무를 할당 받고, develop 브랜치로부터 기능 개발을 위한 feature 브랜치를 생성합니다. feature 브랜치에서 기능을 완성하면 develop 브랜치에 머지합니다.
2. 라이브 서버로 배포
feature 브랜치들이 모두 develop 브랜치에 머지되었다면 QA를 위해 release 브랜치를 생성합니다. 버그 등 수정사항이 확인된다면 release 브랜치 내에서 수정을 진행합니다. QA와 테스트를 모두 통과하면, 배포를 위해 release 브랜치를 master로 머지하며, release 브랜치에서 수정 사항이 있을 경우 동기화를 위해 develop 브랜치에도 머지를 합니다.
3. 배포 후 관리
만약 라이브 서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행합니다. 작업을 마친 후 master와 develop 브랜치에 머지하여 동기화합니다.
Github flow
Github flow는 git flow의 브랜치 전략이 Github에 적용하기에는 복잡하다는 판단에 따라 생겨난 브랜치 전략입니다.
Master 브랜치를 중심으로 운영되며 기능 개발, 버그 수정 등의 작업용 브랜치를 구분하지 않는 단순한 구조입니다.
수시로 배포가 일어나는 프로젝트에 유용합니다.
github-flow의 흐름
1. 브랜치 생성
- master로부터 기능 개발, 버그 수정 등의 작업을 위한 새로운 브랜치를 생성합니다.
- 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내야 합니다.
2. 개발 & 커밋 & 푸쉬
- 작업을 하며 기능별로 commit을 남깁니다.
- commit 메시지는 명확하게 작성해야 합니다.
- 원격지 브랜치로 수시로 push하여 다른 사람들도 확인할 수 있도록 합니다.
3. Pull Request 생성
- 기능 개발이 끝나고 merge할 준비가 완료되었을 때 pull request를 생성합니다.
4. 리뷰 & 토의
- pull request이 완료되면 master에 머지되고, 곧바로 production 환경에 배포되기 때문에 팀원 간 자세한 리뷰, 토의가 이루어집니다.
5. 테스트
- 모든 리뷰가 끝나면, merge하기 전에 라이브 서버나 테스트 환경에 배포하여 최종 테스트를 진행합니다.
- 문제가 발생할 경우 원래의 master 브랜치를 다시 배포하여 롤백합니다.
6. Merge
- 문제 없이 테스트를 마쳤다면 그대로 master 브랜치에 merge합니다.
- master로 merge, push가 일어나면 자동으로 배포가 되도록 설정해놓습니다. (CI/CD)
어떤 것을 선택해야 할까?
- 팀의 브랜치 전략은 조직의 규모, 서비스의 특징 등을 고려하여 협의를 통해 결정해야합니다.
- Production의 공식 배포 주기가 길고 QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git flow가 적합합니다.
- 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 work-flow가 적합합니다.
<참고>
https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5
https://hudi.blog/git-branch-strategy/
https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/
https://www.youtube.com/watch?v=wtsr5keXUyE
https://www.youtube.com/watch?v=EV3FZ3cWBp8
