자료 모음
원본저장소에서부터 가져온 커밋들을 base 라고 부릅니다. 원본 저장소와 포크를 받아온 나의 원격저장소, 그리고 클론을 받은 로컬에는 모두 같은 해시값의 커밋들로 이루어져있습니다. base 가 같은 상황입니다.
git은 억지로 넣어서 base 를 교체하지 않는 한, base 가 같은 저장소에만 push 를 할 수 있습니다.
commit1, commit2, commit3을 base로 한 나의 작업물들은 더이상 commit1, commit2, commit3, commitX, commitY 를 base로 한 저장소와 싱크가 맞지 않는 상태입니다. 이 때가 바로 base의 갱신이 필요한 상황, 즉 rebase를 해야하는 상황 입니다.
Merge 이든 Rebase 든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만, Rebase가 좀 더 깨끗한 히스토리를 만든다. Rebase 한 브랜치의 Log를 살펴보면 히스토리가 선형이다. 작업을 병렬로 동시에 진행해도 Rebase 하고 나면 모든 작업이 차례대로 수행된 것처럼 보인다.
메인 프로젝트에 Patch를 보낼 준비가 되면 하는 것이 Rebase 니까 브랜치에서 하던 일을 완전히 마치고 origin/master 로 Rebase 한다. 이렇게 Rebase 하고 나면 프로젝트 관리자는 어떠한 통합작업도 필요 없다. 그냥 master 브랜치를 Fast-forward 시키면 된다.
Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다.
Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다. 이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라.
