Git) 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

---

References

• https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
• https://nvie.com/posts/a-successful-git-branching-model/
• 사용법 cheat sheet : https://dahye-jeong.gitbook.io/git/git/2019-01-27-git-flow