빠른 비교
# 처음 가져올 때
git clone <url>
# 원격 변경만 먼저 확인할 때
git fetch
git log HEAD..origin/main --oneline
# 원격 변경을 받아와 현재 브랜치에 반영할 때
git pull갈리는 기준
어떤 원격 동기화 흐름을 먼저 떠올리면 되나
| 상황 | 먼저 떠올릴 선택 |
|---|---|
| 저장소를 처음 내려받기 | git clone <url> |
| 원격 변경만 먼저 확인 | git fetch |
| fetch 후 원격 커밋 비교 | git log HEAD..origin/main |
| 바로 현재 브랜치에 반영 | git pull |
| 선형 히스토리로 반영 | git pull --rebase |
fetch는 원격 추적 브랜치만 갱신하고, 작업 브랜치는 건드리지 않는다
git fetch를 실행하면 origin/main 같은 원격 추적 브랜치(remote-tracking branch)가 최신 커밋으로 갱신됩니다. 이 브랜치는 로컬 저장소 안에 있는 읽기 전용 참조로, 원격의 현재 상태를 가리킵니다. 현재 작업 중인 main 브랜치에는 아무런 변경도 일어나지 않습니다. 덕분에 원격에 어떤 커밋이 쌓였는지 미리 보고 통합 여부를 직접 결정할 수 있습니다.
git fetch origin
git log --oneline HEAD..origin/main # 내가 아직 반영 못 한 원격 커밋 목록
git diff HEAD origin/main # 실제 내용 차이 확인
# 내용을 보고 판단 후 merge 또는 rebase
git merge origin/mainpull은 fetch와 merge(또는 rebase)를 한 번에 수행한다
git pull은 내부적으로 git fetch 후 현재 브랜치에 원격 추적 브랜치를 통합합니다. 기본 동작은 merge이고, --rebase 옵션을 주면 rebase로 통합합니다. 빠른 반영에는 편하지만, 충돌이 있을 때 중간 상태를 확인할 여유 없이 바로 충돌 해결 단계로 진입하게 됩니다. 협업 규모가 커지면 fetch로 먼저 상태를 확인하는 패턴이 더 안전합니다.
git pull # fetch + merge (기본)
git pull --rebase # fetch + rebase (선형 히스토리 유지)
git pull origin main # 특정 원격/브랜치 명시fetch는 확인용, pull은 반영용으로 보면 실수가 줄어든다
원격에 무슨 일이 있었는지 먼저 보고 싶으면 fetch가 맞고, 확인 없이 바로 내 브랜치에 반영해도 되는 상황이면 pull이 맞습니다. 로컬에 아직 push하지 않은 커밋이 있는 상태에서 git pull을 먼저 실행하면 예상치 못한 merge commit이 생기거나 바로 충돌 해결 단계로 들어갈 수 있습니다. 협업 브랜치에서는 보통 fetch -> log/diff 확인 -> merge 또는 rebase 선택이 더 안전합니다.
# 원격만 먼저 확인
git fetch
git log --oneline HEAD..origin/main
# 바로 반영
git pull --rebaseclone은 저장소 전체 객체를 내려받고 origin 리모트를 자동 설정한다
git clone은 단순한 파일 복사가 아닙니다. 원격 저장소의 모든 commit, tree, blob 객체와 refs를 내려받고, origin이라는 이름으로 원격을 자동 등록하며, 기본 브랜치를 checkout한 상태로 작업 디렉터리를 구성합니다. 얕은 clone(--depth)을 쓰면 최근 N개 커밋만 받아 초기 다운로드 시간을 줄일 수 있지만, 전체 히스토리가 없어 bisect나 blame에 제약이 생깁니다.
git clone https://github.com/example/project.git
git clone --depth 1 https://github.com/example/project.git # 얕은 clone
git clone --branch develop <url> # 특정 브랜치 기준으로 clone선택 기준
| 상황 | 적합한 선택 |
|---|---|
| 저장소를 처음 내려받을 때 | git clone <url> |
| 원격 변경을 먼저 확인하고 싶을 때 | git fetch 후 log, diff |
| 확인 없이 바로 브랜치에 반영할 때 | git pull |
| 선형 히스토리를 유지하며 pull할 때 | git pull --rebase |
| 원격 추적 브랜치 상태를 볼 때 | git log HEAD..origin/main |
주의할 점
git pull은 fetch와 merge를 자동으로 합치기 때문에, 로컬에 커밋이 있는 상태에서 실행하면
예상치 못한 merge 커밋이 생길 수 있습니다. 협업 브랜치에서는 git fetch 후 상태를 확인하고
git merge 또는 git rebase를 직접 선택하는 습관이 히스토리를 더 깔끔하게 유지해 줍니다.
git pull
# Merge made by the 'ort' strategy.
# 로컬 작업이 있었는데 먼저 fetch로 보지 않아서
# 원치 않은 merge commit이 생길 수 있음참고 링크
3 sources