[GIT] Git Flow, Trunk Based

 

프로젝트가 커져도, 사람이 많아도 branch , merge 깔끔하게 하는 협업방식 : Git Flow, Trunk Based

 

 

GitFlow 전략

branch : (주브랜치) 1. main 2. develop  / (보조브랜치)  3. feature 4. release 5. hotfix

 

예를 들어 v1.0 신버전을 개발한다고 할 때 : 

1. main브랜치에 v0.9코드 commit해두고

2. 신기능코드를 넣을때, main 브랜치의 사본 develop을 만듭니다.

이렇게 되면 신기능을 develop에 넣기 때문에, 좀 더 안정적으로 개발이 가능합니다.

3. 하지만 develop 브랜치에 feature 브랜치를 만들어서 거기서 테스트해보고, develop 브랜치에 합치는 것이 더 안전합니다. 예를 들어 guild 기능이나, friend 기능이 필요하면 feature/guild , feature/friend 브랜치를 만들어 작업하고, 합치는 방식으로 진행합니다.

4. 어느정도 develop 브랜치 코드가 완성되었다 싶으면 main 브랜치에 바로 합체해도 좋지만, v1.0을 출시전에 테스트를 하기 위해 release 브랜치를 만들어 마지막 테스트가 완료되면 main에 합쳐서 main을 배포합니다.

5. 배포 후 유저들이 1.0v 에서 버그를 발견했을 때, hotfix 브랜치를 생성해 수정합니다.

 

Git Flow의 어려움

Vincent Driessen이 2010년에 Git Flow를 처음 제시했던 블로그 글을 보면, 그가 글을 작성한 지 10년 뒤인 2020년에 추가한 Note Of Reflection 을 확인할 수 있습니다.

이 부분에서는 Git Flow가 웹 앱(web apps) 개발을 염두에 두지 않고 만들어졌고, 적합하지 않다고 회고합니다. 즉 그의 말에 따르면 우리가 일반적으로 작성하는 백엔드, 프론트 애플리케이션은 Git Flow를 사용하기 적합하지 않다는 것이죠.

그렇다면 어떤 이유에서 Git Flow가 웹 앱 개발에 적합하지 않다는 것일까요? 제가 생각하는 Git Flow의 어려움은 아래와 같습니다.

브랜치 관리 규약이 복잡하다

A successful Git branching model 에서는 feature, release, hotfix 세 가지의 보조 브랜치가 어디서 생성될 수 있으며, 어디로 머지(Merge)되어야 하는지, 그리고 어떤 이름을 가질 수 있는지 상세하게 설명합니다. 이러한 규약을 익히는 것도 어려운 점 중 하나이지만, 규약으로 인해 브랜치 관리의 본질적인 복잡성이 증가하는 것 또한 문제가 됩니다. 이러한 복잡성을 보여주는 예시를 간단히 짚어보자면 아래와 같습니다.

• release 와 hotfix 브랜치를 머지하기 복잡합니다. 기본적으로 두 종류의 브랜치는 변경 사항이 덮어씌워지는 것을 방지하기 위해 master와 develop에 동시에 머지되어야 하며, 활성화된 release 브랜치가 있다면 이것도 신경써야 합니다.
• 새로운 작업을 feature 브랜치와 hotfix 브랜치 중 어떤 것으로 해야 할지 판단하기 어렵습니다. 일반적으로는 계획된 기능을 feature, 계획되지 않은 픽스를 hotfix로 하지만 이런 분류가 애매해지는 순간이 분명 존재합니다.
• hotfix에서 새로 발생한 변경 사항을 feature 브랜치에 적용하고 싶다면, 최소 3번의 머지가 필요합니다. (hotfix -> master, hotfix -> develop, develop -> feature)

브랜치가 오래 유지된다

Git Flow에서는 브랜치가 보통 오래 유지되고, 상대적으로 많은 변경사항을 한 번에 머지하는 것을 선호합니다.

이러한 선호는 여러가지 부작용을 같이 야기합니다.

먼저, 서로 다른 두 브랜치에서 독립적으로 작업을 하게 되면 동시에 수정한 부분이 생길 수 있는데, 이 때 두 브랜치를 머지하기 위해서는 Git 상에서 컨플릭트(merge할 경우 발생하는 충돌 문제)를 해결해야 합니다. 두 브랜치가 각각 독립적으로 오래 작업되었을수록, 컨플릭트는 보통 더 크고 해결하기 어려워집니다. 컨플릭트 해결 중 발생하는 휴먼 에러로 버그를 만들 확률 또한, 컨플릭트의 규모가 커질수록 같이 증가합니다.

 

그 뿐만이 아니라, 브랜치가 오래 유지되어서 변경사항이 많을수록, 동료 개발자가 변경사항에 대해 코드리뷰를 진행하기가 더욱 어려워집니다. 동료 개발자가 코드 퀄리티나 버그에 대한 피드백을 주기 어려워지면, 전체적인 개발 문화에도 영향을 주게 됩니다.

마지막으로, 브랜치가 오래 유지된다는 것은 자연스레 배포의 주기가 길어진다는 것을 의미합니다. 이는 운영 배포를 통해 실제 환경에서 새롭게 만든 코드와 기능에 대한 피드백을 받는 것을 어렵게 합니다.

 

---

 

Trunk-Based 전략

트렁크 기반 개발은 Git Flow의 대안으로서 주로 사용되는 브랜치 전략입니다.

main브랜치 하나만 운영합니다.

신기능이필요하다 → feature1, feature2 ... 같은 곁가지 만들어서 main에 합쳐 배포합니다.

 

장점 :

• 브랜치 관리에 드는 리소스가 대폭 절약됩니다. 개발자가 각자 자신이 맡은 피쳐 브랜치를 main 브랜치와 싱크를 맞추는 것만으로도 충분합니다.
• 며칠 단위로 main에 머지하기 때문에, 머지 시 발생하는 변경이 작아집니다. 따라서 컨플릭트는 보통 작거나 없고, 코드 리뷰도 용이합니다.
• 배포하기 위해서는 main에 머지하는 것만으로 충분합니다. 배포 프로세스가 간단해져서, 더욱 자주 배포할 수 있게 됩니다.

단점 :

• 소스코드 관리할 필요없는 장점이 있으나, 단점으로는 테스트를 자주해야 합니다.
• 만들고자 하는 기능이 몇 주 내지는 몇 달의 개발 기간이 필요한 큰 기능일 수 있습니다. 이런 상황에서는 트렁크 기반 개발의 실천법대로 며칠마다 메인 브랜치에 머지하기 어려워집니다.
• 만들고자 하는 기능 A가 다른 기능 B의 릴리즈에 의존적이라면, B 기능이 완료되기 전까지 A 기능도 배포하기 어렵습니다.
• 기능을 별도의 스테이지 서버에서 검증하고 배포하는 것이 아니라 바로 실서버로 배포하기 때문에, 잘못된 기능이 메인 브랜치로 머지될 위험이 증가합니다.

 

 

 

정리 출처 : https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/

정리 출처 : https://www.youtube.com/watch?v=EV3FZ3cWBp8