[Git] Git Branch 전략 어떤 걸 사용해야 할까?

1. 서론 - "Git Branch 전략 어떤 걸 사용하지?"

---

프로젝트 초기 기획 단계를 마치고 개발 단계에 들어가기 전에, 몇 가지 중요한 규칙과 설정을 정해야 했습니다. 여러 안건 중 Git Branch 전략을 선택하는 과정에 대해 공유해보려 합니다. 그리하여 과정 중 학습한 내용과 프로젝트에 도입한 전략과 왜 해당 전략을 선택하게 되었는지 생각을 공유해보려고 합니다.

 

2. Git Branch 전략

---

2 - 1. Git Branch 전략이 필요한 시점

개발을 처음 시작했을 때, Branch의 개념도 모르고 기본적으로 설정된 main 브랜치에 작업을 저장하며 프로젝트를 진행했습니다. 하지만 팀 프로젝트를 진행하면서 몇 가지 공통적인 문제점이 발생했습니다.

예를 들어, A와 B 개발자가 동시에 main 브랜치를 사용하면 A 개발자가 Push를 진행한 후, B 개발자가 Push를 시도할 때 충돌 문제가 발생하고 병합 여부를 물어보게 됩니다. Git Branch 전략을 알기 전에는, 이러한 상황에서 서로 메시지를 주고받으며 수정할 부분을 미리 논의한 뒤 Push를 진행하고, 다른 팀원에게 이 사실을 알린 후 병합하는 비효율적인 방식으로 작업을 이어갔습니다.

 

문제 발생 과정

1. A, B 개발자 동시에 main 브랜치에서 작업 진행
2. 작업을 마친 A 개발자가 main 브랜치에 Push
3. 그 후 B 개발자가 main 브랜치에 Push
4. Push 과정 중 문제 발생, 병합 및 리베이스 여부 선택

그리하여, 문제를 해결하기 위해 커뮤니티 질문으로 얻게 된 답변은 'Git Branch 전략 사용 권장'이었습니다.

2 - 2. Git Branch 전략 장점

Git Branch 전략을 사용하게 된 궁극적인 이유는 독립적인 작업을 위해서였지만, 이 외에도 여러 가지 장점이 존재합니다.

• 협업 효율성과 안전성
  • 여러 개발자가 동시에 작업할 때, 독립적인 작업 브랜치에서 수행해 팀원 사이에 발생할 수 있는 충돌을 최소화
  • 병합을 위해 PR 요청으로 다른 팀원들의 코드 리뷰와 지식을 공유 가능
• 코드 안정성 유지
  • 새로운 기능이나 버그들을 별도의 작업 공간에서 진행, 바로 주 브랜치에 업로드가 되지 않아 안정성을 보장
  • 병합 전 테스트나 검증으로 문제 초기에 발견 가능
• 개발 프로세스 체계화
  • 개발, 테스트, 릴리스 등의 단계를 명확히 구분하여 체계적인 관리에 용이
  • 특정 작업의 추적과 Rollback도 수행할 수 있어 프로젝트 관리에 유연성을 향상

 

2 - 3. Git Branch 전략 종류 

• Git Flow
• GitHub Flow
• GitLab Flow

Git Branch 전략은 여러 가지가 있지만, 여러 프로젝트에서 대중적으로 사용되는 2가지(Git Flow, GitHub Flow)를 살펴보겠습니다.

 

3. Git Flow

---

Git Branch 전략에 대해 자료를 탐색하다 보면, 다음과 같은 Workflow 이미지를 자주 보셨을 것입니다.

 

여러 프로젝트와 현업에서도 대표적으로 사용되는 Git Branch 전략 방식입니다. 위 사진을 처음에 보면 복잡하고 어지러우실 겁니다. Git Flow 방식은 체계적이면서도 복잡한 특징을 가지고 있습니다. 이러한 이유로 처음 접할 때는 어떻게 사용해야 할지 막막할 수 있습니다. 이제 Git Flow 전략에서 사용되는 주요 브랜치에 대해 살펴보겠습니다.

 

⚙️ Git Flow 주요 브랜치

• main : 출시된 제품의 버전을 관리하는 브랜치
• develop : 다음 출시될 제품의 버전 개발 브랜치
• feature : 새로운 기능 추가와 수정 부분 개발 브랜치
• release : 다음 정식 출시될 develop 브랜치의 최종 문서 작업과 테스트하는 브랜치
• hotfix : 긴급하게 수정에 사용하는 개발 브랜치

 

4. GitHub Flow

---

Git Flow Workflow

Git Flow 보다는 매우 간결해 보이는 전략 방식입니다. 프로세스도 매우 간결해졌으며, 사진으로만 봐도 이해하기 쉽습니다. 해당 전략은 지속적 통합에 초점을 맞춘 방식입니다. 그래서 신속한 배포가 큰 장점인 방법이라 할 수 있습니다. 주요 브랜치는 다음과 같습니다.

 

⚙️ GitHub Flow 주요 브랜치

• main : 출시된 제품의 버전을 관리하는 브랜치
• change : 새로운 기능이나 버그 수정 작업 개발 브랜치

change 브랜치 이름은 자유롭게 생성합니다.
다만, Git Flow처럼 명칭이 없으므로 어떤 작업을 하는지 의미가 분명한 명칭을 사용해 생성해야 합니다.

 

5. 결론 - "어떤 걸 사용하는 게 맞아?"

---

결론을 말씀드리기 전에, 두 전략을 비교한 표를 살펴보겠습니다.

특징	Git Flow	GitHub Flow
브랜치	main, develop, feature, release, hotfix	main, feature
목적	지속적인 유지보수와 크고 복잡한 프로젝트 관리	지속적인 배포와 변화에 신속하게 대응
협업 과정	코드 리뷰와 병합 과정이 체계적	코드 리뷰의 간소화, PR로 빠르게 처리
적합한 프로젝트	크고 복잡하며, 여러 팀원이 참여하는 프로젝트	작거나 중간 규모의 프로젝트, 빠른 변화가 필요한 프로젝트

결론적으로, 어떤 전략을 반드시 사용해야 한다는 법칙은 없습니다. 진행하려는 프로젝트의 규모와 협업 방식에 따라 전략은 달라질 수 있습니다. 필자도 "현업에서 사용하는 것을 경험해야 한다"는 생각을 했지만, 이는 틀린 생각입니다. 실제 현업에서도 두 방식 모두 사용되고 있으며, 프로젝트 상황에 맞게 전략을 선택하는 것이 중요합니다. 프로젝트 진행 도중에도 전략을 변경할 수 있습니다. 예를 들어, GitHub Flow -> Git Flow로의 변경, 또는 그 반대의 상황도 충분히 가능합니다.

 

필자가 현재 진행하는 프로젝트에서는 BE 파트의 개발자가 총 2명이고, 원활한 소통과 FE 팀과의 지속적인 회의를 통해 빠르게 대응하기 위해 'GitHub Flow' 방식을 채택했습니다. 추후 정식 릴리스 이후 제품이 복잡해지고 팀원이 늘어나 불편함이 생긴다면, 언제든지 'Git Flow' 방식으로 전환할 준비도 되어 있습니다. 👊

 

6. 참고(Reference) 📖

---

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

Understanding GitHub Flow and Git Flow