Git Branch 전략

• 깃 브랜치 전략은 왜 쓸까요?
  • 보편적으로 통용되는 브랜치 운용 방법
  • 다수의 개발자 간 협업 과정에서 제품 개발 및 배포를 원활하게 돕기 위해 사용
• 대표적인 Git Branch 전략
  • Git flow - git-flow cheatsheet
  • Trunk Based Development - Trunk Based Development
  • Github flow

 

Git Flow

• 일반적으로 master, develop, feature, release, hotfix 5개의 브랜치를 운영합니다. 이 중 가장 중요한 브랜치는 master와 develop 브랜치로, 나머지 브랜치는 팀 내 필요성에 따라 운영하기도 합니다.
  • master: 가장 근본이 되는 브랜치로 배포된 / 또는 당장 배포 가능한 제품의 코드를 가지고 있는 브랜치입니다.
  • develop: 메인 개발이 진행되는 브랜치로 출시 예정 버전의 개발이 진행되는 브랜치입니다. master 브랜치를 따 옵니다.
  • feature: 하나의 기능을 개발하는 브랜치로, 해당 기능이 개발 완료되면 develop 브랜치로 merge합니다. 보통 origin에 푸시하지 않고 로컬에서만 관리합니다.
  • release: master 브랜치로 배포를 보내기 전에 QA를 진행하기 위한 코드를 가지고 있는 브랜치입니다. 또는 이미 배포 나간 버전을 관리하기 위해 사용합니다. 추후에 marster 브랜치로 merge합니다.
  • hotfix: master 브랜치의 내용을 배포한 후에 버그가 생겼을 때 긴급 수정을 진행하는 브랜치입니다. 추후에 marster와 브랜치로 merge합니다.
• 장점:
  • CI/CD 적용이 용이합니다. master 브랜치에 푸시를 하면 즉시 프로덕션 배포를 시키는 형태로 많이 사용합니다.
  • PR(Pull Request)에 대한 꼼꼼한 검토가 가능합니다.
  • 저장소에 관여하는 사람이 많을 때 브랜치가 우후죽순 생겨나는 것을 막을 수 있습니다.
• 단점:
  • Git flow 전략에 대한 사전 지식이 있어야 합니다. 또한 빠르게 제품을 완성하고 싶을 때 해당 전략은 부적절 할 수 있습니다. (기본적으로 각 브랜치끼리 merge 할 때마다 PR을 거쳐 한다는 것이 전제이기 때문에…)
  • 사용하지 않는 브랜치가 생깁니다. 특히 release 브랜치는 master와 용도 구분이 다소 모호합니다.
  • 관리하는 브랜치 자체가 많고, merge하는 단위가 크다보니 merge시 충돌이 많이 발생합니다.

 

Trunk Based Development

• master 단일 브랜치를 중심으로 운용합니다. master 외의 브랜치를 만들지 않거나, 금방 지울 소규모의 작업용 브랜치를 생성해서 작업 후 master 브랜치에 merge하고 작업용 브랜치는 지웁니다.
• 장점:
  • 빠르고 유동적인 애자일 개발 방법론에 적합합니다. (PR을 하지 않습니다.)
  • 작은 규모로 단기 브랜치를 생성하고 빈번하게 master에 merge하여 대규모 충돌을 피합니다.
• 단점:
  • CI/CD를 적용한 경우, master 브랜치에 푸시된 내용은 즉시 프로덕션에 반영되기 때문에 master 브랜치에 변경사항을 반영하기 전에 철저한 테스트가 이루어져야합니다. 즉, master 브랜치의 내용은 항상 유효하면서 배포 가능한 상태여야 합니다.

 

깃 브랜치 전략, 꼭 써야 할까요?

• 조직 상황에 맞게 채택/사용하면 됩니다.
• 다만 범용적으로 통용되는 만큼 개념은 알아두면 좋습니다.
• @: 프로젝트 용량이 커질 경우 레포지토리를 브랜치처럼 쪼개서 다루는 방법도 존재

---

참고자료

Trunk-based Development vs. Git Flow

(알아두면 개발팀장가능) GitFlow vs Trunk-based 협업방식