Merge
두 개의 브랜치로 나누어진 커밋 히스토리에서 합치는 가장 쉬운 방법은 Merge다.
이 경우 C3, C4를 조상으로 하는 3-way-Merge로 새로운 커밋을 만들어낸다.
Rebase
Git에서 한 브랜치에서 다른 브랜치로 합치는 방법 중 나머지 하나는Rebase다.
$ git switch experiment
$ git rebase master실제로 일어나는 일은 아래와 같다.
- 두 브랜치가 나뉘기 전인 공통 커밋으로 이동
- 그 커밋부터 현재의 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시 저장
- Rebase할 브랜치(experiment)가 합칠 브랜치(master)가 가리키는 커밋을 가리키게 하고 아까 저장해놓았던 변경사항을 차례대로 적용한다.
그리고 나서 master 브랜치를 Fast-forward(빨리감기) 시킨다.
C4'로 표시된 커밋내용에서는 Merge 예제에서 살펴본 C5 커밋에서의 내용과 같다. Merge이든 Rebase이든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만 Rebase가 좀 더 깨끗한 히스토리를 만든다.
Merge와 Rebase의 특징
Merge: 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해짐.Rebase: 이력은 단순해지지만, 원래의 커밋 이력이 변경됨. 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안됨.
Rebase의 위험성
Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다.
이미 공개 저장소에 Push 한 커밋을 Rebase 하지마라!!
로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할수도 있지만
어딘가에 Push로 내보낸 커밋에 대해서는 절대로 Rebase 하지 말도록 하자!
왜냐하면 이미 push된 커밋을 누군가가 pull로 받고서 -> 내가 rebase 한 후 -> 누군가가 다시 push를 할 때 merge를 해야하는 상황이 발생한다 -> 이후 pull 시 코드가 꼬이게 되는 현상이 발생하게 된다..!
그러니 외부 Repo에 Push가 된 Commit은 조용히 보내주도록 하자!
rebase --onto
rebase --onto은 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치를 rebase할 경우 사용할 수 있다.
위의 그림의 경우 master에서 server브랜치가 나오고 C3을 공통으로 사용하는 client 브랜치가 있을 경우, client브랜치에서 공통조상을 없애면서 master로 합칠 경우 사용할 수 있다.
$ git rebase --onto master server client
이후 master 브랜치로 돌아가서 Fast-forward 시킬 수 있다.
$ git switch master
$ git merge client
rebase -i
최신 커밋이 아닌 예전 커밋을 업데이트 하고싶은 경우 interactive rebasing을 사용할 수 있다.
git rebase -i
-----------------------------------
# p, pick : 그냥 해당 커밋을 사용하는 것
# r, reword : 커밋을 사용하지만 메시지는 변경한다
# e, edit : 커밋을 사용하지만 안의 변경사항을 바꾸겠다
# s, squash : merge 를 통해 커밋을 하나로 묶어주는 것처럼 여러 commit을 하나로 묶어준다
# f, fixup : sqush와 비슷하지만 메시지를 남기지 않는 것
# e, exec : 이 커밋부터 shell 명령어를 직접적으로 이용하고 싶을 때 사용한다
# b, break: stop here, 여기서 멈춘다
# d, drop: 해당하는 커밋을 history에 남기지 않고 제거하고 싶을 때이 외에도 많은 옵션이 존재한다. 실무에서 유연히 사용하기 위해선 git도 꾸준히 공부해야할 대상인 것 같다. 팀 개발을 위한 Git, GitHub 시작하기 책에 관심이 가는데 한 번 사서 파보도록 해야겠다.
참고
