Git Branch 전략 / Git Workflow 전략

개요

Git Branch 전략을 세움에 있어 고려해야될 사항이 몇 가지 있다.

소통 (communication) 비용

여러 사람이 협업을 편하기 하기 위한 git인데 push 할 때마다 메신저로 '지금 머지하겠습니다' 또는 '배포해도 될까요'를 매번 물어보는 것 또한 경제학에서는 비용으로 계산된다.

병렬 (parallel) 개발

여러 개발자들이 동시에 여러가지 feature를 개발할 수 있어야 한다.

short lifetime of branches

브랜치는 필요에 따라 만들고 빨리 merge후 삭제되어야한다. 작년에 어떤 SI에서는 브랜치가 300개가 넘도록 방치되는 것도 본 적이 있다. 모든 개발자가 main의 최신 버전을 가지고 있다고 가정하면 main과 merge가 자주 되어야지 추후에 복잡한 merge conflict를 예방할 수도 있다.

 

1. Git Flow

Git workflow를 잘못 쓴 게 아니고 workflow 의 종류 중 하나인 고유명사이다.

 

 

위 방법은 develop branch에 아직 release되지 않은 최신코드가 있으므로, feature 개발 단계의 입장에서 봤을 때 develop을 main처럼 다루게 된다. → 즉, develop과 main 두 개의 branch는 삭제되지 않고 영원히 남아있는 전략이다.
release branch가 정상적으로 배포되었다면, QA를 통해 release에서 안정성 테스트를 하고, 최종 코드는 develop과 main으로 merge한다.
hotfix는 정기적인 업데이트가 아닌 긴급히 기능적인 결함이나 보안 취약점을 해결하기 위해 사용된다.

 

장점

• 여러 개발자가 동시에 작업하고 서로의 작업에 영향을 주지 않아 병렬 개발이 가능하다

단점

• 작은 프로젝트 (약 10명 정도 개발자)에게는 지나치게 복잡한 구조
• 어떻게 보자면 git flow는 아주 이상적이고 논리적인 workflow다. 그러나 문제는 우리는 이상적인 세계에 살고 있지 않다. 많은 개발자가 있을 때 누군가 브랜치 하나를 오염시키면 문제가 복잡해진다.

 

2. Github flow / TBD (Trunk-Based Development)

 

• main branch에서 바로 따서 feature를 개발.
• feature2가 먼저 개발이 완료되면 main에 merge하고, 최신 main을 feature1에 다시 merge
• hotfix도 하나의 feature처럼 처리

장점

• 소규모 개발에 용이와 충돌 최소화

단점

• 복잡한 배포 요구사항이 있을 때는 다른 전략을 고려해야되서 소통 비용이 증가
• CD(continuous deployment)의 자동화가 어렵고, 소통 비용이 많이 발생할 수 있다.

 

3. SimGit Flow

위의 Git Flow와 Github Flow의 중간 단계라고 보면 된다.
SimGit Flow라는 이름은 스타트업 회사 Omnevue의 CTO인 Andrew Winnicki가 2022년 이 글 https://levelup.gitconnected.com/better-git-branching-strategy-multi-apps-monorepos-and-multiple-teams-in-focus-cd17b56962f2 에서 제안하였다.
아래 그림에서 feature는 merge를 하는 순간 삭제하는 것이 좋지만, 이 글에서 버전 관리를 위해서 release branch는 (그림에는 표시 안 되었지만) 남겨두는 것이 더 좋다고 한다.
main branch는 tag를 남기는 것이 좋지만 가독성을 위해 tag없이 branch 전략으로 갔다고 한다.

 

 

• main branch - 항상 source of truth

장점

• 더 직관적인 전략

단점

• 개발자들이 어떤 release 버전이 진행 중인지 모니터링 해야한다. - 이는 특정 요일에 새로 따고 merge하는 약속을 정해놓는 것으로 극복이 가능하다.

 

예시 1

feature2 개발이 늦는다면? → merge된 main branch를 가져와 feature2에 반드시 merge 한다.

 

release가 main에 merge되면 남아있는 개발 진행 중인 feature branch에 merge 될 수 있도록 한다.

 

배포 서버

dev, stg, prd 서버가 3개 있다.
prd는 main, stg는 최신 release branch를 배포하면 된다.
dev는 협업 인원이 많다고 하면 develop branch를 하나 생성해서, dev에 배포되는 것은 develop branch로 국한 시킬 수도 있지만, 보통 그냥 dev용 Jenkins에서 바로 feature branch를 배포하면 된다.