git push -f (git push --force)
로컬 브랜치의 변경 사항을 강제로 원격 저장소에 덮어쓰는 명령어이다.
보통은 로컬 브랜치의 커밋 히스토리를 변경(예: rebase, amend) 한 후에 사용된다.
⚠️ 왜 "강제(push -f)"가 필요한가?
Git은 기본적으로 push 할 때, 원격 브랜치가 로컬 브랜치의 조상이 아닐 경우 push를 거부한다.
(= 히스토리가 "앞으로"만 가야지, "되돌리면" 위험하다고 보기 때문이다.)
하지만 git commit --amend, git rebase, git reset 같은 작업은 커밋 해시를 변경하므로 push 하려면 -f 옵션이 필요하다.
📘 예시: amend 후 push -f
1. 이미 커밋을 push
git commit -m "Fix bug" git push origin feature-branch |
2. 나중에 메시지를 수정
git commit --amend -m "Fix login bug" |
이제 로컬 커밋과 원격 커밋 해시가 달라졌다.
이 상태에서 일반 push를 하면 오류가 발생한다.
git push origin feature-branch 🚫 오류 메시지: ! [rejected] feature-branch -> feature-branch (non-fast-forward) error: failed to push some refs |
✅ 해결: 강제 푸시
git push -f origin feature-branch |
이제 원격 저장소의 이전 커밋은 완전히 덮어쓰기 되고, 수정된 커밋이 올라간다.
⚠️ 주의 사항
항목 | 설명 |
협업 중이라면? | 다른 사람이 기반하고 있던 커밋이 날아가 혼란 초래 가능 |
안전하게 하려면? | git push --force-with-lease 사용 추천 (충돌 방지 기능 있음) |
언제 사용? | 개인 브랜치 정리, 리뷰 전 커밋 다듬기 등 push 전에 정리하는 경우 |
✅ 요약
명령어 | 사용 상황 |
git push | 일반적인 push (히스토리 변경 없음) |
git push -f | 히스토리를 수정했을 때 강제 push |
git push --force-with-lease | 강제 push + 누군가의 push 여부 확인 (조심성 있는 방식) |
'Git & Github > [인강] Git & Github 실무 활용 완벽 가이드' 카테고리의 다른 글
[Git & Github] 18. Git의 이면 - 해싱(Hashing)과 객체 (0) | 2025.05.02 |
---|---|
[Git & Github] 17. 히스토리상의 중요한 순간에 표시하기 (0) | 2025.05.02 |
[Git & Github] 16-1. git commit --amend (0) | 2025.04.30 |
[Git & Github] 16. Interactive Rebase를 사용하여 히스토리 삭제하기 (0) | 2025.04.30 |
[Git & Github] 15. 리베이스(Rebase)는 가장 까다로운 명령어일까? (0) | 2025.04.30 |