Git Pull vs Fetch: 언제, 어떻게 사용할까?

Git을 사용하다 보면 git pull과 git fetch는 가장 자주 사용하는 명령어 중 하나입니다. 두 명령어 모두 원격 저장소의 변경 사항을 가져오는 역할을 하지만, 작동 방식과 사용 시점에 미묘한 차이가 있습니다. 따라서 이 차이를 명확히 이해해보려고 합니다.

Git Pull = Fetch + Merge/Rebase

가장 핵심적인 차이부터 알아보겠습니다. git pull은 사실 두 가지 명령어를 합친 것과 같습니다.

1. git fetch: 원격 저장소(예: origin)의 최신 변경 이력을 로컬 저장소로 가져옵니다. 하지만 이때 내 작업 브랜치(feature/기능1)에는 어떠한 변경도 적용하지 않습니다. 단지 원격 브랜치(origin/main)의 최신 정보만 업데이트할 뿐입니다.
2. git merge (기본) 또는 git rebase: fetch로 가져온 원격 브랜치의 내용을 현재 내가 작업 중인 로컬 브랜치에 **자동으로 병합(merge)하거나 재배치(rebase)**합니다. 이 과정에서 내 로컬 코드가 실제로 변경됩니다.

즉, fetch는 “원격에 무슨 일이 있었는지 살펴보기만 하는 것”이고, pull은 “살펴보고 내 코드에 바로 합치기까지 하는 것”입니다.

왜 최신 Main 브랜치를 내 작업 브랜치에 반영해야 할까?

“작업이 다 끝난 후에 한 번에 PR(Pull Request)로 합치면 안 되나요?”

물론 가능합니다. 하지만 권장하지 않는 방법이며, 그 이유는 다음과 같습니다.

• 충돌(Conflict) 가능성 증가: 내가 작업하는 동안 main 브랜치는 계속해서 변경됩니다. 이 차이가 벌어질수록 나중에 내 코드를 합칠 때 거대한 코드 충돌이 발생할 확률이 기하급수적으로 높아집니다. 작은 충돌은 해결하기 쉽지만, 큰 충돌은 많은 시간과 노력을 소모시킵니다.
• 기능 불일치 및 중복 작업: 동료가 main에 추가한 새로운 기능이나 중요한 버그 수정이 내 작업 브랜치에는 반영되지 않아, 내 기능이 의도치 않게 오작동하거나 이미 해결된 문제를 나도 모르게 다시 작업하게 될 수 있습니다.
• 어려운 코드 리뷰: 내 PR이 main의 최신 상태를 반영하지 않으면, 리뷰어는 내 코드 변경분과 그동안 main에 쌓인 변경분을 모두 고려해야 하므로 리뷰가 복잡해지고 지연될 수 있습니다.

결론적으로, 주기적으로 main 브랜치의 최신 코드를 내 작업 브랜치로 가져오는 것은 나중에 발생할 큰 문제를 미리 방지하고, 팀 전체의 개발 생산성을 높이는 매우 중요한 습관입니다.

안전하고 효율적인 워크플로우 추천

그렇다면 어떻게 main의 변경 사항을 내 feature 브랜치로 가져오는 것이 가장 좋을까요? pull을 직접 사용하는 것보다 fetch를 활용하는 것이 더 안전하고 명확합니다.

추천 워크플로우: fetch + merge 또는 rebase

현재 feature/기능1 브랜치에서 작업 중이라고 가정해 보겠습니다.

1. git fetch origin: 먼저 fetch 명령어로 원격 저장소(origin)의 모든 최신 정보를 가져옵니다. 이제 내 로컬에는 origin/main의 최신 상태가 저장되었지만, 내 feature/기능1 브랜치는 아직 그대로입니다.
2. (선택) 변경 사항 확인: git log HEAD..origin/main 명령어로 main 브랜치에 어떤 변경 사항이 있었는지 미리 확인할 수 있습니다.
3. 변경 사항 통합: 이제 두 가지 방법 중 하나를 선택해 main의 변경 사항을 내 브랜치로 가져옵니다.
   • Merge: git merge origin/main
     • main 브랜치의 변경 이력을 내 feature 브랜치에 합칩니다. “Main 브랜치의 내용을 합쳤다”는 새로운 Merge 커밋이 남습니다. 히스토리가 명확하게 유지된다는 장점이 있습니다.
   • Rebase: git rebase origin/main
     • 내 feature 브랜치의 시작점을 main 브랜치의 최신 커밋으로 옮깁니다. 내 커밋들이 main의 최신 커밋 위에 차곡차곡 다시 쌓이는 형태가 되어, 커밋 히스토리가 한 줄로 깔끔하게 정리됩니다. PR 전에 히스토리를 정리할 때 매우 유용합니다.

자동 Fetch 도구

주기적으로 fetch를 실행하는 것은 중요하지만 매번 직접 입력하기는 번거로울 수 있습니다. 다행히 대부분의 최신 개발 도구들이 이 기능을 지원합니다.

• IDE (VS Code, IntelliJ 등): 소스 제어 탭이나 상태 표시줄의 동기화 버튼을 통해 백그라운드에서 자동으로 fetch를 수행하거나 클릭 한 번으로 실행할 수 있습니다.
• Git GUI 클라이언트 (Sourcetree, GitKraken 등): 앱을 열어두는 것만으로도 주기적으로 fetch를 실행하여 원격 브랜치의 변경 사항을 시각적으로 보여줍니다.

정리

• git pull = git fetch + git merge/rebase
• 안전한 작업을 위해, pull로 한 번에 합치기보다 fetch로 먼저 변경 사항을 가져온 후, 내용을 확인하고 merge나 rebase로 직접 통합하는 습관을 들이는 것이 좋습니다.
• 주기적으로 main 브랜치와 동기화하면 나중에 발생할 큰 충돌을 예방하고 안정적인 개발이 가능합니다.

이러한 Git 워크플로우를 팀에 정착시킨다면 훨씬 더 효율적이고 즐거운 협업 경험을 만들 수 있을 것입니다.

참고

• Pro Git 2nd Edition by git-scm.com - https://git-scm.com/book/ko/v2
• GitHub Docs - https://docs.github.com/ko
• Google Gemini