git merge vs git rebase / git fetch vs git pull

깃을 공부하면서 헷갈릴 수 있는 git merge와 git rebase, git fetch와 git pull의 차이점 및 사용 방법을 정리한 글입니다.

Git Rebase와 Git Merge

Git을 사용하다 보면 여러 브랜치를 병합해야 하는 상황이 발생합니다. 이때 git merge와 git rebase 두 가지 방법이 존재합니다.

Git Merge

git merge는 두 개의 브랜치를 합치는 방법입니다.

대상 브랜치의 최신 커밋을 기준으로 새로운 merge 커밋을 생성하여 변경 사항을 합칩니다.

동작 과정

1. main 브랜치에서 git merge feature1을 실행합니다.
   • 이는 main 브랜치에 feature1 브랜치를 합치겠다는 의미입니다.
2. git은 feature 브랜치와 main 브랜치가 공통으로 가리키고 있는 base 커밋을 찾습니다.
3. base 커밋과 main 브랜치의 최신 커밋, feature1 브랜치의 최신 커밋을 비교하여 변경 사항을 반영한 새로운 merge 커밋을 생성합니다.
4. 만약 충돌이 발생하면 Git이 자동으로 해결할 수 없는 변경 사항을 표시되고, 개발자는 충돌 파일을 열어 원하는 내용으로 변경하여 새로운 merge 커밋을 생성합니다.
5. main 브랜치에 merge 커밋이 추가되며, feature1 브랜치의 변경 사항이 main 브랜치에 반영됩니다.

장점

• 합쳐지는 브랜치의 커밋이 보존됩니다.
  • 위 예시로 보면 feature1의 커밋이 보존됩니다.
• 새로운 merge 커밋을 생성하기 때문에 변경 사항이 언제, 어떤 브랜치에서 병합되었는지를 쉽게 확인할 수 있습니다.
• 따라서 협업 시 여러 개발자의 작업 내역을 명확하게 유지하고 충돌 해결하기가 용이합니다.

단점

• 병합 커밋이 많아지면 Git 히스토리가 복잡해질 수 있습니다.

Git Rebase

git rebase는 한 브랜치의 변경 사항을 다른 브랜치 위에 재배치하는 방식입니다. 이를 통해 브랜치 히스토리를 보다 깔끔하게 정리할 수 있습니다.

동작 과정

1. feature1 브랜치에서 git rebase main을 실행합니다.
   • • 이는 feature1 브랜치에 base를 main 브랜치 최신 커밋으로 하겠다는 의미입니다.
2. Git은 feature 브랜치가 main 브랜치에서 분기된 지점을 찾습니다.
3. feature 브랜치의 커밋을 임시로 저장한 뒤, main 브랜치의 최신 커밋을 기반으로 feature 브랜치의 변경 사항을 하나씩 다시 적용합니다. (적용 시 기존 커밋 아이디가 아닌 새로운 커밋 아이디로 적용됨.)
4. 충돌이 발생하면 사용자는 각 충돌 파일을 수동으로 수정한 후 git add [파일]을 실행합니다.
5. 충돌 해결 후 git rebase --continue 명령어를 실행하여 다음 커밋을 적용합니다. 이때 또 충돌이 발생할 경우 4-5번을 반복하여 해결합니다.

장점

• 커밋 히스토리가 일렬로 정렬되어 단순하게 유지할 수 있습니다.
• 브랜치 개별 커밋이 순차적으로 정리되어 코드 리뷰나 디버깅 시 각 커밋의 변화 내용을 이해하기가 쉽습니다.

단점

• 협업 시 다른 개발자와 충돌이 발생할 가능성이 있습니다.
• 이미 공유된 브랜치에서 rebase를 실행하면 히스토리가 변경되어 문제를 일으킬 수 있습니다.

Git Merge와 Git Rebase의 차이점

동작 방식	병합 커밋을 생성하여 두 브랜치를 합침	커밋을 기준이 되는 브랜치 위에 재배치
히스토리	브랜치가 병합될 때 그래프 형태로 남음	선형적인 커밋 히스토리 유지
변경 사항 확인 방식	merge 커밋을 통해 어떤 브랜치에서 어떤 브랜치가 병합되고, 어떻게 변경되었는지 명확히 보임	브랜치 개별 커밋을 순차적으로 정리하여 깔끔한 변경 내역을 유지
충돌 처리	비교적 간단한 병합 충돌 해결	커밋마다 충돌 해결이 필요할 수 있음

Git Merge를 사용하면 적절한 상황

• 여러 개발자가 협업하는 프로젝트에서 브랜치의 작업 내용을 명확하게 유지해야 할 때
• 기능 브랜치를 메인 브랜치로 병합할 때
• 원본 커밋 이력을 보존해야 할 때

Git Rebase를 사용하면 적절한 상황

• 커밋 히스토리를 깔끔하게 유지하고 싶을 때
• 개인 브랜치에서 작업 후 메인 브랜치와 동기화할 때
• merge 커밋을 최소화하고 싶을 때

---

Git Fetch와 Git Pull

원격 저장소의 변경 사항을 가져오는 방법으로 git fetch와 git pull이 있습니다.

Git Fetch

git fetch는 원격 저장소의 최신 변경 사항을 로컬 저장소의 원격 브랜치로 가져오지만, 현재 작업 중인 브랜치에는 반영하지 않습니다.

즉, 원격 저장소의 최신 변경 사항이 origin/[브랜치]에만 적용됩니다.

동작 과정

1. git fetch origin을 실행하면 원격 저장소(origin)의 최신 커밋 정보를 가져옵니다.
2. origin/main 등의 원격 브랜치에 새로운 커밋이 업데이트됩니다.
3. 하지만 현재 작업 중인 브랜치에는 변경 사항이 적용되지 않습니다.

장점

• 원격 저장소의 변경 사항을 확인한 후 적용 여부를 결정할 수 있습니다.
• 충돌이 발생할 가능성을 미리 확인할 수 있습니다.

단점

• 변경 사항을 가져오기만 하고, 직접 적용하지 않으므로 추가적인 merge나 rebase 과정이 필요합니다.

Git Pull의 정의와 동작 원리

git pull은 git fetch와 git merge를 한 번에 실행합니다.

즉, 원격 저장소의 최신 변경 사항을 가져오고 현재 브랜치에 즉시 병합합니다.

동작 과정

1. git pull origin main을 실행하면 원격 저장소의 변경 사항을 가져옵니다.
2. 현재 브랜치와 자동으로 병합이 이루어집니다.
3. 충돌이 발생하면 직접 해결해야 합니다.

장점

• 원격 저장소의 최신 상태를 빠르게 반영할 수 있습니다.
• 협업 시 최신 변경 사항을 바로 적용할 수 있습니다.

단점

• 예상치 못한 변경 사항이 자동으로 병합될 수 있습니다.

Git Fetch와 Git Pull의 차이점

비교 항목	Git Fetch	Git Pull
동작 방식	원격 변경 사항을 가져오지만 병합하지 않음	원격 변경 사항을 가져와 현재 브랜치에 병합
적용 여부	수동으로 merge나 rebase 필요	자동으로 병합 진행
충돌 가능성	병합이 없어서 충돌이 일어나지 않음	자동 병합이므로 충돌이 일어날 수 있음
사용 목적	원격 변경 사항을 미리 확인하고 싶을 때	최신 변경 사항을 바로 반영하고 싶을 때

Git Fetch를 사용하면 적절한 상황

• 원격 저장소의 변경 사항을 미리 확인하고 싶을 때 (git fetch 후 git diff 등으로 확인)
• 자동 병합 없이 변경 사항을 수동으로 관리하고 싶을 때
• 브랜치 간 충돌 가능성이 높아 병합 전에 확인이 필요한 경우

Git Pull을 사용하면 적절한 상황

• 최신 변경 사항을 바로 반영하고 싶을 때
• 협업하는 프로젝트에서 팀원의 작업 내역을 빠르게 받아와야 할 때
• 원격 저장소의 내용과 로컬 저장소의 내용을 일치시켜야 하는 경우