Reset vs Revert
저는 개인 프로젝트를 진행할 때 커밋 로그를 더 깔끔하게 남기기 위해서 git reset --SOFT {Head~N}, git push {branch} --force를 많이 사용합니다.
예를 들어, 원격 마스터 브랜치에 잘못된 내용 또는 완벽하지 않은 단위의 커밋을 했다고 가정합시다. 이를 고치는 커밋을 연달아서 남기면 좋은 이력이 남지 못합니다.
그래서 Reset & Push 를 해서 완벽한 단위의 커밋으로 수정하고자 하는 것이죠.
왜 현업에서는 이를 사용해서는 안되는지 말씀드려보겠습니다.
git push origin master --force
사실 git reset은 절대 나쁜 것이 아닙니다. reset은 로컬에 있는 변경점을 수정하는 것 뿐이기 때문입니다.
문제는 강제 푸시(git push {branch} --force) 입니다.
예를 들어서, 제가 A 커밋과 B 커밋을 작성했습니다.
그런데, B가 좋지 않은 커밋이라는 것을 깨닫고는 git reset --soft HEAD~1을 사용해서 B 커밋을 없애고 B 내용에서 조금 수정한 새로운 커밋 C를 생성했습니다.
로컬에는 원격에 대한 변경점이 A와 C가 있습니다.
이제 강제푸시를 해야하는데, 만약 그 전에 다른 분의 작업 내용 커밋 D가 원격 브랜치에 push됐다고 가정합시다.
이 때 저는 그런 사실을 모르고, 강제 push를 사용하면 원격 브랜치가 제 로컬 브랜치로 완전히 탈바꿈되면서 커밋D가 날라갑니다.
즉, 강제 푸시를 사용하게 되면 로컬에 없는 원격 브랜치의 변경점들이 모조리 날아갑니다.
--force-with-lease
체크를 꼼꼼하게 한다고 해도, 강제 푸시 직전에 생긴 target 브랜치에 변경점까지 사람이 체크할 수는 없습니다.
이러한 문제를 조금이나마 방지하기 위해서는 --force-with-lease 옵션을 사용하면 됩니다.
이는 Git이 push 하려는 마지막 커밋이 현재 원격 브랜치의 상황과 동일할 때만 push를 실행합니다. 이를 사용하면 로컬에서 완전히 확인이 되었다는 가정 하에 안전하게 강제 푸시를 실행할 수 있습니다.
하지만, 사람인 이상 누구나 실수를 할 수 있으니, 정말 중요한 상황에서만 사용하시길 권장드립니다.
마무리
정리하자면, 다른 사람도 사용하는 원격 브랜치에 강제 푸시(git push ~ --force)를 사용하는 것은 위험합니다.
대신에 revert를 사용하거나, 추가적인 커밋으로 소스를 보완하는 것이 바람직합니다.
혼자 사용하는 로컬 브랜치 또는 원격 브랜치라면 브랜치를 헷갈리지 않게 조심해서 reset을 사용해도 됩니다.
감사합니다.
참고