1. 들어가며
GitHub와 같은 원격 저장소를 사용해 협업하다 보면 다른 개발자가 반영한 코드를 가져오거나, 로컬 브랜치를 최신 상태로 갱신해야 하는 상황이 자주 발생한다.
이때 사용하는 대표적인 명령어가 git fetch와 git pull이다.
두 명령어는 모두 원격 저장소의 변경 사항을 가져오지만, 가져온 변경 사항을 현재 로컬 브랜치에 자동으로 통합하는지에 차이가 있다.
이번 글에서는 Fetch와 Pull의 동작 원리, 차이점, 적절한 사용 시점과 주요 옵션을 살펴본다.
2. 로컬 브랜치와 원격 추적 브랜치
Fetch와 Pull을 이해하기 위해서는 먼저 로컬 브랜치(Local Branch)와 원격 추적 브랜치(Remote-Tracking Branch)를 구분해야 한다.
GitHub 저장소를 다음 명령어로 복제했다고 가정하자.
git clone https://github.com/example/project.git
일반적으로 다음과 같은 브랜치 참조를 확인할 수 있다.
main
origin/main
두 참조는 이름이 비슷하지만 서로 다른 역할을 한다.
| 구분 | 의미 |
|---|---|
main | 내 컴퓨터에서 직접 작업하는 로컬 브랜치 |
origin/main | 마지막으로 가져온 원격 main의 상태를 나타내는 로컬 참조 |
원격 저장소의 main | GitHub 서버에 실제로 존재하는 브랜치 |
여기서 origin은 원격 저장소를 나타내는 이름으로, 일반적으로 git clone을 실행할 때 기본적으로 설정된다.
중요한 점은 origin/main이 원격 저장소의 최신 상태를 실시간으로 반영하는 것은 아니라는 것이다.
다른 개발자가 GitHub에 새로운 커밋을 Push하더라도 내 로컬의 origin/main은 자동으로 갱신되지 않는다.
최신 정보를 가져오려면 git fetch 또는 git pull과 같은 명령어를 실행해야 한다.
3. git fetch란?
git fetch는 원격 저장소의 최신 커밋과 브랜치 정보를 가져와 로컬의 원격 추적 브랜치를 갱신하는 명령어이다.
가장 큰 특징은 원격 저장소의 변경 사항을 가져오지만, 현재 작업 중인 로컬 브랜치에는 자동으로 통합하지 않는다는 점이다.
3.1. 동작 원리
다음과 같은 상황을 가정하자.
원격 저장소(GitHub)
A --- B --- C --- D --- E (main)
로컬 저장소
A --- B --- C (main, origin/main)
다른 개발자가 원격 저장소에 D, E 커밋을 Push했지만 내 로컬 저장소에는 아직 반영되지 않은 상태이다.
이때 다음 명령어를 실행한다.
git fetch origin
Fetch 이후
A --- B --- C --- D --- E (origin/main)
↑
main
Git은 원격 저장소의 D, E 커밋을 가져오고 origin/main을 E 커밋으로 갱신한다.
하지만 로컬 main은 여전히 C 커밋을 가리킨다.
즉, 원격 저장소의 최신 변경 사항을 가져왔지만 현재 작업 브랜치에는 적용하지 않은 상태이다.
3.2. 가져온 변경 사항 확인하기
Fetch의 장점은 원격 저장소의 변경 사항을 현재 브랜치에 반영하기 전에 미리 검토할 수 있다는 것이다.
# 원격 저장소의 최신 정보 가져오기
git fetch origin
# 로컬 main에는 없는 원격 커밋 확인
git log main..origin/main --oneline
# 로컬 main과 원격 main의 코드 차이 확인
git diff main origin/main
git log main..origin/main은 로컬 main에서는 도달할 수 없지만 origin/main에서는 도달할 수 있는 커밋을 보여준다.
git diff main origin/main은 두 브랜치가 가리키는 커밋의 파일 상태 차이를 보여준다.
이를 통해 다른 개발자가 어떤 코드를 변경했는지 확인할 수 있다.
3.3. 변경 사항을 실제로 반영하려면?
Fetch만 실행하면 로컬 main은 변경되지 않는다.
따라서 가져온 변경 사항을 실제로 반영하려면 별도의 명령어가 필요하다.
git switch main
git merge origin/main
앞선 예시에서는 로컬 main이 원격 main보다 단순히 뒤처져 있으므로 Fast-Forward Merge가 가능하다.
Merge 이후
A --- B --- C --- D --- E
↑
main
origin/main
이제 로컬 main과 origin/main이 동일한 커밋을 가리킨다.
즉, Fetch는 원격 변경 사항을 가져오는 단계와 실제로 반영하는 단계를 분리할 수 있다는 특징이 있다.
3.4. git fetch는 언제 사용할까?
① 원격 저장소의 변경 사항을 미리 확인할 때
다른 개발자가 Push한 코드를 검토한 후 현재 브랜치에 적용할지 결정할 수 있다.
② 현재 작업 브랜치를 변경하고 싶지 않을 때
기능 개발 중 원격 저장소의 최신 정보만 가져오고, 실제 통합은 나중에 수행할 수 있다.
③ Merge 또는 Rebase 전에 원격 정보를 갱신할 때
git fetch origin
# 현재 브랜치에 최신 main을 반영
git rebase origin/main
이처럼 최신 원격 정보를 가져온 후 원하는 통합 방식을 직접 선택할 수 있다.
4. git pull이란?
git pull은 원격 저장소의 변경 사항을 가져온 후 현재 로컬 브랜치에 통합하는 명령어이다.
Fetch가 변경 사항을 가져오는 작업만 수행한다면, Pull은 가져오기와 통합을 함께 수행한다.
일반적인 동작 과정은 다음과 같다.
git pull
│
▼
git fetch
│
▼
Merge 또는 Rebase
│
▼
로컬 브랜치 갱신
단, 실제 통합 방식은 Git 설정과 명령어 옵션에 따라 달라진다.
4.1. 동작 원리
다음과 같은 상황을 가정하자.
원격 저장소
A --- B --- C --- D --- E (main)
로컬 저장소
A --- B --- C (main)
이때 다음 명령어를 실행한다.
git switch main
git pull origin main
Git은 원격 저장소의 D, E 커밋을 가져온 후 현재 로컬 브랜치에 통합한다.
로컬 브랜치가 원격 브랜치보다 단순히 뒤처져 있으므로 Fast-Forward가 가능하다.
Pull 이후
A --- B --- C --- D --- E
↑
main
origin/main
새로운 Merge Commit을 생성하지 않고 로컬 main의 포인터가 E 커밋으로 이동한다.
4.2. 로컬과 원격 브랜치가 분기되었다면?
Pull이 항상 Fast-Forward 방식으로 동작하는 것은 아니다.
다음과 같이 로컬과 원격 브랜치에 서로 다른 커밋이 추가된 상황을 살펴보자.
D --- E (origin/main)
/
A --- B --- C (main)
로컬에는 C 커밋이 추가되었고, 원격에는 D, E 커밋이 추가되었다.
이 경우에는 단순히 브랜치 포인터를 이동하는 것만으로 변경 사항을 통합할 수 없다.
따라서 Merge 또는 Rebase와 같은 통합 전략이 필요하다.
Merge 방식을 선택한 경우
git pull --no-rebase origin main
D --- E
/ \
A --- B --- C --- M (main)
기존 커밋 히스토리를 유지하면서 새로운 Merge Commit M을 생성한다.
Rebase 방식을 선택한 경우
git pull --rebase origin main
A --- B --- D --- E --- C' (main)
로컬 C 커밋의 변경 사항을 원격 브랜치의 최신 커밋 E 위에 다시 적용한다.
따라서 git pull은 단순히 fetch + merge가 아니라, fetch + 선택된 통합 방식이라고 이해하는 것이 정확하다.
또한 Git 설정에 따라 분기된 브랜치에서 통합 방식을 지정하지 않으면 Pull이 중단되고 전략을 선택하라는 메시지가 나타날 수 있다.
4.3. git pull의 주요 옵션
① git pull —ff-only
git pull --ff-only origin main
Fast-Forward가 가능한 경우에만 로컬 브랜치를 갱신한다.
로컬과 원격 브랜치가 분기된 경우 작업을 중단한다.
따라서 로컬 main에 직접 커밋하지 않고 원격 main의 최신 변경 사항만 안전하게 반영하려는 경우 유용하다.
② git pull —rebase
git pull --rebase origin main
원격 변경 사항을 가져온 후 로컬 커밋을 그 위에 다시 적용한다.
개인 작업 브랜치에서 직선적인 커밋 히스토리를 유지하고 싶을 때 적합하다.
③ git pull —no-rebase
git pull --no-rebase origin main
원격 변경 사항을 가져온 후 Merge 방식으로 통합한다.
기존 커밋 히스토리를 유지하면서 변경 사항을 반영하고 싶을 때 적합하다.
4.4. git pull은 언제 사용할까?
① 로컬 브랜치를 최신 상태로 갱신할 때
원격 저장소의 변경 사항을 현재 브랜치에 바로 반영하고 싶을 때 사용한다.
② 변경 사항을 별도로 검토할 필요가 없을 때
원격 변경 내용을 이미 알고 있다면 Pull을 사용하여 가져오기와 통합을 한 번에 수행할 수 있다.
다만 현재 브랜치의 상태에 따라 충돌이나 의도하지 않은 병합이 발생할 수 있으므로 주의해야 한다.
5. git fetch vs git pull 비교
| 비교 항목 | git fetch | git pull |
|---|---|---|
| 목적 | 원격 변경 사항 가져오기 | 원격 변경 사항 가져오기 및 통합 |
| 원격 커밋 다운로드 | O | O |
| 원격 추적 브랜치 갱신 | O | O |
| 현재 로컬 브랜치 자동 변경 | X | O (필요한 경우) |
| 현재 작업 파일 변경 | X | O (변경이 적용되는 경우) |
| Merge 또는 Rebase 수행 | X | 설정에 따라 수행 |
| 장점 | 변경 사항을 검토한 뒤 통합 가능 | 명령어 한 번으로 동기화 가능 |
| 단점 | 별도 통합 작업 필요 | 의도하지 않은 충돌이나 병합 가능 |
| 적절한 상황 | 최신 변경 사항 확인 | 로컬 브랜치 최신화 |
두 명령어의 핵심 차이는 Fetch가 원격 변경 사항을 가져오는 데서 멈추는 반면, Pull은 가져온 변경 사항을 현재 브랜치에 통합한다는 점이다.
6. 실무 활용 예시
Spring Boot 기반 팀 프로젝트에서 feature/notification 브랜치로 알림 기능을 개발하고 있다고 가정하자.
다른 개발자가 사용자 관련 코드를 main에 병합했고, 해당 변경 사항을 알림 기능에 반영해야 하는 상황이다.
STEP 1. 원격 변경 사항 가져오기
git fetch origin
현재 기능 브랜치를 변경하지 않고 최신 원격 정보를 가져온다.
STEP 2. 변경 사항 확인하기
# 현재 브랜치에는 없는 원격 main의 커밋 확인
git log HEAD..origin/main --oneline
# 공통 조상 이후 원격 main의 변경 사항 확인
git diff HEAD...origin/main
git diff HEAD...origin/main은 두 브랜치의 공통 조상을 기준으로 원격 main에서 발생한 코드 변경 사항을 보여준다.
STEP 3. 변경 사항 반영하기
개인 기능 브랜치에서 작업 중이며 Rebase가 허용된다면 다음과 같이 실행한다.
git switch feature/notification
git rebase origin/main
여러 개발자가 공유하는 브랜치라면 기존 히스토리를 유지하는 Merge를 선택할 수 있다.
git switch feature/notification
git merge origin/main
변경 사항을 통합한 이후에는 테스트를 실행한다.
./gradlew test
Git에서 충돌이 발생하지 않았더라도 다른 개발자의 코드 변경으로 인해 컴파일 오류나 기능 문제가 발생할 수 있으므로 테스트가 필요하다.
반대로 로컬 main을 최신 상태로 갱신하기만 하면 되는 상황이라면 다음과 같이 Pull을 사용할 수 있다.
git switch main
git pull --ff-only origin main
이처럼 변경 사항을 먼저 확인하고 통합 방식을 선택하고 싶다면 Fetch, 원격 변경 사항을 바로 반영하고 싶다면 Pull을 사용하는 것이 적절하다.
7. 마무리
git fetch와 git pull은 모두 원격 저장소의 변경 사항을 가져오는 명령어이지만, 가져온 내용을 현재 로컬 브랜치에 자동으로 통합하는지에 차이가 있다.
Fetch는 원격 저장소의 최신 정보를 가져와 원격 추적 브랜치를 갱신하지만 현재 작업 브랜치는 변경하지 않는다.
반면 Pull은 원격 변경 사항을 가져온 후 Merge 또는 Rebase 등의 방식으로 현재 브랜치에 통합한다.
따라서 원격 변경 사항을 먼저 확인하고 싶다면 Fetch를, 변경 사항을 바로 반영하고 싶다면 Pull을 사용하는 것이 적절하다.
결국 중요한 것은 현재 로컬 브랜치와 원격 브랜치의 상태를 이해하고, 변경 사항을 가져오는 것과 실제로 통합하는 작업을 구분하는 것이다.