Git-flow 이해하기

1. Git Repository

1.1 구성

Upstream remote repository

• 개발자들이 공유하는 저장소
• 최신 코드가 저장되어 있는 원격 저장소

Origin remote repository

• upstream remote repository를 fork한 원격 개인 저장소

Local repository

• 개발자 각자의 컴퓨터에 저장되어 있는 개인 저장소

1.2 gitflow를 적용할 워크플로우 예시

• local repository에서 작업 완료 후 작업 브랜치를 origin repository에 push
• origin reporistory에 push 한 브랜치는 upstream repository로 merge 하는 pull request 생성
• 코드 리뷰 후 upstream remote repository로 merge
• 해당 작업은 마무리되고, 새로운 작업 시작 시 , local repository에서 upstream repository를 pull

2. Git-flow

2.1 브랜치 종류

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치 
  • develop 브랜치에서 생성, develop 브랜치로 merge
  • --no-ff: 새로운 커밋 객체를 생성하면 merge 하기 위한 옵션

// develop 브랜치에서 feature 브랜치 생성해서 체크아웃 
$ git checkout -b myfeature develop

// 기능 개발 완료 후 develop 브랜치로 merge 
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop

• release : 이번 출시 버전을 준비하는 브랜치
  • develop 브랜치에서 생성, develop과 master 브랜치로 merge
  • naming convention: release-*
  • 커밋 이후, 실제 배포되기 전까지 삭제하지 않고 버그 수정을 release 브랜치에 반영
  • 새로운 큰 기능을 추가하는 것은 엄격히 금지 → 새로운 기능이 추가되어야 한다면 develop 브랜치로 merge 되어 다음 release를 기다려야 함

// develop 브랜치에서 release 브랜치 생성 후 checkout 
$ git checkout -b release-1.2 devleop

// 새로운 버전에 반영할 작업 반영 (ex) using shell script) 

$ git commit -a -m "Bumped version number to 1.2"

// 실제 배포가 가능해진 다음,
$ git checkout master 
$ git merge --no-ff release-1.2
$ git tag -a 1.2

// 배포 이후, develop 브랜치에도 merge 하고 release 브랜치 삭제
$ git checkout develop
$ git merge --no-ff release-1.2
$ git branch -d release-1.2

• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
  • master 브랜치에서 생성
  • naming convention: hotfix-*
  • 현재 배포된 상품의 버전이 1.2인 경우, hotfix-1.2.1 브랜치

// master에서 hotfix 브랜치 생성 후 체크아웃
$ git checkout -b hotfix-1.2.1 master

// 버그 수정

// 커밋
$ git commit -a -m "Bumped version number ro 1.2.1"
$ git commit -m "Fixed severe production problem"

// master로 merge 후 태그 달기
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1

// develop도 hotfix 브랜치 merge
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1

// hotfix 브랜치 제거
$ git branch -d hotfix-1.2.1

 

2.2 개발 흐름

• master 생성
• master에서 develop 브랜치 생성
• develop 브랜치
  • 상시로 버그 수정한 커밋 추가
  • 새로운 기능 추가 작업 있는 경우 develop에서 feature 브랜치 생성
  • 기능 추가 작업 완료 후 feature 브랜치 develop 브랜치로 merge
• 모든 feature 브랜치가 merge 되었다면 develop에서 release 브랜치 생성
  • QA를 진행하며 발생한 버그들은 release 브랜치에서 수정
  • QA 통과 후 release 브랜치를 master, develop 브랜치로 merge
• master 브랜치에 버전 태그 추가

2.3 example

case1)

작업 티켓 중 '로그인 레이아웃 생성' 티켓을 처리하는 상황을 가정한다.

• upstream/feature-user 브랜치: 사용자 관련 기능을 구현하는 feature 브랜치
• feature-user 브랜치에서 bfm-100_login_layout 생성

// feature-user브랜치 에서 fetch : upstream 브랜치와 동기화 (pull과 같은데 merge 하지 않음) 
$ git fetch upstream 

$ git checkout -b bfm-100_login_layout --track upstream/feature-user

• bfm-100_login_layout 브랜치에서 코드 수정 후 변경 사항 커밋

$ git commit -m “BFM-100 로그인 화면 레이아웃 생성”

• 커밋이 불필요하게 여러 개로 나뉘어진 경우 → squash (커밋 그래프를 단순하게 유지하기 위한 작업)

// N: 합칠 커밋의 개수 
$ git rebase -i HEAD~N

• 작업 브랜치를 upstream/feature-user에 rebase

$ git pull --rebase upstream feature-user

• 작업 브랜치를 origin 에 push

$ git push origin bfm-100_login_layout

• bfm-100_login_layout 브랜치를 feature-user에 merge하는 Pull Request를 생성
• 같은 feature를 개발하는 동료에게 리뷰 승인을 받은 후 자신의 Pull Request를 merge

case2)

develop 변경사항을 feature로 가져오기 (optional)

• feature 브랜치 개발 작업을 하는 동안 develop에 추가된 기능을 가져와야 하는 경우
• 해당 feature 브랜치에서 upstream/develop 브랜치를 merge

$ git fetch upstream
$ git merge --no-ff upstream/develop

• upstream/develop 변경사항이 merge 된 feature 브랜치를 upstream에 push

$ git push upstream feature-user

case3)

feature에서 완료된 기능을 출시 버전에 포함시키기

• feature 브랜치 기능 개발 완료 후 develop 브랜치에 merge
• develop 브랜치에서 feature 브랜치 merge

$ git fetch upstream 
$ git merge --no-ff upstream/feature-user

• feature 브랜치가 merge된 develop 브랜치를 upstream으로 push

$ git push upstream develop 

case4)

이번 버전 출시 전 코드 리뷰 시작하기

• 출시 담당자가 release 브랜치 생성하고 upstream에 push 하여 release 브랜치 공유
• develop 브랜치에서 release 브랜치 생성

$ git checkout -b release-1.0.0 --track upstream/develop

• release-1.0.0에서 upstream에 push

$ git push upstream release-1.0.0

case5)

코드 리뷰 중 버그 수정하기

• 버그 발생시마다 버그 티켓 생성 → 티켓 모두 해결해야만 출시 가능
• release 브랜치에서 버그 티켓에 대한 브랜치 생성

$ git checkout -b bfm-101_bug_login_id_max_length

• 버그 수정
• 버그 수정 작업 브랜치에 수정 사항 커밋

$ git commit -m “BFM-101 로그인 아이디 길이 제한 버그 수정”

• 버그 수정 작업 브랜치를 origin 브랜치로 push

$ git push origin bfm-101_bug_login_id_max_length

• bfm-101_bug_login_id_max_length 브랜치를 해당 출시 release 브랜치에 merge 하는 Pull Request를 생성
• 리뷰 승인 받은 후 pull request merge

case6)

버그 티켓 모두 해결 후 출시

• release 브랜치를 master, develop 브랜치에 merge 하고 master 브랜치에 버전 태그 달아줌
• release 브랜치를 버그가 모두 수정된 최신 상태로 갱신

$ git pull upstream release-1.0.0

• release 브랜치를 develop 브랜치에 merge

$ git checkout develop 
$ git pull upstream develop
$ git merge --no-ff release-1.0.0

• develop 브랜치를 upstream에 push

$ git checkout master 
$ git pull upstream master 
$ git merge --no-ff release-1.0.0

• master에 태그 추가

$ git tag 1.0.0

• master 브랜치와 1.0.0태그를 upstream에 push$ git push upstream master 1.0.0

$ git push upstream master 1.0.0

 

---

References

• https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
• https://nvie.com/posts/a-successful-git-branching-model/