•
브랜치를 어떻게 잘 써먹어볼까에 대한 얘기를 해보기 전에 먼저 우리는 브랜치를 왜 사용할까?
◦
개인적인 측면에선
▪
메인 브랜치에서만 작업을 수행한다면 하나의 커밋 단위가 완성되기 전까지는 빌드가 안 되거나 불완전한 기능이 남아 있을 것이다.
◦
협업을 하게 된다면
▪
메인 브랜치에서 수 많은 개발자들이 협업한다면 내가 작업하고 있는 파일을 누군가가 건들게 될 것이고 충돌을 일으킬 것이다.
▪
여러 기능을 개발하면서 남겨진 커밋 히스토리가 시간 순서대로 메인 브랜치에 뒤죽박죽 섞이게 될 것이다.
•
하나의 단위가 명확하게 분리되지 않았기 때문에 롤백도 어려워진다.
◦
브랜치 기능을 사용한다면
▪
다른 브랜치의 변경사항에 영향을 받지 않는 독립적인 환경에서 개발을 진행하거나 버그를 잡을 수 있다.
▪
여러 기능을 여러 사람이 병렬적으로 개발할 수 있게 된다.
•
이처럼 이롭기만 해보이는 브랜치를 마구잡이로 사용한다면 혼란을 불러올 수 있다.
•
브랜치 관리에 명확한 기준이 없다면 다음과 같이 혼란을 일으킬 소지들이 있다.
◦
이 브랜치는 어떤 목적으로 생성된거지?
◦
이 브랜치는 어떤 커밋 시점에서 분기된거지?
◦
어떤 브랜치에서 내 브랜치를 분기시켜야하지?
◦
내 브랜치는 어디에 병합해야하지?
◦
어떤 브랜치가 최신이지?
◦
어떤 브랜치가 배포된 버전이지?
•
Git 브랜치 전략은 프로젝트의 Git 브랜치들을 효율적으로 관리하기 위한 워크플로우다.
Git Flow
•
Git Flow는 크게 Main, Develop, Supporting 브랜치로 구분하여 관리한다.
◦
Supporting 브랜치는 또 다시 Feature, Release, HotFix 브랜치로 나뉜다.
◦
Main 브랜치와 Devleop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되어야하는 브랜치다.
◦
반면 Supporting 브랜치는 필요할 때마다 생성되고 역할을 다하면 삭제된다.
•
Main 브랜치
◦
출시 가능한 프로덕션 코드를 모아두는 브랜치이다.
◦
프로젝트 시작 시 생성되며 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해둔다.
•
Develop 브랜치
◦
다음 버전 개발을 위한 코드를 모아두는 브랜치이다. 개발이 완료되면 Main 브랜치로 머지된다.
•
Supporting 브랜치
◦
Feature 브랜치
▪
하나의 기능을 개발하기 위한 브랜치다.
▪
Develop 브랜치에서 파생되며 기능이 개발 완료되면 Develop 브랜치에 머지된다.
▪
머지할 때 주의점은 FastForward로 머지하지 않고 Merge 커밋을 생성하며 머지를 해주어야 한다. 이렇게 해야 히스토리가 특정 기능 단위로 묶인다.
▪
네이밍은 feature/branch-name와 같이 한다.
◦
Release 브랜치
▪
배포를 준비하기 위한 브랜치이다.
▪
Develop 브랜치에서 생성하며 버전 이름 등의 소소한 데이터를 수정하거나 배포 전 사소한 버그를 수정하기 위해 사용된다.
▪
이런 작업들이 완료되었다면 Main과 Develop 브랜치에 둘다 머지한다. 이때 Main 브랜치에는 태그를 이용해 버전을 표시한다.
▪
Release 브랜치를 따로 운영하므로써 배포와 관련 없는 팀원들은 다른 기능을 개발할 수 있다.
▪
네이밍은 release/v1.1과 같은 형태로 생성한다.
◦
HotFix 브랜치
▪
이미 배포된 버전에 문제가 발생했다면 사용하는 브랜치다.
▪
Main 브랜치에서 생성하며 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 머지한다.
▪
네이밍은 hotfix/v1.0.1과 같은 형태로 생성한다.
•
Git Flow의 한계
◦
Git Flow는 명시적으로 버전관리가 필요한 스마트폰 어플리케이션, 오픈소스 프로젝트 등에 적합하다.
◦
웹 어플리케이션은 특성상 사용자가 항상 최신의 버전만 사용하기 때문에 여러 버전을 병렬적으로 지원할 필요가 없다.
◦
또한 하루에 몇 번이고 배포될 수 있으므로 이런 특성상 웹 어플리케이션에 Git flow는 다소 적합하지 않다.
GitHub Flow
•
Main 브랜치
◦
항상 안정된 상태여야 한다.
▪
안정된 상태라는 것은 모든 커밋이 언제 배포되든 문제없어야 하고 브랜치를 새로 분기하더라도 문제가 없어야 한다는 것이다.
◦
Main 브랜치의 모든 커밋은 빌드가 되고 테스트를 통과해야 한다.
◦
GitHub Flow에서 유일하게 강제하는 사항이다.
•
Topic 브랜치
◦
새로운 기능을 개발할 때는 Topic 브랜치를 Main 브랜치로부터 생성하여 사용한다.
▪
Git Flow의 Feature 브랜치와 동일한 역할을 하며 Git Flow의 HotFix 브랜치의 역할도 수행한다.
◦
Topic 브랜치의 네이밍은 기능을 설명하는 명확한 이름으로 결정한다.
▪
user-content-cache, submodules-init-task, redis2-transition
◦
Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 푸쉬한다.
▪
이를 통해 개발자들이 끊임없이 코드에 대한 커뮤니케이션이 가능해진다.
◦
개발이 완성되고 풀 리퀘스트를 날리는 것이 아닌 스크린샷, 아이디어를 공유하고 싶을 때도 PR을 개설한다.
◦
토론과 리뷰가 종료되었다면 어프로브를 받고 Main 브랜치에 Topic 브랜치를 머지한다.
▪
이때 Topic 브랜치는 자동화된 CI 빌드를 통과해야 머지가 가능하다.
•
개발팀이 소규모 애자일 팀이고 제품이 하나의 배포 버전만 유지한다면 GitHub Flow가 적합하다.
