우리 프로젝트에 제대로 된 Git 브랜치 전략을 세우는 게 어때요?
안녕하세요. 이 포스트는 제가 프론트엔드 개발자로 참여 중인 가사분담 플랫폼 '두잇투게더'의 Git 브랜치 전략을 팀원들과 함께 세우기 위해 정리한 내용입니다.
나, 지금까지 Git branch를 어떻게 사용했더라
Git과 GitHub에 대해 잘 몰랐던 제가 처음으로 브랜치를 사용했던 프로젝트는 2022년에 진행한 반려 식물 돌봄 매칭 서비스, planter였습니다. 그때는 develop 브랜치를 default 브랜치로 설정하고, 새로운 기능을 추가하거나 버그를 수정할 때마다 별도의 브랜치(feature, design, fix)를 만들어 작업을 했습니다.
작업이 끝난 후에는 PR(Pull Request)을 생성해 develop 브랜치에 병합했고, 최근 프로젝트에서도 같은 방식으로 진행했었습니다. 그 덕분에 저는 어느새 Git 브랜치 전략에 대해 꽤 잘 알고 있다고 생각했고, "나 이제 Git 고수야!"라고 주장했지만
어제, 그게 엄청난 착각이라는 걸 깨닫게 되었습니다. 사실 전 아직 Git에 대해 잘 알지 못하고 있었습니다.
Git 브랜치 전략
https://techblog.woowahan.com/2553/
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합니다. '배달
techblog.woowahan.com
개발자라면 한 번은 다들 읽지 않았을까요? 전 이제 읽었네요(머쓱..)
네, 하여튼 이 글을 보고 눈을 떴달까요.
우선 Git 브랜치 전략이 뭐냐?
여러 개발자들이 동시에 효율적으로 작업할 수 있도록 Git을 사용하는 방식이나 규칙을 정의한 것.
한마디로 우리 git 이렇게 사용해요! 하고 약속하는 것이죠.
제 생각에 그 중에 가장 보편적인 게, GitHub-Flow 와 Git-Flow인 것 같습니다.
GitHub-Flow
GitHub-Flow는 Git-Flow보다 간단한 방식으로, 자동화된 배포를 전제로 하며 master(or main) 브랜치만을 사용하여 개발하는 방식입니다.
GitHub-Flow는 총 두 개의 브랜치를 사용합니다.
- master(main) : 항상 배포 가능한 상태를 유지하는 브랜치입니다.
- feature : 새로운 기능을 개발하는 브랜치로, master(main)에서 분기하여 작업을 진행합니다. 작업이 완료되면 다시 master(main) 브랜치로 병합합니다.
즉, 기능이 개발되면 내부에서 리뷰를 하고 바로 배포를 시키는 방법이죠.
제가 지금까지 이렇게 개발을 해왔던거 같은데.. 음? 그럼 나름 브랜치 전략이 있었다는걸까요? ㅎㅎ..(뻥)
Git-Flow
Git Flow는 Vincent Driessen이 제안한 전략으로, 비교적 큰 프로젝트에 적합한 방식입니다. 기본적으로 개발 프로세스를 여러 단계로 나누어 관리하는 방식입니다.
Git-Flow는 총 다섯 개의 브랜치를 사용합니다.
- master(main) : 항상 배포 가능한 상태를 유지하는 브랜치. 최종 제품 버전이 여기에 존재합니다.
- develop : 개발 중인 코드가 모이는 브랜치. feature 브랜치들이 이곳에 머지됩니다. master(main)에서 분기하여 작업을 진행합니다.
- feature : 새로운 기능을 개발하는 브랜치로, develop 브랜치에서 분기하여 작업합니다. 기능 개발이 완료되면 다시 develop에 병합됩니다.
- release : 제품 배포를 위한 준비를 하는 브랜치. 버그 수정, 문서화 작업 등이 이루어집니다. 검증계로, 실데이터를 가지고 QA를 진행합니다. develop에서 분기하고, 작업이 끝나면 master와 develop에 병합됩니다.
- hotfix : master 브랜치에서 발생한 긴급한 버그를 수정하는 브랜치입니다. 수정 후에는 master와 develop에 모두 병합됩니다.
GitHub-Flow보다 확실히 더 복잡하죠? 그대신 훨씬 더 전략적이라는 생각이 드네요.
잠깐, 이건 뭐지?
팀원들과 그동안 해왔던 이상한 Git 브랜치 전략 경험을 나누면서 두 가지의 질문이 나왔습니다.
첫 번째, 이슈와 브랜치는 개발이 완료되면 바로 닫고 삭제하는게 좋은건가?
두 번째, main을 default 브랜치로 뒀다가 다시 develop으로 default 브랜치로 바꾸는, 왔다리갔다리 전략을 해도 되는가?
현업에 계신 개발자분께 질문을 드렸더니,
이슈와 브랜치는 최대 3개월 동안 유지하고, 정말로 해당 기능에 버그가 없다고 확신할 수 있을 때에야 이슈를 닫는다고 하셨습니다. 저는 보기 싫다고 바로바로 정리하던 스타일이라, 확실히 제 자신이 아직 수준이 단순 기능구현에만 몰입하는 지망생이라 생각이 들었습니다.
또한 default 브랜치를 바꾸는 일은 거의 없다고 하셨고, main 브랜치를 계속 유지한다고 하셨습니다.
지금까지 브랜치 왔다 갔다 하는 게 귀찮아서 develop을 default 브랜치로 설정했었는데, 그 말씀을 듣고 또 한 번 큰 충격을 받았습니다.
두잇투게더만의 Git 브랜치 전략
저희 팀은 Git-Flow를 기반으로 하되 우리의 상황에 맞게 약간 수정을 하기로 했습니다.
주요 변경 사항으로는 검증 단계인 release 브랜치를 제거하고, hotfix 대신 더 일반적인 용도의 fix 브랜치를 도입하는 것으로,
그 이유는 프로젝트가 초기 개발 단계에 있어 실제 데이터를 다루지도 않고, 배포 과정에서 중대한 이슈가 발생할 가능성이 낮다고 판단했기 때문입니다.
| 브랜치 | 설명 | 예시 | base branch |
| main | 운영계 (Tag 표시) | main | |
| develop | 개발계 main에서 나와서 main으로 merge |
develop | main |
| feature | 로컬계 이슈 단위 기능 개발 브랜치 develop에서 나와서 develop으로merge |
feature/#1-add-login | develop |
| fix | 버그 수정 develop에서 나와서 develop으로merge |
fix/#2-resolve-login | develop |
간단하게 플로우를 설명해드리자면,
- main 브랜치는 운영 환경으로 설정한 후 초기 배포를 진행합니다.
- 그 후 main 브랜치에서 개발 환경인 develop 브랜치로 분기하여 개발 작업을 시작합니다.
- GitHub에서 Issue를 생성하고, 그에 맞는 작업 단위로 develop 브랜치에서 feature 브랜치를 분기하여 작업을 진행합니다.
- feature 브랜치에서 작업이 완료되면, PR을 생성하여 develop 브랜치에 병합합니다.
- develop 브랜치에 병합 후 발생한 복합적인 버그는 fix 브랜치를 생성하여 수정한 뒤, 다시 develop 브랜치로 병합합니다.
- 개발이 완료되면 main 브랜치에 병합해 최종적으로 배포를 합니다.
그 외에도,
1. feature 브랜치의 사소한 버그는 feature 브랜치에서 수정하기
2. feature 브랜치는 컴포넌트별로 시작했다가 큰 기능 쪽으로 확대, 이슈는 쪼개서
3. 이슈, 브랜치 삭제는 일주일마다 한번에
라는 규칙을 설정했습니다.
이제 Git 브랜치 전략도 세웠겠다,
내일부터 개발에 들어갈 것 같습니다. 과연 저희의 전략이 제대로 세워졌을지..
걱정이되면서도 설레네요.
한번 프로젝트를 완료해보고 느낀 점도 한번 써보겠습니다.
감사합니다 :)