언제 볼지 모르는 면접을 대비하여 여러 파트를 나눠 공부 중인데, git 파트의 git-flow를 공부하게 돼 내용을 정리해보려 한다.
노션에만 정리해놓기엔 뭔가 아쉬워서(?) 포스팅을 한다.
개발하는 소프트웨어가 버전화 돼있거나, 여러 개의 버전을 지원하는 경우에 git-flow 전략이 적합하다.
git-flow 전략은 총 5개의 브랜치를 활용한다.
5개의 브랜치를 메인 브랜치와 서브 브랜치로 나눌 수 있으며, 각 브랜치의 역할과 사용 방법은 다음과 같다.
메인 브랜치
메인 브랜치는 이름 그대로 코어 역할을 하며, 수명이 무한정인 브랜치들이다.
1. master
- 항상 배포 준비 상태의 코드를 반영한다.
2. develop (integration)
- 항상 다음 배포를 위한 최신 변경사항을 반영한다.
- develop 브랜치의 소스 코드가 안정화 되고 배포할 준비가 되면 master 브랜치로 merge 되어야 하고, 배포 번호(release number) 태그를 지정해야 한다.
- 변경 사항이 master 브랜치에 merge될 때를 배포 시점이라 할 수 있으며, hook 스크립트를 사용하여 master 브랜치에 커밋이 있을 때마다 자동으로 빌드 후 배포할 수 있다.
서브 브랜치
서브 브랜치는 팀원 간의 협업을 지원하고, 기능 추적을 용이하게 하며 배포와 출시 중 발생한 문제를 지원한다. 수명이 짧으며, 결국 삭제된다.
1. feature (topic)
- 향후 출시를 위한 새로운 기능을 개발하기 위해 사용한다.
- develop 브랜치에서 만들어지며, 개발 결과에 따라 다시 develop 브랜치에 merge되거나, 폐기 처리된다.
- 보통 개발자의 repo에서만 사용하며, origin에는 생성하지 않는다.
2. release
- 새로운 배포 준비를 위해 사용한다. 사소한 버그나 메타 데이터(버전, 날짜 등) 수정은 허용한다.
- 새로운 배포가 거의 완료되면 develop 브랜치에서 만들어진다.
- 해당 시점에 배포할 내용만 포함해야 하며, 향후 배포할 내용은 그 시점에 가서 분기한 후 작업해야 한다.
- 버전은 release 브랜치를 분기할 시점에 할당한다.
(이전 버전은 상관 없다. 이전 배포 버전이 1.1이고 당시 1.2를 계획했었더라도 실제 분기할 때 2.0을 배포 계획이라면 2.0으로 할당한다.) - 분기 후에는 버전 번호(version number)를 분기해야 한다.
$ ./bump-version.sh 1.2- 완전히 배포될 때까지 유지되며, 여기서 버그 수정이 가능하지만 새 기능 추가는 금지된다.
- 정식 배포 준비가 완료되면 master로 merge 돼고, 추후 참조할 수 있도록 커밋에 태그를 지정한다.
- develop 브랜치에도 merge 해서 버그 수정사항을 포함하게 한다.
- merge 완료 후 삭제한다.
3. hotfix
- 계획된 작업은 아니지만 배포 준비를 위한 점에서 release 브랜치와 비슷하다.
- 출시 버전에서 즉각 해결해야 할 문제가 발생했을 때, master 브랜치에서 만들어진다.
- 한 사람이 버그를 해결하는 동안, 다른 팀원들은 계속 develop 브랜치에서 작업을 해나갈 수 있다.
- 분기 후에는 항상 버전 번호를 분기해야 한다.
$ ./bump-version.sh 1.2.1- 작업이 완료되면 master에 merge 하고 태그를 지정한 후 develop 브랜치에도 merge 한다.
- 단, 현재 작업 중인 release 브랜치가 있다면 release 브랜치로 merge 해야 반복 작업을 방지할 수 있다.
- merge 완료 후 삭제한다.
대부분의 개발자들은 배포 전에 항상 예민하다고 하던데 정말 신경 쓸 게 한두 개가 아닐 것 같다는 생각이 든다.
당연히 코드 자체에도 신경을 써야하지만, 협업을 위해 정확한 브랜치를 적합한 시점에 사용해야 하고 나만의 프로젝트가 아니기 때문에 동료를 항상 도울 수도 있어야 할 것 같다.
부트캠프에서 작은 프로젝트이긴 했지만 브랜치 활용이 서툴러 엉뚱한 곳에서 브랜치를 파고도 뭐가 잘못된 지 몰랐던 적, 동료 코드가 날라가서 팀 전체가 고생한 적이 있었는데, 이제 생각해보면 이런 것들이 git 활용의 중요성이 아닐까 싶기도 하다.
아직 git-flow에 따라 프로젝트를 진행해 본 경험은 없지만 새로운 지식을 쌓게 됐다는 것이 만족스러우며, 얼른 실무에서 이러한 플로우를 따라 작업을 해보고 싶다.
