[Git] Git 브랜치 이름은 어떻게 정할까? - Git Flow로 브랜치 관리하기

부트캠프에서는 프로젝트를 진행할 때 STEP별 명세서를 받았다.

그래서 자연스레 브랜치 이름도 step1, step2... 등으로 네이밍했었다.

 

근데 직접 앱을 기획해보니 브랜치 이름을 어떻게 정할지 고민이 됐다.

'Git 브랜치 이름'을 키워드로 검색했더니, 온통 "Git Flow 전략"에 대한 자료만 나왔다.

Git Flow가 뭘까?

브랜치 모델 (Branch Model)이란 브랜치 이름, 브랜치별 임무를 규정한 것이다.

이 브랜치 모델 중 가장 유명한 게 Vincent Driessen가 만든 Git Flow이다.

 

프로젝트를 효율적으로 관리하기 위해

master, develop, feature, release, hotfix 5개 종류로 브랜치를 구분한다.

Git Flow

당장 위의 구조도를 모두 이해할 필요는 없다.

대부분의 작업은 feature -> develop -> release -> master 순으로 merge 시켜서 관리한다는 것만 알면 된다.

• feature : 새로운 기능을 개발할 때는 feature 브랜치에서 기능별 브랜치를 만들어 작업한다.
• develop : 기능 개발이 완료되면 해당 feature 브랜치를 develop 브랜치에 merge 시킨다.
• release : release 준비가 완료되면 develop 브랜치를 release 브랜치로 merge 시키고, release cycle을 진행한다.
• master : 최종 product를 release할 때는 release 브랜치를 master 브랜치로 merge 시키고, 해당 버전에 대해 Tag를 단다.
• hotfix : product release 이후 중요한 버그가 발생하면 hotfix 브랜치로 작업하고, develop 및 master 브랜치로 merge 시킨다.

Git Flow의 장점

• 브랜치가 자동으로 생성/삭제/merge 되어 편리하다.
• 브랜치 이름을 일관적으로 사용할 수 있다.
• 브랜치별 역할이 명확히 구분되어 있어 각 브랜치의 상태에 따라 배포 및 테스트를 진행하기에 용이하다.
  
  • feature 브랜치를 업데이트하면 unit test를 실행
  • develop에 merge request 발생 시 integration test와 slack 메시지 발송
  • develop 브랜치를 업데이트하면 개발 서버 배포 및 integration test 실행
  • release 브랜치 배포 시 relase 서버 배포 및 QA 팀에 메일로 전달
  • master 배포 시 실 서버 배포
• 승인된 개발자만 코드에 접근할 수 있게 해서 안전하게 소스코드를 관리할 수 있다
• feature 브랜치를 통해 기능 단위로 독립적인 개발이 가능하다.
  - 이때 PR을 활용하여 기능별 히스토리를 관리할 수 있다.
• feature 브랜치는 칸반 보드의 티켓과 연동되므로 기능별 추적이 쉽고, 오류 발생 시 특정 기능을 UNDO 시킬 수 있다.
• multi thread(배포 버전과 개발 버전 분리)가 가능하다.

Git Flow의 단점

찾아보니 단점으로 아래의 의견도 있었다.

• release 브랜치의 활용도가 낮다. (버전별 Tag가 존재하므로)
• master 브랜치의 활용도가 낮다. (develop 브랜치가 역할을 대신할 수 있다.)
• feature 브랜치 특성상 복수형인 features 네이밍이 적절하다.
• 브랜치 관리보다 적절한 커밋 단위를 설정하는 게 더 중요하다.

1. Git Flow 생성하기

Git Flow는 Git의 extension 기능이고, 별도 설치가 필요하다.

macOS 사용자는 터미널에서 아래를 입력하면 된다.

$ brew install git  // git을 미설치한 경우에만
$ brew install git-flow-avh

그다음 프로젝트 폴더 위치에서 git flow init을 입력하면 된다. (일반 git을 생성할 때 터미널에서 git init을 했듯이)

그러면 아래처럼 브랜치 이름을 입력하라는 안내가 뜨는데, 그냥 모두 Enter키로 넘기면 된다.

$ git flow init

Which branch should be used for bringing forth production releases?
   - develop
   - master
Branch name for production releases: [master]

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [/Users/projects/project1/.git/hooks]

설정이 완료되고 git branch -a를 찍어보면 아래처럼 develop, master가 생성된 게 보인다.

* develop
* master
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

2. Git Flow 사용하기

Feature

새로운 feature를 개발할 때

git flow feature start login 을 입력하면 자동으로 develop/feature/login 브랜치를 생성해준다.

 

해당 feature를 팀원과 협업하여 개발한다면

git flow feature publish login (일반 git처럼 git push를 입력해도 됨)

git flow feature pull origin login (일반 git처럼 git pull를 입력해도 됨)을 입력하여 주고받기하면 된다.

 

기능 개발이 완료됐다면

git flow feature finish login 을 입력하면 자동으로 login 브랜치를 develop에 merge 시키고, login 브랜치를 삭제한다.

Release / HotFix

브랜치 이름은 release-어쩌구 그리고 hotfix-어쩌구 형태로 네이밍한다.

---

필요한 상황에 따라 명령어를 찾아 쓰기만 하면 되므로 매우 간단하다.

명령어를 요약해둔 CheatSheet를 추천한다.

 

구체적인 사례와 팁은 이 링크를 활용하면 된다.

특히 Git 충돌 방지를 위한 팁은 이 링크를 추천한다.

 

- Reference

• Vincent Driessen의 A successful Git branching model
• Daniel Kummer의 Git Flow CheatSheet
• 생활코딩 > Git Flow - 출시와 개발을 동시에 진행하는 방법
• GitHub Docs > GIT을 기반으로 한 프로젝트 개발프로세스
• Blog - 우아한형제들 기술블로그 > 우린 Git-flow를 사용하고 있어요
• Blog - Jin의 Git Flow 사용법 요약 및 팁
• Blog - CouchCoding의 충돌 없는 Git을 위해 Git Flow에 대해 알아보자

 

🍎 포스트가 도움이 되었다면, 공감🤍 / 구독🍹 / 공유🔗 / 댓글✏️ 로 응원해주세요. 감사합니다.