git flow

한 번만 천천히 읽으면 이해가 되는 거 였다..

주요 브랜치

• master
  • 항상 production-ready 상태를 유지하는 브랜치
• develop
  • 다음 출시(release)를 준비하는 브랜치
  • 출시할 준비가 되면 master브랜치로 병합(merge) 후 릴리즈 번호를 태그로 지정

지원 브랜치

주요 브랜치(master, develop)와는 달리 제한된 수명을 가진다.
팀원간 병렬 개발, 기능 추적, 신속한 버그 수정 등을 담당한다.

• feature
  • develop브랜치로부터 생성
  • 새로운 기능을 개발할 때 사용
  • 기능 개발 시작 시 브랜치를 생성하고, 개발이 완료되면 develop브랜치로 병합 후 제거
  • 개발자의 local repository에만 존재

먼저 기능에 관련된 이름의 브랜치를 생성한다. 주로 feature/[개발할 기능]형식을 많이 사용하는 듯?
중요한 점은 develop브랜치에서 생성해야 한다는 점!

$ git checkout -b feature/sign-up 
$ git switch -c feature/sign-up

git switch -c [브랜치명]는 브랜치를 생성함과 동시에 해당 브랜치로 이동한다.

기능 개발이 완료되면 develop브랜치로 병합한다.
이 때 --no-ff옵션을 꼭 붙인다.

$ git switch develop

# feature -> develop 병합
$ git merge --no-ff feature/sign-up

# 브랜치 삭제
$ git branch -d feature/sign-up

--no-ff옵션은 fast-forward를 하지 않겠다는 뜻. 항상 새로운 커밋 객체를 만들어 병합한다.
브랜치의 과거 정보가 손실되는 것을 방지함

• release
  • develop브랜치로부터 생성
  • 새 프로덕션 릴리즈를 준비(출시 버전을 준비)
  • develop과 master브랜치에 병합 후 제거

릴리즈 브랜치도 생성할 때 develop브랜치로부터 생성해야 한다.

$ git switch -c release/1.2

릴리즈 브랜치가 실제로 릴리즈 될 준비가 되면, master와 develop브랜치에 병합 후 release브랜치는 제거한다.

$ git switch master
$ git merge --no-ff release/1.2

# 태그 수정
$ git tag -a 1.2


$ git switch develop
$ git merge --no-ff release/1.2

$ git branch -d release/1.2

• hotfix
  • master브랜치로부터 생성
  • 서비스 중인 프로덕션 코드에 긴급한 수정사항이 있을 경우
  • develop과 master브랜치에 병합 후 제거
  • hotfix브랜치에서 작업하는 동안 develop브랜치도 함께 병렬작업이 가능함

master브랜치로부터 hotfix브랜치를 생성한다.
현재 서비스 중인 버전이 1.2라면, 1.2.1로 브랜치명을 정한다.
그리고 hotfix브랜치에서 버그를 수정한다.

$ git switch -c hotfix/1.2.1

버그 수정이 완료된 후 master와 develop브랜치에 병합 후 hotfix브랜치는 제거한다.

$ git switch master
$ git merge --no-ff hotfix/1.2.1
$ git tag 1.2.1

$ git switch develop
$ git merge --no-ff hotfix/1.2.1

$ git branch -d hotfix/1.2.1

---

참고

• A successful Git branching model
• 우린 Git-flow를 사용하고 있어요
• [생활코딩 youtube] git flow model 강추!!