기록

[Git] Git push (fetch first) 오류 발생: 브랜치 분기 상태에서의 동기화 전략 본문

제대로 이해하기

[Git] Git push (fetch first) 오류 발생: 브랜치 분기 상태에서의 동기화 전략

zyin 2025. 5. 26. 12:00

시작하면서

로컬에서 git push 명령을 실행했을 때 아래와 같은 오류 메시지를 마주한 경험이 있다.

! [rejected]        develop -> develop (fetch first)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do not have locally.

 

이 메시지는 단순히 "원격에 변경 사항이 있으니 먼저 가져오라"는 뜻이 아니다. 내부적으로는 로컬 브랜치와 원격 브랜치의 히스토리가 서로 다른 방향으로 분기되었기 때문에, fast-forward push가 거부된 상태를 의미한다.


1. 내부 동작 관점에서 원인 분석

Git은 push 명령 시 다음 조건을 만족해야 정상적으로 동작한다.

  • 로컬 브랜치의 HEAD가 원격 브랜치의 조상(ancestor)이거나,
  • 원격 브랜치가 로컬 브랜치의 조상이고 fast-forward가 가능해야 함.

하지만 원격 저장소에서 이미 다른 사용자가 변경사항을 push한 상태라면, 로컬은 이를 반영하지 못한 상태로 push를 시도하게 된다. 이 경우 Git은 브랜치 간 히스토리 충돌을 피하기 위해 push를 거부하며, “fetch first” 즉, 먼저 원격 변경사항을 통합(pull)하라는 메시지를 출력한다.


2. 해결을 위한 병합 전략 결정

이후 git pull을 수행하면 다음과 같은 메시지가 다시 등장할 수 있다.

fatal: Need to specify how to reconcile divergent branches.

 

이는 브랜치가 분기(divergent)된 상태로 판단되었으나, 병합 방식이 설정되지 않았기 때문이다.
즉, Git은 두 브랜치의 히스토리를 어떻게 통합할지에 대한 전략을 명시적으로 요구한다.

병합 방식 1: Merge

git pull --no-rebase
  • 원격 커밋과 로컬 커밋을 병합(Merge)하여 새로운 커밋을 생성한다.
  • 커밋 로그에는 병합 흔적이 남는다.
  • 팀에서 merge 커밋 허용 정책을 사용 중이라면 적합하다.

병합 방식 2: Rebase

git pull --rebase
  • 로컬 커밋을 원격 커밋 뒤에 재적용하는 방식이다.
  • 브랜치 히스토리가 선형(linear)하게 유지되어 로그가 간결해진다.
  • 충돌 발생 시 수동으로 해결 후 git rebase --continue 명령으로 재개한다.

3. 실전 적용 예시

내 경우에는 커밋 히스토리를 보다 깔끔하게 유지하기 위해 rebase 방식을 사용했다.
구체적인 명령 흐름은 다음과 같다.

# 원격 변경사항을 가져오되, rebase 방식으로 적용
git pull --rebase origin develop

 

이 명령 실행 중 충돌이 발생할 경우:

# 충돌 파일 수정 후
git add .

# rebase 재개
git rebase --continue

 

모든 과정이 정상 완료되면 다음 명령으로 푸시를 재시도한다.

git push origin develop

4. 반복 방지를 위한 설정

Git에서 병합 전략을 매번 지정하지 않기 위해 전역 설정을 적용할 수 있다.

전역 설정 예시:

git config --global pull.rebase true  # 항상 rebase 방식 사용
# 또는
git config --global pull.rebase false  # merge 방식 사용

이 설정은 git pull 명령 시 기본 동작을 자동화해준다.
CI/CD 파이프라인에서도 일관된 병합 전략을 유지하는 데 유용하다.


5. 결론

Git에서 push (fetch first) 오류는 단순한 충돌 상황이라기보다는 브랜치 히스토리의 분기 상태에 대한 Git의 엄격한 무결성 제어로 이해해야 한다. 이러한 상황에서는 병합 전략을 명확히 인지하고, 팀의 정책이나 프로젝트 특성에 따라 merge 또는 rebase를 선택해 일관된 브랜치 관리 체계를 유지하는 것이 중요하다.

Comments