팀원에게 슬랙으로 질문을 받았고 나도 잘 모르는 상황이라 그냥 Merge하시라고 답변드렸지만 이후에 커밋 로그에 Conflict Commit이 여러 개 생겨나는 부분이 Commint log가 지저분해 진다고 생각해 한번 상황을 재현하면서 해결 방법을 찾아봤습니다.
Git을 사용하면서 rebase
를 한 후 push
가 reject되는 문제에 부딪힐 때가 있습니다. 이 문제는 주로 원격 저장소와 로컬 저장소의 브랜치 히스토리가 일치하지 않을 때 발생합니다. 이 포스트에서는 이 문제를 해결하는 세 가지 방법을 소개합니다.
문제 상황
main
브랜치에서feat
브랜치를checkout
하여 작업을 진행합니다.- 작업 중
main
브랜치에 추가 커밋이 발생합니다. feat
브랜치에서git rebase main
을 실행하여 최신 커밋을 반영합니다.- 이후
git push
를 시도하면, push가 reject됩니다.
해결 방법 1: 강제 푸시 (주의 필요)
주의: 이 방법은 위험합니다. 원격 브랜치의 커밋을 덮어쓸 위험이 있으므로 다른 사람과 공유하는 브랜치에는 사용하지 마세요.
git push origin feat-branch --force
또는 좀 더 안전한 방법으로
git push origin feat-branch --force-with-lease
--force-with-lease
옵션은 원격 브랜치가 예상한 커밋에 위치해 있을 경우에만 강제 푸시를 실행하므로 상대적으로 안전합니다.
해결 방법 2: 새로운 브랜치를 만들어 푸시
- 현재
feat
브랜치에서 새로운 브랜치를 생성합니다. git checkout -b feat-branch-new
- 새로운 브랜치를 원격 저장소에 푸시합니다.
git push origin feat-branch-new
이 방법은 원격 저장소의 히스토리를 변경하지 않고 새로운 브랜치로 안전하게 작업을 반영할 수 있습니다.
해결 방법 3: 원격 브랜치를 로컬로 다시 땡겨온 후 병합
- 원격의
feat
브랜치를 로컬로 땡깁니다. git fetch origin feat-branch
- 로컬의
feat-branch
와 원격의feat-branch
를 병합합니다. git merge origin/feat-branch
- 병합이 잘 되었다면, 원격 브랜치에 다시 푸시합니다.
git push origin feat-branch
이 방법은 원격 저장소에 있는 다른 작업과 병합하여 안전하게 브랜치를 업데이트합니다.
정리
Git rebase
후에 push
가 reject되는 문제는 까다로울 수 있지만, 적절한 방법을 사용하면 쉽게 해결할 수 있습니다. 선택할 방법은 상황과 작업 중인 브랜치의 상태에 따라 다르므로 주의가 필요합니다.
저희팀에서는 첫번째 방법을 채택했으며 이유는 force push는 주의점이 있지만 feat브랜치는 다른 개발자와 공유하지 않는 상황이라 force push로 커밋로그를 깔끔하게 유지하는 것을 사용하기로 했습니다.