rebase 이해하기 git..

REBASE 는... 말그대로 RE - BASE .. 내가 만들어진 부모(BASE)를 재정의(RE)하는것이다. 재정의하게 되면 내가 알고 있던 부모(old)로부터 바뀌어진 있는 부모(new)의 수정 내용이 나에게 적용된다. 

흡사 처음부터 난 바뀌어진 부모(new)로 부터 만들어진것 처럼.. 말이다. 부모의 수정본이 그대로 나에게 적용되는것이다. 예로 내가 작업중인데 중간에 상용에 hotfix 가 적용된 경우 그 적용본을 나에게 적용해야할때, rebase 를 하면된다.(누구를 대상으로 rebase 하냐고? rebase로 가져올(작업으로 머지할.. 내작업..한 소스로 들어올) 대상에게 rebase  한다. 즉 내 작업으로 checkout 된 상태에서 git rebase master or develop 이런거지. onto master 이다. )

그리고 항상 언급되는 얘기인데, rebase 는 히스토리의 수정이 들어가므로

push 한 커밋을  rebase 하진 마라. 내가 새로 한 작업(push 되지 않은 commit)을 rebase 하는건 문제 없다. push 한것을 rebase 했다간 내가 push 한걸 가져간 누군가의 작업을 망쳐버릴 수 있다.

출처: https://ezsnote.tistory.com/entry/왜-rebase

아래는 단계별로 예를 든 것이다.

1. develop 으로 부터 2개의 브랜치를 만든다. 하나는 newHotFix, 하나는 newFun01

2. newHotFix 에 4번의 커밋을 한다. 히스토리상 4개의 커밋이 보이겠지. 

3. newHotFix 를 이제 develop 에 반영하자. 

rebase 는 나의 base 를 다시 재정의 하는것이다.

이걸 언제 쓰냐고? 간단히 내가 만든 브랜치의 부모인 master/develop 이 다른 배포와 머지가 되어버린 상태일때,

즉, 내가 브랜치 만들때와 다르게 상태가 바뀌었다면 그때 나의 브랜치의 부모를 새로운 master/develop 로 하는게 rebase 라고 봐도 된다. 

위의 내용중 newHotFix 를 develop 에 적용하자. (즉 머지)

(참고로 newHotFix 에서 develop/master 로 rebase 해봤자 변화는 없다... 내가 알던 부모가 그대로거든)

5. 이제 newFun01 이 알던 develop/master 가 아니다. newHotFix 와 머지됐거든

   새로운 부모로 rebase 하자. 

   git checkout newFun01

   git rebase develop

   하면 newHotFix 의 내용이 newFun01 에 들어가 있다. 새로운 부모로 base 를 새로 짰으니 그 수정분이 newFun01 에 들어온것이다.

6. 이때 상태를 보면.. push 할것과 pull 할게 생겨있다. 현재브랜치는 newFun01 이다. pull 하면 어떤일이 생길까?

   rebase 를 했을때 상태를 보면 newFun01 은 newHotFix 가 적용되었고 그 위치에 있다. 여기서 pull 을 하면 newHotFix 분이 현재가 아닌 과거로 밀려나고 현재 새로운 수정본위치로 head 가 옮겨진걸 볼 수 있다. 즉 히스토리가 반영되는것이라고 봐도 된다. 마치 hotfix 가 적용된 이후의 develop/master 로 부터 브랜치를 만든것처럼 된다. 

   이제 push 하자.

   git push 

7. 자.. 이제 히스토리를 보면 같은 부모로 부터 만든 hotFix / newFun 의 위치가 hotFix 가 먼저 적용되고 이후에 newFun 을 만들어 작업한것 처럼 보이게 생성되어있다. 동시에 같은 부모가 아니라 하나의 작업이 끝나고 그다음 다른 피처를 만들어 머지한것처럼..