출처: git기초 (코딩애플)
서론
프로젝트가 커졌을 경우
git branch를 깔끔하게 만들도록 도와주는 방법론 같은게 있습니다.
git flow,
github flow
gitlab flow
trunk-based 등 다양한 것들이 있는데
이것을 적용하면
브랜치관리가 쉬워지고
팀원이 아무리 많아도 개발절차가 매끄러워집니다.
그래서 프로젝트 리드하는 팀장이 알면 좋습니다.
git flow 전략
gir flow 전략은 크게 5개의 브랜치를 운영합니다.
- main 브랜치
- develop 브랜치 (개발용)
- feature 브랜치 (develop에 기능 추가용)
- hotfix 브랜치 (main 브랜치 버그해결용)
- 가끔 release 브랜치 (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용)
게임개발 프로젝트의 팀장이라고 생각해봅시다.
그리고 0.9 버전에서 1.0 버전으로 가려고 합니다.
1. develop 브랜치부터 생성합니다.
위험하기때문에 신기능 개발해서 바로 main 브랜치에 합칠 수 없습니다.
실험용 프로젝트 사본을 만들고 거기다가 먼저 개발해봅니다.
그러기 위해 main 브랜치에 있던 기존 프로젝트를 복사한 develop 브랜치를 생성합니다.
이제 모든 개발은 develop 브랜치에서 진행하라고 팀원들에게 전파합니다.
2. 신기능 개발은 feature 브랜치에서 진행
신기능을 만들고싶으면 develop 브랜치를 복사한 feature 브랜치에서 각각 개발합니다.
feature/guild 브랜치 만들어서 길드기능 만들고
feature/friend 브랜치 만들어서 친구기능 만들고 합니다.
(보통 대시나 / 기호로 브랜치 작명을 합니다.)
완성되면 develop 브랜치에 merge 합니다.
중요한 내용이 아니라면 squash and merge도 괜찮습니다.
3. 신버전 출시 준비는 release 브랜치
develop에서 만든 2개 기능이 완성됐습니다.
이걸 바로 main 브랜치에 합치기에는 불안해서
develop -> release 브랜치 이렇게 프로젝트를 복사한 다음 출시준비를 합니다.
여기서 테스트나 Q&A 하면 됩니다.
버그를 발견하면 알아서 임시 브랜치를 만들어서 수정하거나 합니다.
release/1.0 이런 식으로 이쁘게 브랜치명을 짓는 경우가 많습니다.
완성된 것 같으면 main 브랜치로 merge 합니다.
그리고 유저에게 배포합니다.
개발은 계속 진행되어야 하므로 완성본은 develop 브랜치에도 merge 합니다.
4. hotfix 브랜치
1.0버전에서 돈복사 버그를 발견했습니다.
이런 급한 것은 main 브랜치에서 hotfix 이런 브랜치 하나 만들어서 바로바로 버그를 수정합니다.
수정이 완료되면 main 브랜치에 merge 하면됩니다.
당연하게도 develop 브랜치에도 merge 해야합니다.
유저들에게는 '잡다한 버그 수정' 공지해주고 점검보상을 살짝 해줍시다.
게임 뿐만 아니라 웹이나 앱도 비슷하게 운영할 수 있습니다.
다 합친 그림입니다.
안따라해도 됩니다.
예를 들어 release 브랜치 쓰지 않고 바로 main 브랜치에 merge 해서 배포해도 됩니다.
대신 선택에 이유와 근거가 있으면 되고
책임도 지면 됩니다. (책임은 코드짠 사람으로 가겠지만)
Trunk-based 전략
"브랜치 하나만 잘 관리하자"
코드를 작성한 걸 바로 배포해도 상관 없는 프로그램이면
그리고 크게 대격변 업데이트를 안하는 안정적인 프로그램이면
굳이 많은 브랜치를 만들 필요가 없습니다.
그래서 main 브랜치와 기능 추가용 feature 브랜치만 운영하면 됩니다.
(github flow 방법과 유사합니다.)
-
기능추가, 버그 픽스가 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어서 코드를 짭니다.
-브랜치마다 작명을 잘 해야합니다. -
기능이 완성됐으면 main 브랜치에 합칩니다.
-이제 브랜치는 쓸데없으니 삭제합니다. -
main 브랜치에 있는 코드를 필요할 때마다 유저들에게 배포합니다.
장점은 코드를 한 브랜치에서만 관리하기 때문에 편리합니다.
크게 개발해서 merge 하는 것보다 작은 단위로 merge 하는 것이 더 안전합니다.
하지만 main 브랜치에 있는 코드가 뻑이나면 큰일나기 때문에 자주 코드리뷰와 테스트를 해줘야합니다.
그래서 테스트를 자주하고 자동화해놓은 곳들이 제대로 사용가능합니다.
결론
이미 어느정도로 개발이 진척이 되었거나 수준 높은 개발자가 많은 팀이면 trunk-based 가 훨씬 편리합니다.
출시된 버전의 안정성이 중요한 프로그램들, 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 git flow 가 적절할 수 있습니다.
물론 정해진 것은 없고 직접 해보고 판단하는게 좋습니다.
