Rebase
Git에서 브랜치를 합치는 방법은 Merge와 Rebase가 있다.
Rebase가 뭔지는 두 사진을 보면 좀 더 감을 잡기가 쉽다.
merge 명령을 사용했을 때는 두 브랜치의 마지막 커밋 두 개 c3, c4와 공통조상인 c2를 사용해 만들어 내지만
rebase를 사용했을 땐 c3에서 변경된 사항을 patch로 만들고 이를 다시 c4에 적응시키는 방법이 있다.
위 사진은 git checkout experiment; git rebase master이다.
즉 fast-forward를 적용시키는 것이다.
Rebase는 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다. 아마 이렇게 Rebase 하는 리모트 브랜치는 직접 관리하는 것이 아니라 그냥 참여하는 브랜치일 것이다. 메인 프로젝트에 Patch를 보낼 준비가 되면 하는 것이 Rebase 니까 브랜치에서 하던 일을 완전히 마치고 origin/master 로 Rebase 한다. 이렇게 Rebase 하고 나면 프로젝트 관리자는 어떠한 통합작업도 필요 없다. 그냥 master 브랜치를 Fast-forward 시키면 된다.
merge를 한경우와 rebase를 한경우는 히스토리가 상당히 다르다. 선형인 것을 확인할 수 있을 것이다.
Rebase의 위험성
Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다.
이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라
이 지침만 지키면 Rebase를 하는 데 문제 될 게 없다. 하지만, 이 주의사항을 지키지 않으면 사람들에게 욕을 먹을 것이다.
Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커밋을 git rebase로
'Git' 카테고리의 다른 글
git commit 되돌리기 (0) | 2023.07.03 |
---|---|
브랜치 .Refactoring (0) | 2022.08.14 |
Git Branch(3) (0) | 2021.02.11 |
Git Branch(2) (0) | 2021.02.11 |
Git Branch (0) | 2021.02.11 |
댓글