[설계] Git Branch 전략이란? & Git Branch 전략 알아보기 (Git Flow, GitHub Flow)

🙇🏻‍♂️ 0. 들어가기 전 

이번 팀바팀 프로젝트에서 협업을 처음 경험하고,

 

Git Branch 전략에 대해 처음 들어보게 되었습니다.

 

이전까지는 협업을 하지 않고, 해봤자 페어 프로그래밍이 전부였기 때문에 Git Branch에 대해 신경쓰지 않았습니다.

 

팀원들께 죄송하게도, Git Branch 전략을 정하기 전에는 지식이 많이 없었습니다.

 

원래 정하기 전에 많은 것을 알아갔어야 하는데 반대로 되어버려서 죄송할 따름이네요,, 🙇🏻‍♂️

 

현재 팀바팀의 Git Branch 전략은 정한 상태이지만,

 

학습 측면에서 어떤 Git Branch 전략이 있는지 자세하게 알아보도록 합시다!

---

📘 1. Git Branch 전략이란? 

다양한 Git Branch 전략을 알아보기 전에, Git Branch 전략이 무엇인지 간략하게 알아봅시다.

 

Git Branch 전략이란, 말 그대로 Git Branch들에 전략, 즉 규칙을 부여하는 것입니다.

 

각 Branch는 어떤 Branch를 생성할지, 어디에서 생성할지 (분기할지), 어디로 병합할지 등등

 

각 Branch에 규칙을 정해놓고, 해당 규칙을 팀원들이 지켜가며 개발을 진행하는 것입니다. 

 

---

❓ 2. Git Branch 전략이 왜 필요해?

 

Git Branch 전략이 무엇인지는 알았는데, 왜 Git Branch 전략이 필요한 걸까요?

 

바로 팀원들간의 공통의 Branch 용어를 정하여 Git Branch에 대해 팀원들간의 공통의 이해를 달성하고,

 

더 나아가서 팀의 Git Branch를 효율적으로 관리할 수 있기 때문에 Git Branch 전략이 필요하다고 생각합니다.

 

두 가지 관점에서 살펴볼까요?

 

1. 팀원들간의 공통의 Branch 용어를 정하여 Git Branch에 대해 팀원들간의 공통의 이해를 달성

먼저, Git에 익숙하지 않은 팀원들이라고 가정해봅시다.

 

물론, Branch 이름들은 관례적으로 정해져있지만 팀원들이 생각한대로 생성한다고 가정해봅시다.

 

팀에게 '개발, 운영 서버를 다르게 배포하시오.' 라는 요구사항이 주어졌을 때,

 

팀원 A, B 모두 운영 서버를 main으로 두고 개발 서버는 브랜치를 생성하여 관리한다고 해봅시다.

 

팀원 A는 해당 브랜치의 이름을 main의 하위 개념으로 'sub'로 생성하고,

 

팀원 B는 해당 브랜치의 이름을 또 다른 main의 개념으로 'another-main'으로 생성한다고 해봅시다.

 

다른 팀원들, 팀원 A, B는 각각 해당 브랜치의 이름을 보고 공통된 이해를 할 수 있을까요?

 

Git Branch 전략을 사용하면 각 Branch가 어떤 역할을 하는지 팀원들 모두의 공통의 이해를 가지게 됩니다.

 

이렇듯 Git Branch의 컨벤션을 정하는 느낌으로 팀원의 Branch에 대한 공통적인 이해를 가지게 되는 장점이 있습니다.

 

 

2. Git Branch를 효율적으로 관리

그렇다면, Git Branch의 이름 컨벤션만 지키게 되면 공통의 이해를 가졌으니 괜찮을까요?

 

개발 브랜치의 이름을 'develop'으로 하기로 하고,

각자 작업은 'feature' 브랜치라는 이름을 컨벤션으로 정했다고 해봅시다.

 

이때, Git Branch 전략이 없으면 다음과 같은 문제가 발생할 수 있습니다. 

 

• 팀원 A는 feature 브랜치를 main에서 생성, 팀원 B는 feature 브랜치를 develop에서 생성
• 팀원 A는 feature 브랜치를 main에 병합, 팀원 B는 feature 브랜치를 develop에 병합

이런 상황이 지속되면 Git Branch의 커밋들이 마구잡이로 쌓이게 되고 꼬이게 되어

추적하기가 상당히 힘들 것입니다.

 

어떤 브랜치를 쓸지는 정했지만, 각 Branch의 전략을 정하지 않아서 관리가 되지 않는 것입니다.

 

이렇듯, Git Branch 전략을 확실히 하지 않으면 예상과 다른 팀원의 작업을 경험할 수 있습니다.

 

Git Branch 전략을 사용하게 되면, 각 Branch들의 규칙이 생기기 때문에 효율적으로 관리할 수 있습니다.

---

🚀 2. 다양한 Git Branch 전략

그렇다면 Git Branch들에 규칙들은 어떤 규칙들을 적용해야 할까요?

 

물론 팀원들끼리 정하여 자유로운 규칙을 정해도 되지만,

 

기존에 관례적으로 사용되는 Git Branch 전략을 사용한다면 공통의 이해를 가지기 쉬울 것입니다.

 

그래서 여기서는 관례적으로 사용되는 Git Branch 전략인

Git Flow, Github Flow에 대해 간략하게 살펴보려고 합니다.

 

 

✅ 2-1. Git Flow

Git Flow는 Vincent Driessen이 2010년에 제시한 Git 브랜치 전략입니다.

 

https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

Git Branch 전략을 한 번이라도 찾아본 적이 있다면, 아래의 그림을 본 적이 있을 것입니다.

Git Flow 도식화 그래프

 

그래프에서 한 줄이 브랜치 하나를 의미합니다.

 

그래프만 봐도 브랜치가 많고, 규칙들이 복잡해보이는 것을 알 수 있습니다.

 

간단하게 각 브랜치에 적용된 규칙, 전략들을 알아보도록 하겠습니다.

 

• main : 운영환경에 배포될 수 있는 코드를 모아둔다.
• develop : 다음 버전 기능이 담긴 코드로, 기능을 운영환경에 업데이트 할 때 main으로 merge한다.
• feature : 새로운 기능을 개발하기 위한 브랜치로, develop 브랜치에서 생성하고, 기능 개발이 완료되면 develop으로 merge한다.
• release : 새로운 버전의 배포를 위한 브랜치로, develop 브랜치에서 생성하고, 배포 전 버전 이름 등 사소한 데이터 수정 및 버그를 수정하기 위해 사용된다. 배포 준비가 완료되면 main, develop에 둘 다 merge한다.
• hotfix : 운영환경에 빠르게 수정해야할 버그가 있을 때 main을 빠르게 변경하기 위해 사용한다. main 브랜치에서 생성하고 버그 수정이 끝나면 main, develop에 merge한다. 

 

이러한 규칙을 가진 Git Flow는 모바일 애플리케이션 개발에 적합한 Flow이고,

 

웹 애플리케이션 개발에는 적합하지 않은 Flow입니다.

 

이러한 부분은 Git Flow를 제시했던 Vincent Driessen가 10년 뒤인 2020년에 언급한 글을 보면 알 수 있습니다.

Git Flow의 단점

 

해당 글에서는 일반적으로 웹 애플리케이션은 롤백이 되지 않고, 다양한 버전을 제공할 필요가 없다고 설명하고 있습니다.

 

모바일 애플리케이션을 생각해보면 다양한 버전이 존재하고, 롤백이 잦은 상황임을 알 수 있습니다.

 

하지만, 웹 애플리케이션을 생각해보면 배포를 하는 동안 항상 최신 버전으로 유지하며

 

롤백보다는 버그를 수정하는 일이 많음을 경험상, 직관적으로 알 수 있습니다.

 

이러한 상황에서 Git Flow를 사용한다면, 거의 사용하지 않을 브랜치의 규칙도 학습해야하므로 상당히 비효율적일 것입니다.

 

또, 브랜치가 많아서 이점을 얻기 보다는 개발자의 혼란을 가중시킬 수 있습니다.

 

Vincent Driessen은 글 마지막 부분에 GitHub Flow를 대안으로 제시하고 있습니다.

 

그렇다면, GitHub Flow는 어떤 전략일까요?

 

 

✅ 2-2. GitHub Flow

 

GitHub Flow의 공식 문서는 다음과 같습니다.

https://docs.github.com/en/get-started/quickstart/github-flow

GitHub flow - GitHub Docs

 

GitHub Flow에는 브랜치가 2개 밖에 존재하지 않습니다.

github flow 그래프

간단하게 해당 브랜치에 적용된 규칙을 살펴보겠습니다.

 

Github Flow는 main 브랜치만 엄격한 규칙을 적용하고, 나머지 브랜치는 별다른 규칙이 존재하지 않습니다.

 

임의로 만든 그래프에서는 Git Flow의 Feature 브랜치명을 가져왔지만, 

 

Github Flow에서 main을 제외한 나머지 하나의 브랜치는 자유롭게 생성이 가능합니다.

 

• main : 언제든 배포가 가능한 상태를 유지해야 한다. main으로 merge하기 전에는 엄격한 테스트를 거쳐야 한다. (CI 필수)
• 나머지 브랜치 하나 : main에서 생성하며 이름, 규칙 등 자유롭게 결정한다. 이때, 브랜치 명과 커밋 메시지는 어떤 일을 하고 있는지 자세하게 작성해야 한다.

 

Github Flow의 전체 Flow는 다음과 같습니다.

github flow 배포

1. main에서 새로운 branch를 생성한다. 이때, 브랜치 명은 어떤 일을 할지 자세하게 작성한다.

2. 생성한 브랜치에서 작업이 끝나면 main으로 PR을 작성한다.

3. PR 리뷰가 끝나고 main으로 merge를 할 때 CI/CD를 거쳐서 배포를 진행한다.

 

이렇듯, main에는 항상 배포가 가능한 안정적인 코드가 존재하는 것이 핵심입니다!

 

앞서 Git Flow와 비교했을 때 엄청나게 간단한 것을 알 수 있습니다.

 

저도 Git Flow를 이해하는 시간보다 GitHub Flow를 이해하는 시간이 훨씬 적었습니다.

---

🔮 3. Git Flow와 GitHub Flow 중 무엇을 사용할까?

 

Git Flow와 GitHub Flow 두 전략 다 알아본 결과,

 

다음과 같이 요약할 수 있을 것 같습니다.

 

* Git Flow

- 브랜치 수가 많고 여러 규칙이 있는 만큼, 규모가 큰 프로젝트에서 적합하다.
- 배포 주기가 잦지 않은 프로젝트에서 적합하다.
- 다양한 버전 관리가 필요한 모바일 애플리케이션에서 적합하다.

* GitHub Flow

- 규칙이 있는 브랜치가 main 뿐이고 간단한만큼 비교적 규모가 적은 프로젝트에서 적합하다.
- 수시로 배포가 일어나서 잦은 배포 주기를 가지는 프로젝트에서 적합하다.
- git에 익숙하지 않은 사람이 있을 때 경험해보기 좋다.