[Git] 깃 브랜치 전략(Git Flow, Github Flow)(+TBD)

개발자들이 프로젝트를 진행하면서 협업할 때는 안정적이고 효율적인 프로젝트 관리를 추구해야 한다.

이때 깃 브랜치 전략을 도입한다면, 버전을 체계적으로 관리하고 충돌을 최소화할 수 있다.

대표적인 깃 브랜치 전략인 Git Flow, Github Flow와 TBD(Trunk-based Development)까지 알아보자 !

 

---

 

깃 플로우(Git Flow)

깃 플로우는 복잡한 프로젝트에서 브랜치를 체계적으로 관리하기 위한 브랜치 전략이다.

 

위 그림처럼 깃 플로우는 총 5가지의 브랜치 종류를 가지고 있다.

유지 기간에 따라 메인 브랜치(master, develop)와 보조 브랜치(hotfix, release, feature)로 나눌 수 있다.

(메인 브랜치는 항상 유지되는 반면, 보조 브랜치는 특정 작업이 진행되는 기간 동안에만 유지되는 브랜치이다.)

 

1. master: 버전 별로 출시한 제품을 관리하는 브랜치
2. release: 다음 출시 버전을 준비하기 위해 develop에서 분기하는 브랜치
3. hotfix: 출시한 제품의 긴급 버그를 수정하기 위해 master에서 분기하는 브랜치
4. develop: 다음 출시 버전의 개발을 진행하기 위해 master에서 분기하는 통합 브랜치
5. feature: 다음 출시 버전에 포함될 새로운 기능을 개발하기 위해 develop에서 분기하는 브랜치

깃 플로우는 이처럼 개발, 배포 준비, 긴급 수정이 모두 독립적인 브랜치에서 이루어진다!

따라서 각 브랜치의 제어를 통해 안정적으로(+체계적으로) 프로세스를 수행할 수 있다는 것이 장점이다.

하지만 대규모 프로젝트가 아니거나 배포를 자주 하는 경우에는 적합하지 않을 수 있다는 것이 단점이다.

 

---

 

깃허브 플로우(Github Flow)

깃허브 플로우는 깃 플로우보다 단순한 플로우를 가지고 있으며, 잦은 CI/CD 환경에 적합한 브랜치 전략이다.

 

깃허브 플로우는 master와 feature, 두 브랜치로 구성되어 있다.

1. master: 항상 배포 가능한 상태의 코드를 관리하는 브랜치
2. feature: 기능 개발과 버그 수정을 위해 master에서 분기하는 브랜치

feature 브랜치에서 작업을 완료 → Pull Request 검증 → master 브랜치로 병합(merge)하여 배포를 진행한다.

빠르게 배포가 가능하기 때문에 간단한 프로젝트에 적합하다는 장점이 있다.

 

---

 

TBD(Trunk-based Development)

TBD(Trunk-based Development)는 수명이 짧은 브랜치를 지속적으로 배포하는 개발 방식이다.

출처: https://www.optimizely.com/optimization-glossary/trunk-based-development/

 

1. master: 항상 배포 가능한 최신 상태를 유지하도록 관리하는 브랜치

기존 브랜치 전략처럼 feature 브랜치로 기능을 개발할 때, 오랜 시간이 소요될 수 있다.

이때, develop이나 master 브랜치로 병합(merge)을 하게 되면 충돌이 일어날 가능성이 높다!

이처럼 코드 검토 과정이 길어지는 단점을, TBD에서는 short-lived 브랜치들을 짧은 주기로 지속 병합함으로써 줄일 수 있다.

 

따라서 빠른 배포를 원하는 여러 기업들이 TBD 방식을 채택하고 있는 추세이다 :)

 

 

👏

 

참고

https://www.optimizely.com/optimization-glossary/trunk-based-development/

https://devocean.sk.com/blog/techBoardDetail.do?ID=165571&boardType=techBlog

https://donotlimityourself.tistory.com/42

https://techblog.woowahan.com/2553/