12강. non-fast-forward push 오류 해결

?1. 이번 강의에서 해결할 문제

다른 위치나 GitHub 웹에서 원격 main이 먼저 변경되면 내 push가 원격 이력을 덮을 수 있어 거절됩니다. 강제 push 대신 원격 차이를 가져와 통합합니다.

✓2. 학습 목표

✓이 강의를 마치면

• non-fast-forward 거절 원인을 그래프로 확인합니다.
• fetch 후 원격 커밋을 검토합니다.
• rebase 또는 merge 정책을 선택해 안전하게 push합니다.

◇3. 핵심 개념

원격 브랜치 끝이 내 로컬 브랜치의 조상이 아니면 단순 포인터 전진이 아닙니다. GitHub는 기본적으로 이런 push를 거절해 원격 커밋 손실을 막습니다. 먼저 fetch하고 팀의 통합 정책에 따라 rebase 또는 merge합니다.

§4. 단계별 명령어와 예시

실습 경로: C:\dev\git-learning-site

PowerShell

Set-Location C:\dev\git-learning-site
git fetch origin
git log --graph --oneline --decorate --all -n 15
git log --oneline HEAD..origin/main
git diff HEAD..origin/main
git rebase origin/main
git push origin main

rebase 중 충돌을 해결한 뒤에는 git add <파일>과 git rebase --continue를 사용합니다. 중단하려면 git rebase --abort를 실행합니다.

→5. 명령어가 동작하는 이유

fetch는 원격 참조를 갱신하되 작업 파일을 건드리지 않습니다. rebase는 내 로컬 커밋을 원격 최신 커밋 뒤에서 다시 적용해 직선 이력을 만듭니다. 아직 공유하지 않은 로컬 커밋에 사용하는 것이 안전합니다.

!6. 자주 하는 실수와 안전한 해결법

!자주 하는 실수

• 즉시 git push --force: 다른 사람의 원격 커밋을 잃을 수 있습니다. 먼저 fetch와 log로 원인을 확인합니다.
• 공유 브랜치를 무심코 rebase: 커밋 ID가 바뀝니다. 팀 정책이 merge라면 git merge origin/main을 사용합니다.
• 정말 강제 갱신이 필요한 경우: 보호 브랜치가 아닌 개인 브랜치인지 확인하고, 원격이 예상대로일 때만 --force-with-lease를 고려합니다. 일반 --force보다 안전하지만 여전히 이력을 바꿉니다.

✎7. 직접 실습

✎직접 실습

1. 복제 폴더 두 곳에서 서로 다른 커밋을 만들어 먼저 한쪽을 push합니다.
2. 다른 쪽 push 거절 후 fetch와 log로 원격 전용 커밋을 찾습니다.
3. rebase해 다시 push하고 두 변경이 모두 남았는지 확인합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. GitHub가 non-fast-forward push를 기본 거절하는 이유는 무엇인가요?
2. 작업 파일을 바꾸지 않고 원격 차이를 확인하는 첫 명령은 무엇인가요?
3. --force-with-lease도 위험한 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

push 거절은 원격 이력을 보호하는 신호입니다. fetch, log, diff로 차이를 이해하고 정책에 맞게 통합한 뒤 일반 push를 다시 시도합니다.