Git/Rebase 페이지의 소스 보기

내용출력
로그인[l]
수정할 수 없습니다: Git/Rebase 는 읽기 전용 페이지입니다.
알쏭달쏭한 <code>git rebase</code>. 정확히 어떻게 될 것인가 확신이 없는 상태에서 실전에 적용하자니 영 불안해서, 자꾸 간단한 저장소를 만들어 테스트하느라 시간을 잡아먹는다. 어쨌거나 나중에 볼 수 있게 결과를 적어둠

<toc>


== # 분기가 두 번 일어났을 때 rebase ==

{{{
(1)
A---B---C    master
     \
      D---E  feature1
 devel \   
        F  feature2
}}}
* B에서 devel 브랜치가 분기하고
* D에서 다시 f1, f2 브랜치가 나눠진다

이 때 f1을 master로 rebase
{{{#!vim
(feature1) $ git rebase master
(master)   $ git merge feature1
}}}

다음처럼 된다.
{{{
(2)
A---B---C---D'---E'    master, feature1
     \
      D
 devel \   
        F  feature2
}}}
* 즉 master와 만나는 분기점 이후에 있는 D까지도 같이 rebase된다.

(2)에서, master와 feature2를 머지하면,

{{{#!vim
(master)   $ git merge feature2
}}}

{{{
(3-1)
A---B---C---D'---E'  feature1
     \            \  
      D            \
 devel \            \
        F------------O master
     feature2
}}}
* master의 로그를 보면 D와 D'가 중복해서 나타난다. (뭐 병합에 문제는 없다)

다시 상황 (2)로 돌아가서, 이 상태에서 f2를 또 master에 rebase하면:
{{{#!vim
(feature2) $ git rebase master
}}}

{{{
(3-2)
A---B---C---D'---E'    master, feature1
     \            \
      D            F'  feature2
 devel   
}}}
* D가 또 한 번 E' 뒤에 붙지는 않는다. 동일한 체인지라서 무시되나 봄
* (만일 E'뒤에, D와 충돌하거나, D'와 정반대의 변경을 하여서 무효로 돌리는 커밋을 한 후 F를 rebase하면 어찌 될까...라는 생각이 들었는데, 차마 그 테스트까지는 변태같아서 못하겠다-_-;)

(3-2) 같은 경우는 devel 브랜치가 아직 남아 있어서 D가 살아있다. 만일 (2)에서 브랜치를 먼저 삭제한 후 rebase했다면:
{{{#!vim
(feature2) $ git branch -d devel
(feature2) $ git rebase master
}}}

{{{
(3-3)
A---B---C---D'---E'    master, feature1
                  \
                   F'  feature2
}}}
* D를 가리키는 객체가 없어서 사라짐


== # merge 후 rebase ==

앞 섹션의 (1)에서 다시 시작
{{{
(1)
A---B---C    master
     \
      D---E  feature1
 devel \   
        F  feature2
}}}

여기서 f2를 f1에 merge
{{{#!vim
(feature1) $ git merge feature2
}}}

{{{
(2)
A---B---C    master
     \
      D---E
 devel \   \
        F---O feature1
  feature2
}}}

이 때 f1을 master로 rebase하면 D,E,F는 어떻게 될까...가 궁금했다 -_-;
{{{#!vim
(feature1) $ git rebase master
}}}

{{{
(3)
      master
A---B---C---D'---F'---E'  feature1
     \  
      D
 devel \
        F
  feature2
}}}
* D와 F와 E가 master 뒤에 순차적으로 다시 적용되고, D와 E 원 커밋은 남아 있고, E는 사라지고, E와 F를 머지했던 커밋(O)도 사라지더라.

앞 절과 이번 절의 실험에서, merge나 rebase과정에서 전혀 충돌이 발생하지 않게 각 커밋의 내용을 구성한 터라... 충돌이 발생하면 어찌될지는 모르겠다. 차마 해 볼 엄두도 안 남.


== # Comments ==
[http://dogfeet.github.io/articles/2012/git-merge-rebase.html #dogfeet - Git: Rebase는 언제 어떻게 해야 할까?]

<div class="comments">
<longcomments(100)>
----

</div>
----
[[컴퓨터분류]]
Git/Rebase 페이지로 돌아가기 | 다른 수정본 보기