git pull의 동작 방식 이해하기

git pull이 내부적으로 어떻게 동작하는지 한 번쯤 궁금하셨던 적 있으신가요?

매일 쓰는 명령어지만, 사실 git fetch와 git merge(또는 git rebase) 두 단계의 조합이라는 것을 정확히 알고 쓰는 경우는 많지 않습니다.

git pull은 내부적으로 어떻게 동작할까요?링크를 제목에 복사

git pull의 시그니처는 이렇습니다.

git pull [<options>] [<repository> [<refspec>…]]

실행하면 두 단계가 순서대로 일어납니다.

1. git fetch
2. git merge 또는 git rebase

먼저 원격 저장소의 변경 사항을 다운로드하고, 이후 config 옵션과 명령줄 플래그에 따라 분기된 브랜치를 조정합니다.

결국 git fetch와 git merge를 따로 실행해도 git pull과 동일한 결과를 얻을 수 있습니다. git pull은 커밋, 푸시와 함께 처음 배우는 명령어라 무심코 쓰는 경우가 많지만, 그 이면에는 자동으로 진행되는 병합 과정이 있습니다.

fetch와 merge를 직접 나눠 실행하면 뭐가 달라질까요?링크를 제목에 복사

git pull을 무심코 실행했다가 충돌이 발생하고, 허둥지둥 해결하고 나니 히스토리에 conflict 머지 커밋이 남아있었던 적이 있습니다. 변경 사항을 확인하기 전에 병합이 자동으로 이루어지기 때문에 이런 상황이 생깁니다.

명시적으로 단계를 나누면 이런 장점이 있습니다.

• 병합 전에 원격의 변경 사항을 먼저 확인할 수 있습니다.
• 상황과 목적에 따라 merge와 rebase 중 적절한 전략을 직접 선택할 수 있습니다.
• 예상치 못한 충돌이나 결과를 미리 방지할 수 있습니다.

선형적인 히스토리를 유지하고 싶다면 어떻게 할까요?링크를 제목에 복사

--rebase 옵션을 사용하면 불필요한 병합 커밋 없이 선형적인 히스토리를 유지할 수 있습니다.

git pull --rebase

rebase를 선호하는 팀이라면 pull.rebase=true를 git config에 설정해 두면 매번 옵션을 붙이지 않아도 됩니다.

git config --global pull.rebase true

정리하면링크를 제목에 복사

• git pull은 git fetch + git merge(또는 git rebase)의 조합입니다.
• 편리하지만 변경 사항을 확인하기 전에 병합이 자동으로 이루어진다는 점을 염두에 두어야 합니다.
• 변경 사항을 먼저 검토해야 한다면 git fetch 후 직접 병합하는 방식이 더 안전합니다.
• 선형적인 히스토리를 원한다면 --rebase 옵션 또는 pull.rebase=true 설정을 활용하세요.