git pull 했더니 fatal: Need to specify how to reconcile divergent branches 가 뜰 때: 병합·rebase·ff-only 를 같은 상황에서 직접 돌려 본 결과와 고르는 기준When git pull stops with fatal: Need to specify how to reconcile divergent branches: merge, rebase and ff-only run side by side on the same repositories, and how to choose
git pull 에서 divergent branches 오류를 만난 독자가, 아무것도 망가지지 않았음을 확인하고 병합·rebase·ff-only 중 자기 상황에 맞는 하나를 고르게 돕는다.
시험에서 이 오류는 로컬 브랜치와 작업 폴더를 전혀 바꾸지 않은 채 종료 코드 128 로 멈췄다. 병합은 부모가 둘인 커밋을 하나 더 만들었고, rebase 는 내 커밋의 해시를 바꿔서 이미 push 한 커밋이면 그 뒤 push 가 거부됐다. 커밋 안 한 변경이 있으면 rebase pull 만 거부했고, 충돌이 나면 두 방식에서 HEAD 쪽 내용이 서로 반대였다.
git fetch 뒤 git rev-list --left-right --count HEAD...@{u} 로 양쪽 숫자를 확인하고, 내 커밋을 아직 push 하지 않았으면 git pull --rebase, 이미 push 했거나 팀이 같이 쓰는 브랜치면 git pull --no-rebase 를 쓰고, 한 번 정한 뒤에는 git config 로 기본값을 박아 둬라.
목차
한 줄 요약:
git pull의 divergent branches 오류는 내 브랜치가 안 바뀐 채 멈춘 것이니, push 안 한 커밋이면--rebase, push 했거나 공유 브랜치면--no-rebase로 다시 친다.
hint: You have divergent branches and need to specify how to reconcile them.
...
fatal: Need to specify how to reconcile divergent branches.git pull 을 쳤더니 이렇게 나오고 끝나면 무언가 깨진 것처럼 보인다. 이 글은 같은 상황을 만들어 놓고 --no-rebase(병합), --rebase, --ff-only 를 하나씩 돌려, 각각이 기록을 어떻게 바꾸고 어디서 실패하는지 확인한 결과다. Apple Git 2.54.0(macOS 26.6.2, arm64)에서 사례마다 새 저장소 세 개(원격 하나, 클론 둘)를 만들고, 사용자·시스템 git 설정을 무시한 채 날짜를 고정해 시험 전체를 두 번 돌렸는데 출력이 같았다(해시와 임시 경로는 가렸다, 2026-11-09).
용어 먼저. 갈라졌다(diverged) 는 내 로컬 브랜치와 원격 브랜치에 서로 상대에게 없는 커밋이 하나 이상씩 있다는 뜻이다. 내 쪽이 앞서 있기만 하거나 원격 쪽이 앞서 있기만 하면 갈라진 것이 아니다. 병합(merge) 은 두 갈래를 부모가 둘인 새 커밋 하나로 묶는 것, rebase 는 내 커밋을 원격의 최신 위로 옮겨 다시 만드는 것, fast-forward 는 내가 원격의 조상일 때 포인터만 앞으로 미는 것이다.
이 오류는 내 브랜치를 바꾸지 않고 멈춘 것이다
시험 상황은 이렇다. 같은 원격에서 클론한 A 와 B 가 각자 다른 파일에 커밋을 하나씩 했고, A 가 먼저 push 했다. B 에서 설정 없이 git pull 을 쳤다.
| 확인 항목 | 결과 |
|---|---|
| 종료 코드 | 128 |
| HEAD(내 최신 커밋) | 그대로 |
| 작업 폴더의 변경 파일 수 | pull 전 0, pull 뒤 0 |
git rev-list --left-right --count HEAD...@{u} |
1 1 |
pull 은 가져오는 단계(fetch)까지는 했고(출력에 origin/main 갱신 줄이 있다) 그 뒤 합치는 방식을 정하지 못해 그만뒀다. 그래서 같은 명령을 방식만 붙여 다시 치면 된다. 숫자 둘은 “내가 앞선 커밋 수, 원격이 앞선 커밋 수” 이고, 둘 다 0 보다 크면 갈라진 것이다. 한쪽이 0 이면 이 오류가 안 난다. 시험에서 원격만 앞섰을 때는 그냥 앞으로 밀려 올라왔고(Updating …, 종료 코드 0), 내 쪽만 앞섰을 때는 Already up to date. 였다.
미리 확인하고 싶으면 git fetch 뒤 위 rev-list 명령을 쓰면 된다. git pull 이 하는 일은 fetch 뒤 합치기라는 것을 알면, 이 오류가 곧 “합치기 단계에서 고르라는 요구” 라는 것도 읽힌다.
세 방식이 남기는 모양
같은 갈라진 상태에서 하나씩 시험한 결과다.
| 명령 | 결과 기록 | 내 커밋 해시 | 종료 코드 |
|---|---|---|---|
git pull --no-rebase |
최신 커밋이 병합 커밋(Merge branch 'main' of …, 부모 2개), 양쪽 커밋이 그래프로 갈라졌다 합쳐짐 |
그대로 | 0 |
git pull --rebase |
한 줄로 B: b.txt → A: a.txt → base (부모 1개씩) |
바뀜 | 0 |
git pull --ff-only |
아무것도 안 바뀜, fatal: Not possible to fast-forward, aborting. |
그대로 | 128 |
병합은 기록을 하나도 고치지 않고 커밋을 하나 더한다. rebase 는 기록이 깔끔한 한 줄이 되지만 내 커밋을 새 커밋으로 만들어 해시가 달라진다. --ff-only 는 “합치기를 하지 말고 앞으로 밀 수 있을 때만 하라” 는 방식이라, 갈라진 상태에서는 항상 멈춘다. 즉 --ff-only 는 해결책이 아니라 “갈라졌으면 멈춰라” 라는 선택이다. 이때 오류 문구가 Need to specify… 에서 Not possible to fast-forward 로 바뀌고, git 은 git merge --no-ff 나 git rebase 를 쓰라고 힌트를 준다.
이미 push 한 커밋을 rebase 하면 다음 push 가 거부된다
rebase 가 해시를 바꾼다는 것이 실제로 문제가 되는 장면을 시험했다. B 의 커밋을 feature 라는 이름으로 원격에 먼저 push 해 두고, 로컬에서 git pull --rebase 를 했다. 그 뒤 로컬 커밋 해시는 원격 feature 의 해시와 다르게 됐고, git push origin HEAD:feature 는 이렇게 거부됐다(종료 코드 1).
! [rejected] HEAD -> feature (non-fast-forward)
error: failed to push some refs to '…'옛 해시의 커밋은 원격에 있고 내 쪽에는 같은 내용의 새 해시 커밋이 있으니, 원격 입장에서는 내 브랜치가 갈라진 것이다. 이 상태를 푸는 길로는 강제로 덮어쓰는 push 와 원격 feature 를 다시 가져와 합치는 방법이 있겠지만 이 시험에서는 둘 다 하지 않았다. 여기서 “이미 push 한 커밋” 은 시험처럼 다른 이름(feature)으로 push 해 둔 경우다. 같은 upstream(origin/main)에 push 한 커밋은 rev-list 의 앞선 수가 upstream 에 없는 커밋만 세므로 그 숫자에 잡히지 않는다. 다른 사람이 그 브랜치를 받아 가 있다면 그 사람들의 기록과도 어긋난다. 그래서 이미 push 했거나 다른 사람이 받아 간 커밋이 갈라진 쪽에 있다면 --no-rebase 가 덜 위험하다. 같은 시나리오에서 git pull --no-rebase 로 합친 뒤 git push origin HEAD:feature 는 거부 없이 통과했다(종료 코드 0). 병합은 내 커밋의 해시를 바꾸지 않기 때문이다.
커밋 안 한 변경이 있으면 rebase pull 만 거부한다
base.txt 를 고쳐 놓고 커밋하지 않은 상태에서(갈라진 상태는 그대로, 고친 파일은 가져올 변경과 겹치지 않는다) 두 방식을 돌렸다.
| 명령 | 결과 |
|---|---|
git pull --rebase |
error: cannot pull with rebase: You have unstaged changes. 종료 코드 128 |
git pull --rebase --autostash |
변경을 임시 보관했다가 rebase 뒤 되돌려 놓음, 종료 코드 0, 고친 줄 그대로, 남은 stash 0개 |
git pull --no-rebase |
병합됨, 종료 코드 0, 고친 줄 그대로 |
git 문서(pull.autoStash 항목)에도 “rebase 하는 pull 은 로컬 변경이 있으면 작업을 거부한다” 는 취지의 설명이 있다. 그래서 작업 중 파일이 많은 사람이 pull.rebase true 를 박아 두면 이 거부를 자주 보게 되고, --autostash 를 같이 쓰는 이유가 된다. 시험은 커밋하지 않은 수정 파일 하나일 때만 했고, 추적하지 않는 새 파일이 있을 때는 시험하지 않았다.
충돌이 나면 HEAD 쪽이 서로 반대다
같은 파일의 같은 줄을 A 는 from-a, B 는 from-b 로 고친 뒤 B 에서 pull 했다. 두 방식 모두 종료 코드 1 로 멈췄지만 멈춘 모양이 달랐다.
| 항목 | --no-rebase |
--rebase |
|---|---|---|
상태 표시(git status -sb) |
## main...origin/main [ahead 1, behind 1] |
## HEAD (no branch) |
<<<<<<< HEAD 아래 내용 |
from-b(내 것) |
from-a(원격 것) |
>>>>>>> 줄 |
원격 커밋 해시(출력에서는 가려 둠) | 해시 (B: edit) 내 커밋 |
| 중단 명령 | git merge --abort |
git rebase --abort |
rebase 는 원격의 최신 위에 내 커밋을 하나씩 다시 얹는 중이라 HEAD 가 원격 쪽을 가리킨다. 병합에 익숙한 사람이 HEAD 구역을 “내 것” 으로 알고 rebase 충돌에서 지우면 내 수정을 버리게 된다. 중단 명령을 쓰면 두 경우 모두 HEAD 가 처음의 B: edit 로 돌아오고 변경 파일은 0개였다. 끝까지 해결하려면 충돌 파일을 고치고 git add 한 뒤, 병합은 git commit --no-edit(부모 2개인 병합 커밋이 되었고 그 뒤 push 도 통과했다), rebase 는 git rebase --continue(Successfully rebased and updated, 한 줄 기록)를 썼다. 이 확인은 두 방식 모두 충돌 파일을 both 한 줄로 고쳐서 했다.
잘못 골랐을 때 되돌리기
병합과 rebase 를 각각 끝낸 직후 git reset --hard ORIG_HEAD 를 시험했다. 두 경우 모두 기록이 B: b.txt → base 로 돌아왔고, rebase 뒤에는 내 커밋의 해시도 원래대로 복구됐다(ORIG_HEAD 는 병합·rebase 같은 큰 이동 직전의 HEAD 를 git 이 적어 두는 이름이다). 이 시험은 커밋 안 한 변경이 없는 상태에서만 했다. reset --hard 는 작업 폴더를 덮어쓰는 명령이라 변경이 있으면 쓰기 전에 따로 보관해야 하고, 그 경우는 시험하지 않았다.
기본값 정하기와 우선순위
hint 에 나온 세 설정을 각각 걸어 놓고 옵션 없이 git pull 을 쳤다.
| 설정 | 옵션 없는 git pull 결과 |
|---|---|
pull.rebase true |
rebase (종료 코드 0) |
pull.rebase false |
병합 (종료 코드 0) |
pull.ff only |
fatal: Not possible to fast-forward, aborting. 종료 코드 128 |
pull.rebase true 를 걸고 git pull --no-rebase 를 치면 병합이 됐다. 명령줄 옵션이 설정을 이긴다. 설정 이름은 git 문서 config/pull 에 pull.rebase(true 면 rebase, merges·interactive 값도 있다)와 pull.ff(only 면 fast-forward 만 허용)로 적혀 있다. hint 문구에는 git config 를 git config --global 로 바꾸면 모든 저장소의 기본값이 된다고 적혀 있고, 이 글의 시험은 사용자 설정을 일부러 무시하고 저장소별 설정만 썼으므로 --global 은 직접 시험하지 않았다.
이 경고의 역사는 따로 적는다. git 2.27 릴리스 노트에는 pull.rebase 가 정해지기 전까지 git pull 이 경고를 낸다고 적혀 있다. 반대로 git 문서 master 의 git pull 첫머리에는 --ff-only 에 “This is the default.” 라고 적혀 있는데, 이 글에서 확인한 2.54.0 은 설정이 없으면 위 오류로 멈췄다. 문서와 설치된 버전의 기본 동작이 다를 수 있다. 이 글에서 확인한 2.54.0 에서는 갈라진 상태에서 경고가 아니라 fatal 로 멈췄다. 확인한 버전은 이 하나뿐이어서 어느 버전부터 그렇게 바뀌었는지, 다른 버전의 기본 동작은 모른다.
내가 고르는 기준
이 부분은 시험 결과가 아니라 내 판단이다. 혼자 쓰는 로컬 브랜치에 아직 push 하지 않은 커밋이면 --rebase 가 기록이 깔끔해서 낫다. 한 번이라도 push 했거나 다른 사람이 받아 갈 수 있는 브랜치라면 --no-rebase 로 병합 커밋 하나를 더 받아들이는 편이 위의 push 거부를 안 만난다. 어느 쪽이든 고르기 귀찮다면 pull.ff only 를 전역 기본값으로 두고, 오류가 날 때마다 git fetch 와 rev-list 숫자를 보고 그때 git merge 나 git rebase 를 직접 치는 방법도 있다. 이 오류를 보는 일 자체가 “지금 내 브랜치와 원격이 갈라졌다” 는 신호가 되기 때문이다.
시험 환경과 범위
Apple Git 2.54.0(/usr/bin/git), macOS 26.6.2 arm64, 같은 로컬 디스크 위의 bare 원격과 클론 두 개로 시험했다. GitHub·GitLab 같은 실제 서버, ssh·https 원격, 다른 git 버전, 보호된 브랜치, 병합 커밋이 섞인 로컬 기록의 rebase, 여러 커밋의 rebase 충돌, 추적하지 않는 파일이 있는 경우, 강제 push 는 시험하지 않았다. 시험 스크립트와 출력은 이 글의 작업 폴더에 두 번의 실행 결과와 함께 보관했다.
세 줄 요약
- 오류가 떠도 내 브랜치는 그대로이고(종료 코드 128, HEAD·작업 폴더 변경 없음),
git fetch뒤git rev-list --left-right --count HEAD...@{u}의 양쪽이 모두 0 보다 크면 갈라진 것이다. - 내 커밋을 아직 push 하지 않았으면
git pull --rebase, 이미 push 했거나 팀이 같이 쓰는 브랜치면git pull --no-rebase가 push 거부를 피하고, 잘못 골랐으면git reset --hard ORIG_HEAD로 되돌린다. - 커밋 안 한 변경이 있으면 rebase pull 만 거부하고(
--autostash로 해결), rebase 충돌에서는HEAD구역이 원격 내용이라는 점을 기억한 뒤git config pull.rebase로 기본값을 정해라.
To help a reader who met the divergent branches error from git pull confirm that nothing was damaged and choose between merge, rebase and ff-only for their situation.
In my tests the error stopped with exit code 128 and changed neither the local branch nor the working folder. Merge added one more commit with two parents, while rebase changed the hash of my commit, so a commit that was already pushed was rejected on the next push. Uncommitted edits made only the rebase pull refuse, and on a conflict the HEAD side held opposite content in the two methods.
After git fetch, run git rev-list --left-right --count HEAD...@{u} and read both numbers. If you have not pushed your commits yet, use git pull --rebase; if you already pushed them or the branch is shared, use git pull --no-rebase. Once you have decided, store the choice with git config.
Contents
- The error stops without changing my branch
- What the three methods leave behind
- Rebasing an already pushed commit gets the next push rejected
- With uncommitted changes, only the rebase pull refuses
- On a conflict, the HEAD side is opposite
- Undoing a wrong choice
- Setting a default, and which wins
- How I choose
- Test environment and scope
- Three-line summary
One-line summary: The divergent branches error from
git pullmeans it stopped with my branch untouched, so run it again with--rebaseif the commits are not pushed, or--no-rebaseif they are pushed or the branch is shared.
hint: You have divergent branches and need to specify how to reconcile them.
...
fatal: Need to specify how to reconcile divergent branches.When you type git pull and it ends like this, it looks as if something broke. This article builds the same situation and runs --no-rebase (merge), --rebase and --ff-only one by one, to see how each changes the history and where each fails. It was tested with Apple Git 2.54.0 (macOS 26.6.2, arm64): every case used three fresh repositories (one remote, two clones), user and system git configuration was ignored, dates were fixed, and the whole test ran twice with identical output (hashes and temporary paths were masked, 2026-11-09).
Terms first. Diverged means that your local branch and the remote branch each have at least one commit the other lacks. If only your side is ahead, or only the remote side is ahead, they have not diverged. Merge ties two lines into one new commit with two parents, rebase moves your commits on top of the remote’s latest and recreates them, and fast-forward just slides the pointer forward when you are an ancestor of the remote.
The error stops without changing my branch
The test situation: A and B cloned the same remote, each made one commit touching a different file, and A pushed first. In B, git pull was run with no configuration.
| What was checked | Result |
|---|---|
| Exit code | 128 |
| HEAD (my latest commit) | unchanged |
| Changed files in the working folder | 0 before the pull, 0 after |
git rev-list --left-right --count HEAD...@{u} |
1 1 |
The pull did get as far as fetching (the output has an origin/main update line) and then gave up because it could not decide how to combine. So you can run the same command again with a method attached. The two numbers are “commits I am ahead by, commits the remote is ahead by”, and if both are above 0 the branches have diverged. If one of them is 0 the error does not appear. In the test, when only the remote was ahead the branch simply moved forward (Updating …, exit code 0), and when only my side was ahead the output was Already up to date.
To check in advance, run git fetch and then the rev-list command above. Once you know that git pull means fetch followed by combine, the error also reads as “the combine step demands that you choose.”
What the three methods leave behind
Results from running each one on the same diverged state.
| Command | Resulting history | Hash of my commit | Exit code |
|---|---|---|---|
git pull --no-rebase |
the latest commit is a merge commit (Merge branch 'main' of …, two parents); both commits appear as a graph that splits and rejoins |
unchanged | 0 |
git pull --rebase |
a single line: B: b.txt → A: a.txt → base (one parent each) |
changed | 0 |
git pull --ff-only |
nothing changed, fatal: Not possible to fast-forward, aborting. |
unchanged | 128 |
Merge does not rewrite any history; it adds one commit. Rebase gives a clean single line but rebuilds my commit as a new commit, so its hash differs. --ff-only means “do not combine; move forward only when that is possible”, so on a diverged state it always stops. In other words --ff-only is not a fix but a choice to stop when diverged. In that case the message changes from Need to specify… to Not possible to fast-forward, and git hints at git merge --no-ff or git rebase.
Rebasing an already pushed commit gets the next push rejected
I tested the scene where the changed hash becomes a real problem. B’s commit was first pushed to the remote under the name feature, and then git pull --rebase was run locally. Afterwards the local commit hash differed from the hash of the remote feature, and git push origin HEAD:feature was rejected like this (exit code 1).
! [rejected] HEAD -> feature (non-fast-forward)
error: failed to push some refs to '…'The commit with the old hash is on the remote and my side has a commit with the same content under a new hash, so from the remote’s point of view my branch has diverged. Ways out of this include a push that forcibly overwrites and fetching the remote feature to combine it, but this test did none of them. Here “already pushed” means a commit pushed under another name (feature) as in the test. A commit pushed to the same upstream (origin/main) does not show up in the ahead count of rev-list, because that count only includes commits the upstream lacks. If other people have already pulled that branch, their history will also disagree with it. So if the commits on the diverged side are already pushed or taken by others, --no-rebase is the less risky choice. In the same scenario, after combining with git pull --no-rebase, git push origin HEAD:feature went through without rejection (exit code 0), because a merge does not change the hash of my commit.
With uncommitted changes, only the rebase pull refuses
With base.txt edited and not committed (the diverged state unchanged, and the edited file not overlapping with the incoming changes), I ran the methods.
| Command | Result |
|---|---|
git pull --rebase |
error: cannot pull with rebase: You have unstaged changes. exit code 128 |
git pull --rebase --autostash |
the change was shelved temporarily and restored after the rebase, exit code 0, the edited line intact, 0 stashes left |
git pull --no-rebase |
merged, exit code 0, the edited line intact |
The git documentation (the pull.autoStash entry) also says that a rebasing pull refuses to work with local changes. So someone with many files in progress who stores pull.rebase true will see this refusal often, which is why --autostash is used along with it. The test used a single modified file that was not committed; it did not cover new files that git does not track.
On a conflict, the HEAD side is opposite
A changed the same line of the same file to from-a and B to from-b, and then B pulled. Both methods stopped with exit code 1, but the stopped state differed.
| Item | --no-rebase |
--rebase |
|---|---|---|
Status display (git status -sb) |
## main...origin/main [ahead 1, behind 1] |
## HEAD (no branch) |
Content under <<<<<<< HEAD |
from-b (mine) |
from-a (the remote’s) |
The >>>>>>> line |
the remote commit hash (masked in the output) | hash (B: edit), my commit |
| Command to stop | git merge --abort |
git rebase --abort |
A rebase is replaying my commits one by one on top of the remote’s latest, so HEAD points at the remote side. Someone used to merges who believes the HEAD section is “mine” and deletes it in a rebase conflict will throw away their own edit. With the abort commands, in both cases HEAD returned to the original B: edit and there were 0 changed files. To resolve it all the way, I fixed the conflicted file, ran git add, and then used git commit --no-edit for the merge (it became a merge commit with two parents and the push afterwards also went through) or git rebase --continue for the rebase (Successfully rebased and updated, a single-line history). That check was done with both methods by fixing the conflicted file to a single line, both.
Undoing a wrong choice
I tested git reset --hard ORIG_HEAD right after finishing a merge and right after finishing a rebase. In both cases the history went back to B: b.txt → base, and after the rebase the hash of my commit was restored as well (ORIG_HEAD is the name under which git records HEAD just before a big move such as a merge or rebase). This was tested only with no uncommitted changes. reset --hard overwrites the working folder, so if there are changes they must be set aside first, and that case was not tested.
Setting a default, and which wins
I set each of the three settings from the hint and ran git pull with no option.
| Setting | Result of git pull with no option |
|---|---|
pull.rebase true |
rebase (exit code 0) |
pull.rebase false |
merge (exit code 0) |
pull.ff only |
fatal: Not possible to fast-forward, aborting. exit code 128 |
With pull.rebase true set, running git pull --no-rebase produced a merge. The command-line option beats the setting. The setting names are documented in the git documentation config/pull as pull.rebase (true means rebase; merges and interactive values also exist) and pull.ff (only allows fast-forward only). The hint text says that replacing git config with git config --global makes it the default for every repository; the tests here deliberately ignored user configuration and used per-repository settings only, so --global was not tested directly.
The history of this warning is noted separately. The git 2.27 release notes say git pull issues a warning until pull.rebase is set. On the other hand, the opening of the git pull page in the master git documentation says “This is the default.” for --ff-only, yet the 2.54.0 checked here stopped with the error above when nothing was set. The documentation and the installed version may differ in default behavior. In 2.54.0, which this article checked, a diverged state stopped with fatal, not a warning. That is the only version checked, so I do not know from which version it changed or how other versions behave by default.
How I choose
This part is my judgment, not a test result. For a local branch that only I use and whose commits are not pushed yet, --rebase is better because the history stays clean. For a branch that has been pushed even once, or that others may pull, accepting one more merge commit with --no-rebase avoids the push rejection above. If choosing every time is tiresome, you can also keep pull.ff only as a global default and, whenever the error appears, look at the git fetch and rev-list numbers and then run git merge or git rebase yourself. Seeing the error is itself the signal “my branch and the remote have diverged.”
Test environment and scope
Apple Git 2.54.0 (/usr/bin/git), macOS 26.6.2 arm64, a bare remote and two clones on the same local disk. Real servers such as GitHub or GitLab, ssh or https remotes, other git versions, protected branches, rebasing a local history that contains merge commits, rebase conflicts over several commits, cases with untracked files, and forced pushes were not tested. The test script and its output are kept in this article’s working folder together with the results of both runs.
Three-line summary
- Even when the error appears my branch is unchanged (exit code 128, no change to HEAD or the working folder), and if after
git fetchboth numbers ofgit rev-list --left-right --count HEAD...@{u}are above 0 the branches have diverged. - If you have not pushed your commits, use
git pull --rebase; if you pushed them or the team shares the branch,git pull --no-rebaseavoids the push rejection, andgit reset --hard ORIG_HEADundoes a wrong choice. - With uncommitted changes only the rebase pull refuses (use
--autostash); in a rebase conflict remember that theHEADsection is the remote’s content, then set a default withgit config pull.rebase.