1. 배경설명
개발자 10명이서 브랜치를 대충 아무렇게나 만들면 개발과정이 매우 복잡해지고 추적도 어려워서,
git branch 깔끔하게 만들도록 도와주는 방법론같은게 있습니다.
Git Flow, Github Flow, Gitlab Flow, Trunk-based 등 다양한 것들이 있습니다.
이런걸 적용하면
- 브랜치관리가 쉬워지고
- 팀원이 아무리 많아도 개발절차가 매끄러워집니다.
그래서 프로젝트 리드하는 사람들이 알면 좋습니다.
2. Git Flow 전략
님들이 만드는 프로그램이 항상 안정적인 release를 해야한다면, (e.g. 게임개발) Git Flow 전략을 쓰면 됩니다.
Git Flow 전략(by Vincent Driessen)은 크게 5개 브랜치를 운영합니다.
maindevelop: 개발용feature: develop에 기능 추가용hotfix: main 브랜치 버그 해결용- 가끔
release: (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용
게임개발을 예시로 들면, 이제부터 여러분은 게임개발 팀장입니다.
- 지금까지는 대충 주먹구구식으로 협업해서 0.9버전까지 만들어놨다고 칩시다.
- 근데 1.0 버전부터는 신기능도 많고 해서 제대로 개발을 진행하고 싶은겁니다.
- 그래서 이번엔 Git Flow를 도입해서 개발을 진행해봅시다.
2.1 develop 브랜치부터 생성
신기능 개발해서 바로 main브랜치에 합칠 것입니까? 절대 안됩니다. 신입 개발자들을 믿을 수 없습니다.
- 일단 실험용 프로젝트 사본을 만들고 거기다가 먼저 개발합니다.
- 그러기 위해 main 브랜치에 있던 기존 프로젝트를 복사한 develop 브랜치를 생성합니다.
- 이제 모든 개발은 develop 브랜치에서 진행하라고 팀원들에게 전파합니다.
2.2 feature 브랜치에서 신기능개발
신기능을 만들고 싶으면 develop 브랜치를 복사한 feature 브랜치에서 각각 개발합니다.
-
feature/guild 브랜치 만들어서 길드기능 만들고
-
feature/friend 브랜치 만들어서 친구기능 만들고 하면 됩니다.
- c.f. 브랜치 작명할 때 여러 단어가 필요하면 보통 대시나 / 기호 씁니다
feature(기능)들이 어느정도 완성되면 develop 브랜치에 merge 합니다. 중요한 내용이 아니면 squash and merge도 괜찮습니다.
2.3 release 브랜치에서 신버전 출시 준비
develop에서 만든 2개 기능들이 완성된 것 같습니다.
이걸 바로 main 브랜치에 합치기엔 또 불안하기 때문에
develop -> release 브랜치 이렇게 프로젝트를 복사한 다음 출시준비를 합니다.
- 여기서 테스트나 QA같은거 진행하면 됩니다.
- 버그를 발견하면 알아서 임시 브랜치 만들어서 수정하거나 합니다.
- release/1.0 이런 식으로 이쁘게 브랜치 이름을 짓는 경우가 많습니다.
완성된 것 같으면 main 브랜치로 merge 합니다.
그리고 그거 유저들에게 배포하면 됩니다.
개발은 계속 진행되어야하니 완성본은 develop 브랜치에도 merge 해줍시다.
2.4 hotfix 브랜치에서 버그 수정
1.0 버전에서 갑자기 골드 무한복사 버그를 발견했습니다.
그런 급한 것들은 main 브랜치에서 hotfix 이런 브랜치 하나 만들어서 바로바로 버그수정하면 됩니다.
- 수정이 완료되면 main 브랜치에 직접 merge 하면 됩니다.
- 당연히 develop 브랜치에도 merge 해줘야합니다.
2.5 꼭 사용해야 함?
- 장점 : 안정적으로 버전별 배포 가능
- 단점 : CI/CD 이런거 하는 곳은 안좋아함
- 최근 continuous delivery 이런거 한 때 유행이었는데 그런거 할 땐 적합하지 않을 수 있습니다.
그래서 맨날 남들이 하는거 따라하지 말고 본인 마음대로 변형해서 쓰면 됨.
예를 들면, release 브랜치 쓰지 않고 바로 main 브랜치에 merge 해서 배포하거나 그래도 됩니다
그 선택에 합당한 이유와 근거가 있으면 됩니다. 물론 책임도 져야합니다.
3. runk-based 전략
만드는게 코드짠걸 바로 대중에 배포를 해도 상관없는 프로그램이면,
그리고 크게 대격변 업데이트를 안하는 안정적인 프로그램이면
굳이 많은 브랜치를 만들 필요가 없습니다. 그냥 main 브랜치와 기능추가용 feature 브랜치만 운영하면 됩니다.
이게 Trunk-based 전략입니다. Github Flow도 이거랑 비슷합니다.
3.1 브랜치 하나만 잘 관리
- 기능추가, 버그픽스가 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어서 코드짭니다.
- 브랜치마다 작명 잘하는게 중요합니다.
- 기능이 완성되었으면 main 브랜치에 합칩니다.
- 이제 브랜치 쓸데없으니 삭제합니다.
- main 브랜치에 있는 코드를 필요할 때 마다 유저들에게 배포합니다.
3.2 장단점
- 장점
- 코드를 한 브랜치에서만 관리하기 때문에 편리합니다.
- 크게 개발해서 한 번에 merge 하는 것 보다 작은 단위로 merge 하는 것이 더 안전합니다.
- 단점
- main 브랜치에 있는 코드가 뻑이나면 큰일나기 때문에 테스트나 코드리뷰를 자주해야합니다.
- 그래서 테스트를 자주하고 자동화해놓는 곳들이 제대로 사용가능합니다.
4. 결론
이미 어느정도 개발이 진척이 되었거나 프로들로 가득한 팀이면 Trunk-based 이런거 쓰는게 훨씬 편리합니다.
최근 유행한 CI/CD 이런 식으로 개발하는 곳들도 Trunk-based 개발방식을 적용합니다.
출시 버전의 안정성이 중요한 프로그램, 아직 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 Git Flow가 적절할 수 있습니다.
Q. merge 할 때 어떤 방법 쓰는게 좋은가요?
- 기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge
- 기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase 쓰면 됩니다.
취향일 뿐이고 알아서합시다.
