[Git 깃] git rebase 위험성

Rebase 위험성

Rebase는 Merge 보다 commit history를 깔끔하게 해서 유용하지만

rebase 과정에서 생겨나는 커밋은 내용은 같지만 새로운 커밋이기에

다른 사람과 협업하는 경우 곤란해질 수 있다.

[Git 깃] git rebase

 

 

시뮬레이션

[My Computer]에 원격 저장소를 clone 하였다.

[master]에서 C2, C3 작업을 하였다. 

 

 

다른 팀원들이 C4, C5, C6 작업하여 서버에 push 되었다.

(C6 은 merge commit 이다.)

서버에서 pull (fetch + merge) 하여 C7이 만들어졌다.

(C7은 merge commit 이다.)

 

 

push 하였던 팀원이 C4, C6 를 rebase 한다.

rebase 결과 C4' 를 git push --force하여 원격 서버에도 반영되었다.

[teamone/master]는 C4'를 바라보게 된다.

 

 

[master] git pull (fetch + merge)하여 C8 만들어진다.

git log로 보면 날짜/저자/메시지가 같은 C4, C4' 가 보인다.

(C4와 C4'는 내용물은 동일하지만 Hash 값이 다른 커밋이다.)

rebase된 C4, C6 는 모든 팀원이 포함하지 말아야 한다.

하지만 이대로 push 하게 된다면 혼란이 가중된다.

• 공개된 commit을 rebase 시 문제가 발생할 수 있다.

• rebase 해야 할 commit 들은 push 하기전에 로컬에서 처리하면 좋다.

• 비공개 작업 내용은 rebase 해도 문제 없다.

 

 

Rebase 한 것을 다시 Rebase

rebase 하였다면 다른 사람들도 해당 내용을 반영하면 좋다.

Git에서는 커밋 SHA 체크섬 외에도 커밋 patch 할 내용으로

SHA-1 체크섬을 한번 더 구한다. → 「patch-id」 라고 한다.

 

한 팀원이 다른 팀원이 의존하는 커밋을 없애고

Rebase 한 커밋을 다시 Push 함 상황에서

merge 대신 git rebase teamone/master 명령을 실행해 볼 수 있다.

 

 

 

• 현재 브랜치에만 포함된 커밋을 결정 → C2, C3, C4, C6, C7

• merge 커밋이 아닌 것 결정 → C2, C3, C4

• 이 중 merge할 브랜치에 덮어쓰이지 않은 커밋을 브랜치에 적용

    → C4는 C4'와 동일한 Patch로 → C2, C3

    → C4와 C4' 커밋 내용이 완전히 같을 때만 이렇게 동작

        커밋 내용이 아예 다르거나 비슷하다면 커밋이 두 개 생긴다

 

다른 방법으로는 git rebase --rebase 명령으로

→ git fetch와 hgit rebase teamone/master 명령을 순서대로 가질수도 있다.

→ config설정으로 기본 설정도 가능하다.  git config --global pull.rebase true 

 

 

[까망] Git 목록