[GIT] rebase 와 merge 의 차이

김zunyange·2023년 3월 23일

git mergegit rebase는 모두 두 브랜치를 합치기 위한 명령어이다. 여기서 두 브랜치는 기준 브랜치와 대상 브랜치로 나눈다.

기준 브랜치 : master와 같이 기준이 되는 브랜치
대상 브랜치 : feature 브랜치들과 같이 master에 합쳐져야 하는 브랜치

git merge와 git rebase의 차이

git merge

git checkout feature // feature로 checkout을 하고
git merge main // feature에 main 브랜치를 merge 한다.
  • 브랜치 변경 없이 단순히 브랜치를 합치는 것이라고 보면 되는데, merge 할때마다 merge commit이 생기기 때문에 프로젝트가 활발한 경우 commit 때문에 변경이력을 알기 어렵다.
  • 어떤 변화가 언제 반영되었는지에 대한 이력 없이 다 하나의 커밋으로 합쳐지기 때문이다.
  • 자동 merge가 실패했으니, 충돌 부분을 수정하고 결과를 다시 커밋 하라는 경고문이 노출된다.
  • 충돌이 발생한 이유는 두 브랜치에서 수정한 파일의 내용이 서로 다르기 때문이다.
  • 이와 같이 같은 부분에 서로 다른 부분이 있을 경우, merge conflict가 발생할 수 있다.
  • 이를 해결하기 위해 충돌이 발생한 부분을 수정이 필요하다.

git rebase

git checkout feature // feature로 checkout을 하고
git rebase main // feature에 main 브랜치를 merge 한다.
  • feature 브랜치의 커밋은 main 브랜치가 가지고 있던 기존의 커밋 뒤에 위치하게 된다.
  • 브랜치의 commit message가 시간 순서대로 합쳐진다.
  • history를 깔끔하게 유지하기 위해 사용합니다.
  • main 브랜치의 기존의 마지막 커밋 뒤에 병합할 브랜치의 커밋들이 합쳐지게 하여 master 브랜치에 재배치(rebase) 하는 것을 말한다.

요약

즉, git merge와 git rebase의 다른 점은 두 브랜치의 커밋들을 합치기 위해 어떤 전략을 취하는지이다.
만약 기준 브랜치를 대상 브랜치에 merge한다고 하면 (=feature 브랜치에 master 브랜치를 merge) git merge는 기본적으로 merge를 하기 위해 대상 브랜치를 그대로 두고, 기준 브랜치의 변경 사항(커밋)을 대상 브랜치에 얹으면서 합친다. 그때 conflict가 일어나면 conflict를 해결한 커밋 또한 대상 브랜치에 얹어진다. 그렇기 때문에 git merge는 merge가 일어난 시간에 대상 브랜치에 새로운 커밋을 생성한다.
git rebase는 git merge와 반대로, 기준 브랜치를 대상 브랜치에 rebase한다고 하면, 무조건 기준 브랜치의 커밋 순서는 바뀌지 않고 대상 브랜치의 커밋을 기준 브랜치에 얹는 식이다.

참고) git command

git rebase -i ${수정할 커밋의 직전 커밋}

// 커밋 해시를 이용한 방법
git rebase -i 9d9cde8

// HEAD를 이용한 방법
git rebase -i HEAD~3

git rebase --continue
: conflict 발생시, 충돌 파일을 수정하고 git add 후에 git rebase --continue를 진행한다.
만약 rebase 전으로 되돌리고 싶다면 git rebase --abort 를 사용하면 된다.

git rebase --abort
: git rebase 호출 이전의 분기 상태로 되돌린다.

git reflog
: 로컬 저장소에서 HEAD의 업데이트를 기록을 출력한다.


git reflog show HEAD 와 같다. (show HEAD가 생략된 것)

//만약, 특정 브랜치의 reflog만 보고싶다면
git reflog [show] "branch name"

git reset
: commit 취소하기
git reset --hard를 사용하면 현재 작업 위치인 HEAD의 포인터를 특정 위치로 변경해버릴 수 있다.

주의사항

협업하는 과정에서 이미 원격 리포지터리에 푸시된 커밋 히스토리를 로컬에서 리베이스하여 다시 푸시하는 일은 지양해야 한다. 왜냐하면 rebase는 기존의 커밋을 재사용하는 것이 아니라, 내용이 같은 커밋을 새로 만들기 때문이다.
그렇기 때문에 원격 브랜치(master)를 베이스로 작업하고 있던 동료들의 커밋 히스토리가 와장창 깨질 수도 있게 되고, 특히 함께 협업하는 브랜치에서 --force 로 push 해버린다면, 자칫 동료의 작업본을 날려먹을수도 있다.
📢 rebase로 인해 다른 사람들이 작성하던 commit history 가 바뀌게 된다. 따라서 한 브랜치를 여러명이 수정할 때에는 절대 rebase ❌금지❌다 !!!


출처 : https://pearlluck.tistory.com/754

profile
배움은 즐거워 ~(*ૂ❛ᴗ❛*ૂ)

0개의 댓글