hint: You have divergent branches and need to specify how to reconcile them. hint: You can do so by running one of the following commands sometime before hint: your next pull: hint: hint: git config pull.rebase false # merge hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast- forward only hint: hint: You can replace "git config" with "git config –global" to set a default hint: preference for all repositories. You can also pass –rebase, –no-rebase, hint: or –ff-only on the command line to override the configured default per hint: invocation.

이 메시지는 git pull을 실행하려고 할 때 로컬 브랜치와 원격 브랜치 간에 서로 다른 커밋이 존재 해서 Git이 어떻게 병합할지 결정할 수 없을 때 나옵니다. 즉, 분기(divergent)가 생긴 상태입니다. 이 상황에서 Git은 자동으로 병합하거나 리베이스하지 않고, 당신이 어떻게 처리할지 명시하라고 요구합니다.

해결 방법

당신이 원하는 병합 방식에 따라 아래 중 하나를 실행하시면 됩니다:

1. 기본 병합 방식 (merge) 사용

git config pull.rebase false

  • git pull은 fetch 후 merge를 수행합니다.

  • 커밋 기록이 병합 커밋을 포함해 비교적 복잡해질 수 있습니다.

2. 리베이스 (rebase) 사용

git config pull.rebase true

  • git pull은 fetch 후 rebase를 수행합니다.

  • 깔끔한 커밋 히스토리를 원할 때 좋지만, 충돌 시 더 복잡할 수 있습니다.

3. fast-forward만 허용 (충돌이나 병합 안 함)

git config pull.ff only

  • 현재 브랜치가 원격 브랜치의 조상(commit)일 때만 병합이 일어납니다.

  • divergence가 생기면 pull이 실패합니다. 안전하지만 융통성 없음.

전역 설정으로 바꾸려면

모든 저장소에서 동일한 방식으로 사용하려면 --global 옵션을 추가합니다:

예:

git config --global pull.rebase false

단발성으로 실행하려면

다음 pull 명령어에서만 적용하려면 아래와 같이 옵션을 추가하십시오:

git pull --rebase

또는

git pull --no-rebase

또는

git pull --ff-only

요약하자면

Git이 자동으로 선택하지 않고, 당신에게 병합 전략을 정하라고 말하는 중입니다. 설정을 안 하면 다음에 또 같은 경고가 나옵니다.

개인적으로는 협업 중이라면 rebase는 신중히 사용 하고, 단순히 최신 상태로만 만들고 싶다면 --ff-only나 --no-rebase가 안전합니다.

어떤 방식을 기본값으로 정하실지 확실하지 않다면 사용 중인 워크플로우나 팀 규칙을 먼저 확인하시는 게 좋습니다.

나는 그냥 github에서 워크플로우 파일 하나 지웠을 뿐이거든? 이걸 왜 자동으로 병합 안해주는거야?

좋은 의문입니다. 요점만 말씀드리면:

Git은 양쪽 브랜치에 변화가 있는 경우엔 자동 병합을 하지 않습니다 , 심지어 그게 사소한 것처럼 보여도요.

당신이 GitHub에서 워크플로우 파일을 삭제했는데, 로컬에서도 뭔가 다른 작업(커밋)을 이미 한 상태 라면, Git 입장에선 이렇게 생각합니다:

  • 원격: 워크플로우 파일이 삭제됨 (A)

  • 로컬: 예를 들어 다른 파일 수정 또는 커밋이 있음 (B)

이 경우는 "서로 다른 방향으로 진화했다"는 것이고, Git은 "당신이 어떤 방식으로 병합하고 싶은지 모르겠다"고 판단합니다.

왜 자동 병합 안 하느냐?

Git은 보수적 입니다. 병합 자동화를 시도하다가 히스토리를 꼬아버리는 것보다, 사용자에게 의도를 확인하는 게 더 안전하다고 보기 때문 입니다. 특히 rebase냐 merge냐는 팀 내 정책이 엇갈릴 수 있어서 Git이 결정하려 들지 않습니다.

그럼 어떻게 해야 하느냐?

1. 아무거나 머지해도 상관없으면:

git pull --no-rebase

이건 그냥 fetch하고 merge해서 자동 병합합니다. Git이 병합 커밋을 하나 만들 수도 있지만, 기능상 문제 없습니다.

2. 커밋 히스토리를 깔끔하게 유지하고 싶다면:

git pull --rebase

당신의 로컬 커밋을 원격의 최신 커밋 위로 다시 "재적용"합니다.

마지막으로

"단순히 GitHub에서 파일 하나 삭제했는데 왜 이 난리야?"라는 감정, 지극히 타당합니다.

Git은 파일 삭제가 아니라 히스토리의 불일치 를 문제 삼는 겁니다. 변경된 파일이 뭔지는 중요하지 않고 , 로컬과 원격이 서로 다른 상태에서 커밋이 생겼다면 그걸 병합하는 방식을 당신이 명시하라는 철학 을 갖고 있습니다.

병합 방식만 한 번 설정해주면 그 다음부턴 이런 메시지 안 나옵니다. 그냥 귀찮은 한 번입니다.

그런데 보통 다른게 있으면 자동으로 합쳐주고 conflict 나는 경우만 내가 처리를 했던 것 같은데, 내가 뭘 설정을 했던거야?

예리하십니다. 맞습니다. 평소에는:

로컬과 원격에 모두 변경이 있어도, 충돌(conflict)이 없으면 Git이 그냥 자동으로 merge pull을 해줍니다.

그런데 이번에는 왜 갑자기 "어떻게 병합할래?"라고 물어봤냐면, 당신이 예전에 Git 설정을 바꿨을 가능성이 매우 높습니다.

🔍 핵심 원인

아마도 당신은 과거에 다음 중 하나 를 설정했을 겁니다:

git config --global pull.rebase false

or

git config --global pull.rebase true

or

git config --global pull.ff only

이 설정은 "pull을 어떻게 처리할지 명시적으로 지정하지 않으면 Git이 알아서 못하게 만들라"는 명령 입니다.
즉, Git이 자동으로 결정 못 하도록 보수적인 모드로 전환한 것 입니다.

🔧 확인 방법

다음 명령어로 현재 설정을 확인해보세요:

git config --global --get pull.rebase
git config --global --get pull.ff

출력 결과 예시:

  • true → rebase 하도록 강제함

  • false → merge 하도록 강제함

  • only → fast-forward만 허용 (충돌 없어도 머지 커밋 생기면 안 됨)

또는 전체 global 설정을 보려면:

git config --global --list

✅ 정리

  • Git은 기본적으로 충돌 없으면 자동 머지 합니다.

  • 하지만 당신이 pull.rebase, pull.ff 관련 설정을 했으면 Git은 더 이상 자동 선택을 하지 않습니다.

  • 이번에 그 설정이 발동한 겁니다. 그래서 물어본 거죠: “rebase 할래? merge 할래? ff-only 할래?”

🚀 해결

git config --global --unset pull.rebase
git config --global --unset pull.ff

이렇게 설정을 제거하면 Git은 다시 "알아서" 처리하려고 합니다.
또는 그냥 명확하게 하나 선택해서 설정해도 됩니다.

필요 이상으로 복잡하게 굴었다고 느껴지신다면… 네, 그게 맞습니다. Git은 개발자에게 너무 많은 선택지를 줍니다.

사람들이 가장 일반적으로 쓰는 옵션이 뭘까?

좋은 질문입니다. 결론부터 말씀드리면:

가장 일반적으로 쓰이는 기본 pull 방식은merge입니다.

즉:

git pull --no-rebase

이게 Git의 기본값 이고, 많은 사람들과 팀들이 그냥 이걸 씁니다.

📊 왜 merge가 가장 흔하냐?

  • Git을 설치한 후 아무 설정도 안 하면 기본이 merge입니다.

  • 대부분의 GUI 툴 (예: GitHub Desktop, VS Code, SourceTree 등)도 기본적으로 merge로 설정돼 있음.

  • 충돌이 없으면 별문제 없이 작동함.

  • 익숙한 사용자 경험: “pull 했더니 알아서 최신 상태가 되었다”

🤔 그런데 왜 사람들이 rebase도 쓰나?

  • 커밋 히스토리를 깔끔하게 정리 하고 싶은 개발자들이 선호함.

  • 병합 커밋(merge commit)이 남지 않아서 git log가 간결해짐.

  • GitHub에서 pull request 전에 항상 rebase 하라고 하는 팀 도 많음 (히스토리 깔끔하게 유지하려고).

하지만 rebase는:

  • 실수 시 되돌리기 까다롭고

  • 충돌 처리할 때 머리 아픔

  • 협업 중이면 위험할 수 있음 (공유된 커밋을 rebase 하면 히스토리가 꼬임)

그래서 고급 사용자나 히스토리 강박 있는 사람들만 자주 씁니다.

🎯 실무에서 많이 쓰는 전략

전략 실무에서 사용 이유
git pull 기본, 자동 merge. 가장 흔하고 무난함.
git pull --rebase 히스토리를 깔끔하게 유지하고 싶을 때
git pull --ff-only CI/CD 환경이나 깃 히스토리 깨지면 안 되는 상황에서

📌 추천

  • 혼자 개발 → merge 쓰면 편함.

  • 팀 협업인데 히스토리 깨끗하게 유지하고 싶음 → rebase 고려.

  • CI/CD 자동화 중 → ff-only 사용해서 히스토리 예외 차단.

요약하자면:

아무 설정도 안 하고 그냥git pull만 쓰는 게 사람들이 가장 일반적으로 하는 방식이고, 그건 곧 merge 방식입니다.
특별한 이유가 없다면 그대로 두는 게 현실적으로 제일 무난합니다.

그러면 merge 방식을 default global로 설정하는 법 알려줘

네, Git에서 merge 방식으로git pull을 기본 설정하려면 아래 명령어를 실행하시면 됩니다:

git config --global pull.rebase false

이렇게 하면:

  • 앞으로 git pull 할 때 Git은 fetch + merge를 기본으로 수행합니다.

  • 별도로 --rebase나 --ff-only 옵션을 주지 않아도 됩니다.

  • GUI 툴도 대부분 이 설정을 따라갑니다 (VS Code 등).

확인하려면

정상적으로 설정됐는지 확인하려면:

git config --global --get pull.rebase

출력:

false

이렇게 나오면 merge 방식이 기본으로 설정된 겁니다.

추가로 혹시 이전에 --ff only 설정한 게 있다면, 충돌을 방지하기 위해 이것도 같이 제거해주는 걸 권장드립니다:

git config --global --unset pull.ff

이제부터는 Git이 “어떻게 병합할래요?” 같은 질문 없이 그냥 자동 merge 해줄 겁니다.

근데 기본 git 설정은 fast forward야?

정확하게 짚으셨습니다. 이 부분은 많은 사람들이 헷갈려 하는데, 정리하면 이렇습니다:

✅ Git의 기본 pull 설정은?

git pull

을 아무 설정 없이 실행하면 Git의 동작은 fetch + merge이고,
그 중 merge 방식은 기본적으로 “fast-forward 허용”입니다.

📌 정리하면:

  • pull 기본 동작: fetch + merge

  • merge 기본 동작: fast-forward 가능한 경우엔 fast-forward로 병합
    (즉, 별도의 병합 커밋 없이 브랜치 포인터만 옮김)

  • fast-forward가 불가능한 경우에는 merge 커밋을 생성함

예시로 설명

▶ fast-forward 가능한 경우

A---B---C (main)
         \
          D---E (feature)

만약 main에는 커밋이 아무것도 없고, feature만 커밋이 있다면
git checkout main && git merge feature 하면 fast-forward로 병합됩니다. (C에서 E로 브랜치 포인터만 이동)

▶ fast-forward 불가능한 경우

A---B---C---D (main)
         \
          E---F (feature)

이 경우에는 두 브랜치가 서로 다른 커밋을 가졌기 때문에
Git은 merge 커밋을 만들어야 합니다.

💡 그럼 pull.ff only는 뭐냐?

git config --global pull.ff only 는:

“fast-forward 병합만 허용 하고, merge 커밋은 절대 만들지 마라”는 의미입니다.

이 설정을 하면 fast-forward가 불가능한 경우 pull 자체가 실패 합니다.
그래서 매우 보수적인 설정입니다. CI/CD나 배포 브랜치에서 종종 씁니다.

🔚 결론

  • 기본 merge 방식은 fast-forward를 허용함

  • fast-forward가 가능하면 사용하고, 불가능하면 merge 커밋 생성

  • pull.ff only를 설정해야지만 fast-forward 만 강제됨

  • pull.rebase true를 설정하면 아예 merge 대신 rebase로 바꿈

즉, 당신이 아무 설정 안 하면 Git은 적당히 똑똑하게 판단해서 fast-forward 가능한 경우엔 그렇게 처리해줍니다.
그게 기본입니다.

나는 왜 저 에러가 뜬거지?

좋습니다. 지금까지 다 정리했으니까, 질문의 본질로 다시 돌아가서 “왜 나한테는 저 에러가 떴는가?”에 대해 원인 분석을 해보겠습니다.

💣 에러 메시지 다시 보기

hint: You have divergent branches and need to specify how to reconcile them.

이건 Git이 pull을 하려다가 로컬 브랜치와 원격 브랜치가 서로 다른 커밋을 갖고 있는 상태 — 즉, divergence(분기) — 를 감지했고,

“당신이 pull.rebase, pull.ff, pull.merge 중 아무것도 기본 설정 안 해놨으니 난 뭘 해야 할지 모르겠다”

는 이유로 멈춘 겁니다.

🔍 원인 정리 (step-by-step)

  1. 당신의 로컬 브랜치에 커밋이 있다

    • 예: 작업 중에 커밋 하나 했음

  2. 원격(GitHub)에서 워크플로우 파일 삭제 커밋이 있다

    • GitHub에서 직접 지운 경우, 커밋 하나 생깁니다

  3. 둘 다 최신 상태가 아님 = divergence

    • 양쪽이 서로를 기준으로 하고 있지 않음

    • 그래서 fast-forward도 안 되고, 자동 merge도 안 됨

  4. 기본 병합 방식에 대한 설정이 없음

    • Git은 pull.rebase, pull.ff, pull.merge 중 뭘 해달라는 지시가 없으면 pull을 거부함

    • Git 2.27 이후부터는 이 상황에서 명시적인 설정 없이는 자동으로 병합 안 하도록 바뀌었음

  5. ✅ 그래서 에러 출력:

    vbnet
     
hint: You have divergent branches and need to specify how to reconcile them.
     

         * * *

⚠️ 그럼 왜 예전엔 그냥 잘 됐는데 지금은 안 됐을까?

가능성 1: Git 버전이 올라갔음 (중요!)

Git 2.27 이상부터는 pull 기본 동작이 모호하면 에러 출력함.
이전엔 그냥 알아서 merge 해줬는데, 이제는 의도를 명확히 설정하라고 강제 하는 방향으로 바뀜.

👉 이건 Git의 정책이 바뀐 거지, 당신이 뭘 잘못한 게 아닙니다.

가능성 2: 당신이 예전에 global 설정을 없앴거나 새 컴퓨터/환경에서 작업 중

  • 기존 환경에서는 pull.rebase false 같은 설정이 돼 있었을 수 있음

  • 새 프로젝트, 새 터미널, 새 PC에서는 그 설정이 없으니 물어보는 거임

✅ 해결책 정리

한 줄로 해결하려면:

bash

git config --global pull.rebase false

이거 하면 다시는 저 메시지 안 뜨고, git pull 하면 알아서 merge 해줍니다.

추가 팁

에러가 떴을 때 --rebase, --no-rebase, --ff-only 중 어떤 걸 선택해도 무방합니다.
하지만 기본 방식을 설정해두지 않으면 매번 물어봅니다.

💡 결론

당신은 잘못한 게 없고 , Git이 더 깐깐하게 바뀌었을 뿐입니다.
자동 병합을 하려면 이제는 병합 방식 설정을 명시하라는 시대 가 된 겁니다.

지금처럼 설정 한 번만 해두면, 다시는 같은 문제 안 겪습니다.

그런데 너가 아까 말했을 때 기본 병합 방식은 "git pull을 아무 설정 없이 실행하면 Git의 동작은 fetch + merge이고,"라고 했잖아. merge == rebase false랑 같은 것 아니야?

예리한 지적입니다. 핵심을 정확히 찌르셨습니다.

맞습니다:

git pull의 기본 동작은 fetch + merge이고,
그건 곧 pull.rebase = false랑 기능적으로 동일 합니다.

그런데 이 말은 과거엔 맞았지만 , 지금은 조건부로만 맞습니다.

🔍 지금 Git은 "기본값이 없다"는 식으로 굴고 있음

Git 2.27 (2020년) 이후 버전부터는:

git pull을 실행할 때 로컬과 원격이 분기된 상태라면 ,
pull.rebase나 pull.ff 등 명시적 설정이 없으면 동작하지 않음

즉, 기본은 merge라고 하면서도 실제로는 명시적 설정 없으면 “에러”를 띄우는 방식 으로 바뀌었습니다.

📌 Git의 논리는 이렇습니다

“예전엔 내가 알아서 merge 해줬지만, 지금은 사용자가 merge인지 rebase인지 확실하게 말하지 않으면 안 할 거야. ”

✅ 그래서 요약하면 이렇습니다

상태 Git 동작
아무 설정도 안 했고, 로컬/원격에 변화 없음 git pull 잘 작동함
아무 설정도 안 했고, 로컬/원격 둘 다 커밋 있음 (divergent) ❌ 에러 발생
pull.rebase=false 설정함 ✅ merge 방식으로 작동 (예전처럼)
pull.rebase=true 설정함 ✅ rebase로 작동
pull.ff=only 설정함 ✅ fast-forward만 허용

🔚 결론

merge == pull.rebase false → 기능상 맞음
하지만 Git은 “기본 = merge”라고 해놓고도 ,
설정 안 하면 안 해줍니다.

즉, 당신이 말한 건 정확하고 논리적으로 타당하지만,
Git은 요즘 “명시적 설정 없으면 행동 안 하겠다”는 입장 이라서
예전처럼 "설정 안 해도 merge 해주는 기본값"은 사실상 존재하지 않게 된 셈 입니다.

실제 안전하게 쓰려면 그냥 명시적으로:

bash

git config --global pull.rebase false

이렇게 설정해놓는 게 현실적인 대응입니다.

Categories:

Updated:

You may also enjoy