[Git] 8. Rebase, git flow

cf) merge ... 당겨온다 생각

master -> f

 master정보를 f로 가져오기

git checkout f
git merge master

1. Rebase란?

1) 개념

base commit을 rebase로 명령한 branch의 최신 커밋 point의 공통 commit point로 바꾸는 것

before

$ git checkout experiment
$ git rebase master

after

---

ex2)

- f, m 은 각각 브랜치

- base는 두 개 브랜치의 공통 커밋정보

- base를 현재 master가 가리키고 있는 것(최신커밋)으로 바꾸는 것을 rebase라고 함

f가 커밋했던 정보들을 임시 저장소에 저장(petch)한 후, 최종적으로 merge

git checkout f
git rebase master

rebase

 

※ merge는 병렬로 나아가지만,

  rebase는 일렬로 나아감 (가시성)

merge 

2) conflict 발생시 해결

add: 변경 사항을 만들어서 인덱스에 등록해보기
<<<<<<< HEAD
commit: 인덱스의 상태를 기록하기
=======
pull: 원격 저장소의 내용을 가져오기
>>>>>>> issue3

파일 수정 후, commit이 아닌, rebase명령의 --continue옵션을 지정하여 실행해야 함

(merge에서는 confilict발생시 commit임을 주의)

$ git add myfile.txt
$ git rebase --continue
Applying: pull 설명을 추가

 

3) rebase 취소 명령

git rebase --abort

 

2. git flow

- git을 이용한 작업 흐름

git flow

1) "feature branches"(기능에 대한 브랜치 생성)

-> 작업이 끝나면 develop브랜치로 merge

// login작업의 feature생성
git checkout -b feature-login

// 작업이 끝난 후 merge
git checkout develop
git merge feature-login

// 사용한 브랜치 삭제
git branch -d feature-login

 

2) "release branches"

클라이언트에게 다운로드&서비스&반영 할 때 새로운 브랜치 생성 

-> 버그 수정

한꺼번에 merge시 충돌이 발생하므로 틈틈히 develop브랜치에 merge

master 브랜치로도 merge

git checkout -b release-1.0

// master 브랜치에 merge
git checkout master
git merge release-1.0
git tag -a 1.0 -m "first release" master

* master를 끝에 써주는 이유 : master의 HEAD에 tag값 주기 위함

 

3) "master branches"

사용자에게 제공되었던 버전(Tag)들을 모아놓은 정보들

release branches에서 마침내 서버에 릴리즈할 경우 master에 merge

-> 동시에 Tag를 이용해서 버전 기록(서버에 업로드 하거나 사용자가 다운받을 수 있게끔 함)

 

4) "hotfixes"

사용자에게 버전을 제공했는데, 긴급한 버그 수정을 해야하는 경우

-> 수정 후 master 브랜치 or develop 브랜치에 바로 넘김

git checkout -b hotfix-login

// master에 merge
git checkout master
git merge hotfix-login
git tag -a 1.1 -m "hotfix login" master

// develop에 merge
git checkout develop
git merge hotfix-login

브랜치의 역할

• master: 제품으로 출시되는 브랜치(과거에 출시했던 것이 누적)
• release: 이번 출시 버전을 준비하는 브랜치 (QA를 이곳에서 하며, QA를 통과하면 Master브랜치로 merge)
• develop브랜치는 곧 master브랜치로부터 생긴 것
• tag: 커밋을 참조하기 쉽도록 알기 쉬운 이름을 붙인 것 (단순 주석 처리라고 생각)

3. repository 관점의 work flow

Upstream Remote Repository : 개발자들이 공유하는 저장소

Origin Remote Repository : Upstream Repository를 Fork한 원격 개인 저장소

Local Repository : 개인 컴퓨터 로컬 저장소

 

* 우아한형제들에서의 워크플로우 규약

- 하나의 Jira 티켓은 하나의 커밋

- 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않음

- 자신의 Pull Request는 스스로 merge

 

* 참고 : nvie.com/posts/a-successful-git-branching-model/

            woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html