<aside> 💡 Rebase 의 위험성

Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다.

이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라

이 지침만 지키면 Rebase를 하는 데 문제 될 게 없다. 하지만, 이 주의사항을 지키지 않으면 사람들에게 욕을 먹을 것이다.

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커밋을 git rebase 로 바꿔서 Push 해버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 한다. 그리고 동료가 다시 Merge 한 내용을 Pull 하면 내 코드는 정말 엉망이 된다.

Git - Rebase 하기

</aside>

rebase 시도

• 처음에는 이슈번호를 붙이려 rebase를 하려고 했었다.

• 당시 우리는 잠시 잊고 있었다. 멘토님께서 같이 쓰는 저장소에 rebase를 하지 말라고 하셨던 그 말을.

• rebase를 시도 한 뒤에야, 우리는 rebase가 이전에 있던 커밋이 대체되는 것이 아니라, 이전에 있던 커밋의 내용을 가지되 수정이 생긴 새로운 커밋이 만들어지는 것이라는 것을 깨달았다.

• 로컬에서는 괜찮더라도, 이걸 같이 이용하는 원격 저장소에 force push를 통해 적용시킨 뒤 다른 사람이 그 저장소를 pull 한다면 커밋 히스토리가 정말 엉망이 되었다.

• 그 결과 아래와 같은 커밋 히스토리가 생겼다.

  

rebase의 원리와 활용

• 이때에서야 우리는 왜 멘토님께서 같이 쓰는 저장소에 push된 커밋을 rebase 하지 말라고 하셨는지 알 수 있었다. rebase는 커밋을 한 번에 수정하거나 병합할 수 있는 좋은 기능을 제공해주지만, 그만큼 동작 원리가 복잡해서 혼란이 생기기 쉬웠다.
• rebase는 두 브랜치의 공통 조상 커밋으로 이동하여 비교하고 합치기 때문에 커밋 이력 없이 깔끔하게 두 브랜치를 합칠 수 있는 방법이다.
  • rebase의 동작원리
• 이런 원리를 이용하면 여러 커밋을 하나로 합치거나 커밋을 수정하는 듯 조작할 수 있어서, 커밋 병합이나 과거 커밋의 수정을 위해서 rebase가 사용되기도 한다.
• rebase -i (interactive, 대화형 rebase를 사용 할 수 있다) 명령어를 사용하면, 커밋을 병합, 혹은 없애거나 커밋 메시지를 수정하는 등 여러 수정이 가능하다.
  • squash와 fixup 병합

rebase의 문제점

• 문제는 rebase로 커밋을 깔끔하게 만들어주는 원리의 이면에는 이전의 커밋이 히스토리 상에서 짠하고 삭제되어서 어디서 pull 하든 동기화되는 것이 아니라, rebase된 새로운 하나의 커밋을 만든다는 것에서 시작된다.
• 먼저 이렇게 변경된 커밋을 remote에 rebase로 정리된 커밋을 적용시키려면 force push를 해주어야했다. 이것부터 위험한 행동이었다.
• 또한 이렇게 rebase 되어 remote에 새롭게 커밋이 만들어져서 적용이 된다면, 다른 로컬에서 pull 했을 때 커밋들이 병합되는 것이 아니라 기존의 커밋에 rebase 커밋이 추가되어 새로운 난장판이 생긴다.
• 이런 경우, 다른 사람들이 local에서 다시 병합해주어야 정리된 내용이 적용된다.
• 그렇기 때문에 rebase 를 하려면 해당 레포지토리를 사용하는 모든 구성원의 동의를 받고 진행해야한다는 것을 뼈저리게 느낄 수 있었다.

물론 우리는 둘이라서 해낼 수 있었다.

/ rebase 결과물