우선 나는 Git을 떠올리면 약간의 걱정부터 드는 개발자다. "개발자라면 당연히 Git을 눈 감고도 쓸 줄 알아야지!" 라는 말에 어느 정도 동의는 하지만, 눈 뜨고도 혹시 브랜치를 잘못 합치거나 명령어를 잘못 쳤을까 봐 긴장하곤 한다.
이런 깃린이가 Gitflow를 쓰게 되면서 브랜치에 대한 머릿속 정리가 좀더 깔끔해진 것 같아 간단히 정리해둔다.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Gitflow Workflow | Atlassian Git Tutorial
A deep dive into the Gitflow Workflow. Learn if this Git workflow is right for you and your team with this comprehensive tutorial.
www.atlassian.com
Gitflow는 git을 보다 잘 쓰기 위한 브랜치 전략이다. GUI 툴인 Github Desktop, SourceTree, Kraken 등이 아니다.
집단, 프로덕트의 성격 등에 따라 적절한 브랜치 전략을 세우고 함께 작업하는 개발자들은 그 약속 안에서 개발을 진행해나가는데,
Gitflow는 적게 배포하고 코드 freeze를 하는 프로젝트보단, 정기 배포가 있고 여러 명의 개발자가 각기 다른 부분을 담당하는 규모가 큰 프로젝트에 더 효과적으로 쓰인다고 느꼈다.
왜냐면 Gitflow 전략은 5가지의 브랜치를 지원한다.
1. master (main)
공식적으로 릴리즈한 모든 이력을 담고 있는 가장 상석(?)의 브랜치.
웬만하면 master 브랜치에서 작업할 일은 없다. 프로젝트의 현재까지의 최종 소스로 볼 수 있다.
2. develop
master 브랜치를 보조하는 feature들의 통합 브랜치.
develop 브랜치에서 완성된 코드를 master로 합쳐가는 식.
3. feature
기능을 개발하는 브랜치.
보통 여러 기능이 있을 텐데, 기능별로 다 다른 feature 브랜치를 딴다.
기능에 해당하는 부분만 여기서 손을 대고, 기능이 완료되면 develop 브랜치에 합친다.
보통 이 feature 브랜치까지는 개인/소규모 프로젝트에서도 많이 사용하는 것 같다.
4. release
이번 출시/배포를 위한 브랜치.
develop에서 바로 master로 합치지 않고, release 브랜치로 만든다.
여기에서는 더이상 새로운 기능을 붙이지 않고 간단한 버그 픽스 정도만 진행한다.
5. hotfix
배포 후에 발견한 심각한 버그를 수정해야 할 때 master에서 따는 브랜치.
긴급 수정을 한 후에 develop과 master로 각각 push한다.
위 그림의 설명 + 회사에서 사용한 경험으로 플로우를 설명해보겠다.
우선 master와 develop 브랜치가 이미 있고 현재 동일한 소스이며 이제부터 새로운 작업을 해야 하는 상황이라고 가정한다.
1) develop 에서 feature 를 생성한다.
git flow feature start feature_#1위 커맨드로 develop을 기반으로 한 feature_#1 브랜치를 만들고 checkout할 수 있다.
2) feature_#1, feature_#2, ... 에서 작업이 완성되면 각각 develop으로 합친다.
git flow feature finish feature_#1위 커맨드로 feature -> develop 머지가 가능하다.
3) 현재까지의 develop 소스로 출시 버전인 release를 생성한다.
git flow release start release_20230210생성된 release는 더이상 새로운 큰 기능이 추가되지는 않고 QA를 하며 작은 버그 픽스만 이루어진다.
4) release가 안정적이면 develop, master로 합친다.
git flow release finish release_20230210finish를 하면 release 브랜치가 develop과 master로 각각 merge된다.
실제 라이브 배포가 이루어지는 것은 가장 최신 release이고, master는 최종 코드라는 의미가 더 강하다.
5) 출시를 한 후에 발견된 버그를 수정하기 위해 hotfix를 따서 작업한다.
git flow hotfix start hotfix_20230210_#1
git flow hotfix finish hotfix_20230210_#1위의 커맨드로 hotfix 브랜치를 생성하고 작업한 후 finish를 해줌으로써 해당 hotfix 브랜치는 삭제가 되고, 동시에 develop과 master에 merge 된다.
다행히(?) 아직 hotfix 브랜치를 직접 만들어본 적은 없다.
항상 git은 따로 공부하기도 애매하고 들어가는 프로젝트나 만나는 팀원들마다 조금씩 다른 전략을 제시하기도 해서 나같은 주니어 개발자들에게는 숙제같은 기분이 들곤 한다. 결국 경험치가 쌓이는 게 제일 중요하지 않을까 싶지만, 이슈가 생겼을 때 덜 당황하기 위해 짬짬이 봐두자.