1. rebase정의
(1) - init 버전을 조상으로 하는 master와 topic branch 버전 구조
(2) - ffa5e7e t3(topic branch)버전의 파일 목록
(3) - 84fc052 m2(master branch)버전의 파일목록
우리가 하고 싶은 일은 (master)m2 버전의 조상을 init버전이 아닌 (topic)t3 버전으로 바꾸고 싶다
↗ t1 -> t2 -> (topic) t2
즉 init 에서 〓〓▷ init -> t1 -> t2 -> (topic)t2 -> m1 -> (master)m2
↘ m1 -> (master)m2
처럼 보이도록 하고 싶은 것이다
2. rebase 명령실행
(1) - base를 이동시킬 브런치로 HEAD를 옮긴다 git checkout master
(2) - base가 될 버전(아래에서는 ffa5e7e = topic)으로 rebase를 한다 git rebase ffa5e7e or git rebase topic
- 그럼 이제 우리가 원하는 결과를 얻을 수 있다.
(3) - 여기서 rebase로 재구성된 e0c78d0 m1 버전은 t3의 버전에 이전 m1버전의 변화를 더한 버전이고
m1 버전 = t3버전 + 기존m1의 변화(m1.txt)
- 0fce336 m2 버전은 위 m1버전에 이전m2버전의 변화를 더한 버전이다
m2 버전 = (3)의 m1버전 + 기존m2의 변화(m2.txt)
*rebase는 원격저장소로 Push하기 전에만 사용해야 한다!! rebase를 하고 원격저장소에 push를 하면.. 버전의 본질이 흐려져서 협업시에 아주 혼란스러워질 수 있다!
3. rebase 와 merge
*merge로 m2 + t2 를 합친 mt3 와
rebase로 만든 m2는 서로 완전히 같은 워킹카피(위의 예로는 init.txt | m1.txt | m2.txt | t1.txt | t2.txt | t3.txt)를 가지게 된다
4. rebase의 실체 및 conflict 해결
사실 rebase는 cherry-pick의 원리와 같다
- m1을 마스터로 두고 m1의 베이스를 topic으로 하기 위해 m1 rebase topic 을 하게되면
- git은 topic으로 HEAD를 옮기고 C를 BASE로하여 M1과 비교하여 그 차이점인 m1이라는 내용을
topic과 병합(체리픽) 하여 conflict를 해결하고 새로운 버전을 만들고(파란점을 3merge)
- 위에서 만들어진 버전으로 HEAD를 옮긴후 이제 cm1 버전을 BASE로 하여 cm1m2버전과의 차이점을 cmt1에
체리픽하여 conflict를 해결하고 mt1mt2라는 새로운 버전을 만들게 된다
-그리곤 다시 HEAD를 최종적으로 만들어진 버전으로 옮기고 아래와 같은 그림이 완성된다
이러한 연속된 체리픽과정으로써 rebase가 되는 것이다!!
*rebase의 위와 같은 원리를 실제 gti-bash를 통해 코드상으로 이해하고싶다면
아래 이고잉님의 동영상을 참조하자
참조: opentutorials.org/course/3843/24446
5.협업을 할때 rebase로 로그기록을 깔끔하게 유지하는 방법!
참조:opentutorials.org/course/3843/24447
'GIT' 카테고리의 다른 글
GIT - pull-request (0) | 2020.12.17 |
---|---|
GIT - cherrypick (0) | 2020.12.12 |
GIT - clone, pull,fetch (0) | 2020.12.12 |
GIT - backup, push (0) | 2020.12.12 |
GIT - branch(3 way merge) (0) | 2020.12.11 |