pull은 fetch + integration

git pull은 하나처럼 보이는 두 작업이야

git pull은 git fetch 뒤에 통합 단계를 이어 붙인 줄임말이야. 기본은 merge이고 rebase를 고를 수도 있어. 혼란은 두 번째 단계에서 생겨. 아무 생각 없이 git pull하면 branch가 발산했을 때 로컬 branch에 merge commit을 만들 수 있는데, 짧은 feature 작업에서는 대개 원하지 않는 결과야.

통합 방법은 둘 다 타당해. Merge는 필요하면 merge commit을 만들어 upstream 변경과 합치며, 발산한 모양을 이력에 보존해. 장기 integration branch나 release처럼 발산 자체가 의미 있을 때 좋아. Rebase는 로컬 commit을 upstream tip 위에 다시 replay해 직선 이력을 만들어. 내가 작업하는 동안 누군가도 작업했다는 정도의 짧은 feature branch에 잘 맞아.

현대적인 기본값으로는 global pull.rebase = true를 두고 날마다 plain git pull을 쓰는 방식을 권할 만해. 직선 이력은 읽기와 bisect가 쉽고, 검토자도 feature에 main을 merge한 잡음 대신 한 줄의 chain을 보게 돼. release branch 통합이나 큰 기능 handoff처럼 진짜 merge가 필요할 때는 명시적으로 git merge를 쓰고, git pull은 일상적인 통합에 남겨둬.

실패 모드도 둘 기억해. commit하지 않은 변경과 pull: 통합이 같은 파일을 건드리면 Git이 거부하므로 먼저 commit하거나 stash해. pull rebase 중 conflict: rebase는 충돌한 commit마다 멈추고 해결 뒤 git rebase --continue를 요구해. 과정이 잘못됐다면 git rebase --abort로 pull 전 상태까지 돌아갈 수 있어.

Code

Daily-grade pull 패턴·bash

# 한 번 설정, 잊어:
git config --global pull.rebase true
git config --global rebase.autoStash true   # dirty tree 자동 stash

# feature branch 일상 pull:
git pull           # 위 global 설정과 함께 = fetch + rebase

# 일회성 merge pull (rebase default 오버라이드):
git pull --no-rebase

# fetch 만 + 통합 안 하고 수동 선택:
git fetch
git rebase origin/main      # 또는 git merge origin/main

Pull 이 꼬일 때·bash

# pull 전에 dirty tree?
git stash push -u -m "pre-pull WIP"
git pull
git stash pop      # 또는 git stash apply

# rebase pull 중 conflict:
# 충돌 파일 편집 후:
git add resolved-file
git rebase --continue
# ... 또는 통째로 빠지기:
git rebase --abort

# 헷갈린 merge pull 후 undo:
git reset --merge ORIG_HEAD

Exercise

실제 repo에서 global pull.rebase = true와 rebase.autoStash = true를 설정해. 로컬에서 commit하고 다른 clone에서 push해 발산을 만든 뒤 원래 clone에서 git pull해. git log --oneline --graph로 직선 이력을 확인해. reset한 다음 이 repo에 pull.rebase = false를 설정하고 같은 발산을 반복해 merge commit을 관찰해. 어떤 종류의 branch에 어느 정책이 맞는지 결정해봐.

git pull은 하나처럼 보이는 두 작업이야

Code

External links

Exercise

Progress

댓글 0