Git 브랜칭 전략

1. 깃 브랜칭 전략

우리가 깃과 깃허브를 사용할 때 보통 혼자 개발하게 되면 레포지토리의 master 브랜치 하나에 작성한 코드를 기록한다. 이는 자신만의 규칙들을 정하고 그것을 따르기만 하면 문제가 생기지 않는다. 하지만 팀으로 프로젝트를 진행하면서 하나의 레포지토리에 코드를 기록하다 보면 배포용, 개발용의 구분과 같이 브랜치를 여러 개로 관리할 필요가 생기고, 이 브랜치를 규칙 없이 무분별하게 사용하게 되면 어떤 브랜치가 언제, 무엇을 위해 생성됐으며, 삭제되어야 하는데 방치되고 있는지, 아니면 이후 필요한 브랜치인지 정확히 알기 어렵다. 이에 따라서 깃 브랜칭 전략이 나오게 되었다. 

 

Git Branching 전략이란, 다수의 개발자가 1개의 저장소를 효과적으로 사용하기 위한 work flow이다. work flow인 만큼 회사별로, 조직별로 다르지만 어느정도 정형화된 모범사례가 있는데, 그중 두 가지가 Github flow, Git flow이다. 

---

2. Github flow

 

 

깃허브 플로우 공식 사이트에서 볼 수 있다. (https://docs.github.com/ko/get-started/quickstart/hello-world)

Github flow는 깃허브에서 만든 단순구조의 브랜칭 전략으로, 다음과 같은 특징을 가진다. 

• master 브랜치를 중심으로 운영한다.
• master 브랜치는 항상 stable 하고 배포 가능해야한다. 
• 기능개발, 버그 수정 등의 작업용 브랜치를 따로 구분하지 않는다. 
• 로컬에서 merge 하지 않고 꼭 PR을 통해 merge 해야 한다. 
• 수시로 배포가 일어나며, 웹과 같이 하나의 버전만 존재하는 프로젝트에 유용하다. 

1. 브랜치 생성
   
   • 모든 브랜치는 master 브랜치로부터 분기된다. 
   • 새로운 기능을 위한 브랜치를 Topic이라고 하며, 브랜치 이름은 increase-test-timeout, add-code-of-conduct 와 같이 정확하고 간결하게 작성한다. 
2. 기능 개발 및 버그 수정
3. Pull Request 생성
4. 리뷰 및 논의
5. 공개 및 테스트
   
   • 깃허브에서는 merge 전에 브랜치에서 코드를 공개 및 테스트 가능
6. merge

의 순서대로 작업이 진행된다. 

---

3. Git flow

Git flow는 2010년에 Vincent Driessen라는 분이 자신의 블로그에 올린 글이 인기를 끌며 사용된 전략으로, 다음과 같은 특징을 가진다. 

• 크게 master, develop, feature, release, hotfix 5개의 브랜치로 나눈다. 
• 5개의 브랜치를 메인 브랜치와 보조 브랜치로 구분한다. 
• 배포주기가 길고 팀이 QA나 테스트할 여력이 있는 경우에 적합하다. 

메인 브랜치:

• master, develop 브랜치가 있다.
• 위의 두 브랜치는 삭제되지 않고 항상 유지된다. 
• master 브랜치는 제품으로 배포할 수 있는 코드를 기록하는 브랜치이다. 
• develop 브랜치는 개발자가 개발하는 브랜치이다. 

보조 브랜치:

• feature, release, hotfix 브랜치가 있다.
• 각 브랜치는 분기 목적을 달성하면 삭제된다. 
• feature 브랜치는 특정 기능을 구현하기 위한 브랜치이며, 여러 브랜치가 있을 수 있다. 
• release 브랜치는 master 브랜치로 merge 하기 전 QA 및 배포 전처리를 위한 브랜치이다. 
• hotfix 브랜치는 master 브랜치에서 긴급 버그 발생시 처리하기 위한 브랜치이다. 

---

feature 브랜치

• 새로운 기능을 구현하기 위한 브랜치이다.
• develop 브랜치에서 분기가 되며, 사용을 마치면 develop 브랜치로 merge 한다. 
• 네이밍은 master, develop, release-*, hotfix-* 를 제외하고 가능하지만, 보통 구현할 기능에 대해 작성한다. 
• merge 할 때는 `git merge --no-ff deveop` 과 같이 --no-ff를 사용하여 기록을 따로 그룹화해둔다. 

 

https://koreabigname.tistory.com/65

 

--no-ff 란, 브랜칭 전략에서 merge할 때 사용을 권장하는 옵션이며, fast-forward 관계(과거 기록을 포함하는 관계)에 있어도 merge commit을 생성하여 해당 브랜치가 존재했다는 정보를 남긴다. 이는 commit 기록을 되돌리기 편하게 해준다.
원래는 --ff가 기본 옵션으로, merge 시 브랜치 존재여부를 몰라 어떤 commit에서 특정 기능을 구현했는지 확인이 어렵게 된다. 

 

 

 

---

release 브랜치

• 다음 버전 출시를 위해 QA를 진행하는 브랜치이다.
• develop 브랜치에서 분기되며, develop, master 브랜치로 두 곳 다 merge 한다.
• 네이밍은 release-* 로 하며, 보통 배포하게 될 버전을 붙인다. 
• release 브랜치를 둠으로써 배포 업무와 관련이 없는 팀원들이 병렬적으로 feature에서 기능을 구현할 수 있게 한다. 
• master 브랜치로 merge 후에는 특정 커밋을 커밋번호 대신 가리키는 꼬리표인 tag를 통해 배포된 버전을 명시한다. 

 

---

hotfix 브랜치

• 이미 배포된 버전에서 버그가 발생하면 이를 수정하기 위한 브랜치이다.
• master 브랜치에서 분기되며, develop, master 브랜치로 두 곳 다 merge 한다.
• 네이밍은 hotfix-*로 하며 release와 같이 수정 후 배포하게 될 버전을 붙인다. 
• release와 같이, 코드 수정 중에도 신 기능을 개발하는 팀원에게 영향을 주지 않는 장점이 있다. 
• master 브랜치로 merge 후에는 tag를 통해 이전 버전보다 높은 버전으로 명시한다. 

 

---

4. 마무리

크게 Github flow와 Git flow 2가지의 브랜칭 전략을 알아보았지만 다른 전략들도 많으며, 이중 어느 하나도 깃을 운용하며 생기는 문제를 완벽하게 해결해주지는 않으며, 이에 조직의 규모와 서비스의 특징 등을 고려하여 전략을 결정해야 한다. 

 

일반적으로 Production의 공식 배포주기가 길고 앱과 같이 여러 버전을 관리해야 하며, QA, 테스트, hotfix 등을 할 여력이 있다면 Git flow를 사용하는 것이 적합하다. 

하지만 지속적으로 테스트 및 배포를 하는 팀이고, 서비스가 웹앱과 같이 단일 릴리즈 버전만 존재하고, 팀의 규모가 작다면 Github flow가 적합하다. 

 

---

 

참고 링크

1. https://youtu.be/wtsr5keXUyE
2. https://youtu.be/jeaf8OXYO1g
3. https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html
4. https://koreabigname.tistory.com/65
5. https://nvie.com/posts/a-successful-git-branching-model/
6. https://hudi.blog/git-branch-strategy/
7. https://subicura.com/git/guide/github-flow.html#github-flow-%E1%84%87%E1%85%A1%E1%86%BC%E1%84%89%E1%85%B5%E1%86%A8
8. https://docs.github.com/ko/get-started/quickstart/github-flow
9. https://dongminyoon.tistory.com/39