많은 개발자들이 브랜치를 대충 아무렇게나 만들면 개발과정이 매우 복잡해지고 추적도 어려워서
git branch를 깔끔하게 만들도록 도와주는 방법론이 있습니다.
git flow, github flow, trunk-based 등 다양합니다.
이런 걸 적용하면
1. 브랜치 관리가 쉬워지고
2. 팀원이 아무리 많아도 개발 절차가 매끄러워집니다.
그래서 프로젝트 리드, 매니저 하는 사람들이 알면 좋습니다.
시키는 것만 하는 코딩노예들은 몰라도 됩니다.
1. 안정적인 운영이 필요하면 git flow
님들이 만드는 프로그램이 항상 안정적인 배포를 해야한다면 (게임 등)
git flow 전략을 쓰면 됩니다.
git flow 전략은 크게 5가지 브랜치를 운영하는데
- main 브랜치
- develop 브랜치 (개발용)
- feature 브랜치 (develop 브랜치에 기능 추가용)
- hotfix 브랜치 (main 브랜치 버그 해결용)
- 가끔 release 브랜치 (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용)
를 운영합니다.
이제 여러분은 게임 개발 팀장입니다.
지금까지는 대충 브랜치를 만들어서 정상적인 버전으로 0.9버전까지 만들어놨다고 칩시다.
근데 1.0버전부터는 신기능도 많고 해서 제대로 개발을 진행하고 싶은겁니다.
그래서 이번엔 git flow를 도입해서 개발을 진행해봅시다.
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 브랜치 이렇게 프로젝트를 복사한 다음 출시 준비를 합니다.
- 여기서 테스트, QA 등을 진행합니다.
- 버그를 발견하면 알잘딱 임시 브랜치 만들어서 수정합니다.
- release/1.0 이런 식으로 이쁘게 작명하는 경우가 많습니다.
최종 완성된 것 같으면 main 브랜치로 merge합니다. 그리고 그거를 유저들한테 배포합니다.
개발은 계속 진행되어야 하니, 완성본은 develop 브랜치에도 merge 해줍시다.
4. 갑자기 못찾은 버그 발견하면 hotfix 브랜치
1.0 버전에서 갑자기 골드 무한복사 버그를 발견했습니다.
그런 급한 것들은 main 브랜치에서 hotfix 브랜치를 만들어서 바로바로 버그를 수정합니다.
- 수정이 완료되면 main 브랜치에 직접 merge합니다.
- 당연히 develop 브랜치에도 merge 해줍니다.
이제 유저들에겐 "잡다한 버그 수정" 공지만 올리고 점검보상 던져주면 됩니다.
게임뿐만아니라 웹이나 앱도 비슷하게 운영할 수 있습니다.
5. 전체 플로우
Q. 꼭 저거대로 따라해야 함?
A. 물론 단점도 있습니다.
최근 continuous delivery 이런거 한 때 유행이었는데 그런거 할 땐 적합하지 않을 수 있습니다.그래서 맨날 남들이 하는거 앵무새처럼 따라할 생각하지 말고 본인 마음대로 변형해서 쓰십시오.
예를 들면 release 브랜치 쓰지 않고 바로 main 브랜치에 merge 해서 배포하거나 그래도 됩니다.
그 선택에 합당한 이유와 근거가 있으면 됩니다. 물론 책임도 져야합니다.
근데 PM 위치에서 책임은 언제나 전가 가능
2. Trunk-based 전략
님들이 만드는게 바로 대중에 배포를 해도 상관 없으면,
그리고 크게 대격변 업데이트를 안하는 안정적인 프로그램이면
굳이 많은 브랜치를 만들 필요가 없습니다.
그냥 main 브랜치와 기능 추가용 feature 브랜치만 운영하면 됩니다.
이게 trunk-based 전략입니다.
github flow도 이거랑 비슷합니다.
1. 기능 추가, 버그 픽스가 필요하면 main 브랜치에서 새로운 feature 브랜치를 하나 만들어서 코드를 작성합니다.
브랜치마다 작명 잘 하는게 중요합니다.
2. 기능이 완성되었으면 main 브랜치에 합칩니다.
이제 feature 브랜치는 쓸데없으니 삭제합니다.
3. main 브랜치에 있는 코드를 필요할 때마다 유저들에게 배포합니다.
- trunk-based 개발의 장점은 코드를 한 브랜치에서만 관리하기 때문에 편리합니다.
- 크게 개발해서 한 번에 merge 하는 것 보다는, 작은 단위로 merge 하는 것이 더 안전합니다.
- 하지만 main 브랜치에 있는 코드가 뻑나면 큰일나기 때문에 테스트나 코드 리뷰를 자주 해야합니다.
그래서 테스트를 자주 하고, 자동화해놓는 곳들이 제대로 사용 가능합니다.
오늘의 결론
이미 어느정도 개발이 진척이 되었거나 프로 코딩전사들로 가득한 팀이면 trunk-based 이런거 쓰는게 훨씬 편리합니다.
최근 유행한 CI/CD 이런 식으로 개발하는 곳들도 trunk-based 개발방식을 적용합니다.
출시된 버전의 안정성이 중요한 프로그램들, 아직 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 git flow가 적절할 수 있습니다.
하지만 물론 정해진 것은 없고 직접 해보고 판단하는게 좋습니다.
Q. merge 할 때 어떤 방법 쓰는게 좋은가요?
기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge
기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase 쓰면 됩니다.
취향일 뿐이고 알아서합시다.
강의 출처
