[GIT] Rebase 하기

Rebase의 기초

• Rebase는 두 브랜치를 합치는 방법 중 하나로, Merge와는 다른 방식으로 작동합니다.
• git rebase 명령을 사용하여 한 브랜치에서 다른 브랜치로 변경사항을 적용합니다.

• $ git checkout experiment
  $ git rebase master

• Rebase는 두 브랜치의 공통 조상에서부터 시작하여 변경사항을 차례대로 임시로 저장하고, 다른 브랜치의 최신 커밋으로 이동한 후 저장해둔 변경사항을 순차적으로 적용합니다.
• Rebase 후에는 Master 브랜치를 Fast-forward하여 합칩니다.

• $ git checkout master
  $ git merge experiment

• Rebase를 통해 만들어진 커밋 히스토리는 선형적이며 깨끗한 형태를 가지게 됩니다.

Rebase의 활용

• 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치가 있을 때, 일부 변경 사항만을 가져와서 브랜치를 정리할 수 있습니다.

• $ git rebase --onto master server client

• 위 명령은 client 브랜치에서 변경된 커밋 중 master 브랜치와 server 브랜치의 공통 조상까지의 커밋을 제외한 나머지 커밋을 master 브랜치에 적용합니다.

• $ git rebase master server

• 위 명령은 server 브랜치에서 변경된 사항을 master 브랜치에 Rebase합니다. 이후 master 브랜치를 Fast-forward하여 작업을 통합할 수 있습니다.

• $ git checkout master
  $ git merge server

• 모든 작업이 완료되면 필요없는 브랜치를 삭제할 수 있습니다.

• $ git branch -d client
  $ git branch -d server

Rebase 주의사항

• Rebase는 기존 커밋을 변경하는 것이 아니라 새로운 커밋을 만들기 때문에 이미 서버에 Push한 커밋을 Rebase하면 그 이후의 커밋들이 모두 새로 생성됩니다.
• Rebase로 인한 문제
  1. 중앙 저장소에서 Clone하고 일부 수정 후 Push.
  2. 다른 팀원이 커밋, Merge 후 Push.
  3. 하나의 팀원이 Merge를 되돌리고 Rebase 후 강제 Push.
  4. 다른 팀원이 Fetch하면 혼란스러운 상태가 됨.
• 서버에 Push하기 전에 Rebase로 커밋을 수정하지 않으면 이러한 혼란이 발생할 수 있습니다.

Rebase 한 것을 다시 Rebase 하기

• 만약 다른 팀원이 강제로 내가 한 작업을 덮어쓴 경우, Git은 커밋의 "patch-id"라는 값으로 커밋을 식별합니다. 이 값은 커밋에 대한 변경 사항을 나타냅니다.
• 위에 상황에서 다른 팀원이 내가 의존하는 커밋을 없애고 Rebase 한 상황에서, 내가 git rebase teamone/master 명령을 실행하면 Git은 다음과 같은 작업을 수행합니다
  1. 현재 브랜치에만 포함된 커밋을 결정합니다.
  2. Merge 커밋이 아닌 것을 결정합니다.
  3. 덮어쓰이지 않은 커밋을 결정합니다.
  4. 결정한 커밋을 teamone/master 브랜치에 적용합니다.
• git pull 명령을 실행할 때 --rebase 옵션을 사용하여 Rebase를 진행할 수 있습니다. 또한, git pull 명령에 대한 기본적인 옵션을 설정하려면 git config --global pull.rebase true 명령을 사용할 수 있습니다.
• Rebase는 개인적으로 작업하거나 아직 Push하지 않은 커밋에 사용하는 것이 좋습니다.

Rebase와 Merge의 장단점

• Rebase의 장점
  • Rebase는 커밋 히스토리를 단순하고 선형적으로 유지합니다. Merge 커밋이 적어지며, 브랜치의 작업 내용이 한눈에 들어옵니다.
  • 로컬에서의 작업을 정리하기 위해 사용될 수 있습니다. 작은 단위로 자주 Rebase하면 깔끔한 히스토리를 유지할 수 있습니다.
  • 중요한 커밋만을 선택적으로 합칠 수 있어 가독성이 향상됩니다.
• Rebase의 단점
  • 이미 공개된 커밋을 Rebase하면 역사를 변경하게 되어 협업에 혼란을 야기할 수 있습니다.
  • 실수로 잘못된 Rebase를 수행하면 데이터 손실이 발생할 수 있습니다.
• Merge의 장점
  • 이미 공개된 커밋을 변경하지 않으므로 안정적입니다.
  • 개발 흐름을 정확하게 기록하며, 각 브랜치의 독립성을 유지합니다.
  • 병합 시 충돌이 발생할 경우 쉽게 해결할 수 있습니다.
• Rebase를 사용하는 경우
  • 로컬 브랜치에서의 작업
  • 개별적인 기능 브랜치
• Merge를 사용하는 경우
  • 이미 Push한 브랜치에 대해서는 Rebase를 사용하지 않는 것이 안전합니다.
  • 여러 명의 개발자가 협업할 때는 안정적인 Merge가 더 적절할 수 있습니다.
  • 프로젝트의 중요한 이력을 남기고자 할 때 Merge를 사용합니다.