`git push — force` 이야기
Published in
3 min readFeb 6, 2014
안녕하세요. 스타일쉐어 개발팀의 김현준입니다. 훌륭한 엔지니어링 경험을 공유하고 싶어 만든 블로그이지만, 아직까지는 그런 일이 없었던지라, 창피한 장애 경험을 공유하고자 합니다.
배경
- 웹 서비스 디플로이는 프로덕션 웹 서버에서 업스트림
master
를 풀 받아 리로드하는 방식으로 진행하고 있습니다. - CSS, JS 등의 파일들은 CDN을 위해 매 빌드마다 디플로이 이전에 S3에 업로드합니다. Git 커밋의 SHA1 해시를 키로 사용합니다.
장애
- 어제 새벽 서비스에 긴급한 패치가 있었습니다. 하지만 이 커밋은 8분 후 다시 롤백되는데…
- 오늘 오후 디플로이 이후에 갑자기 웹 사이트의 스타일이 전부 깨져보이기 시작했습니다.
- 심지어 아무리 커밋 로그를 살펴봐도 존재하지도 않는 커밋 해시로 파일을 요청하고 있었습니다.
원인
- 롤백을
git revert
명령으로 하는 대신에, 이전 커밋으로HEAD
를 돌리고git push --force
로 업스트림을 덮어썼습니다. - 해당 커밋은 이미 디플로이가 되어있었지만, 되돌린 이후에 다시 디플로이를 하지 않았습니다.
- 다음 디플로이할 때 해당 웹 서버 로컬에서 업스트림
master
를 풀 받자, (개발자의 로컬이나, GitHub에서 보이는 커밋 트리와 달랐기 때문에) 서로 다른 커밋 해시를 가지게 되었습니다. - 404
교훈
force-push
를 (창피한 실수라던지, 지저분한 여러개의 커밋이라던지) 이력을 남기고 싶지 않을 때 사용하는 경우가 있는데요. 이는 위의 사례처럼 해당 커밋을 이미 풀 받은 다른 개발자의 로컬을 꼬이게 하거나, 장애를 유발할 수가 있습니다. 롤백을 하고 싶은 경우엔 revert
명령을, 커밋을 정리하고 싶은 경우엔 각자의 브랜치에서 충분히 rebase
를 한 뒤에 올리는 습관을 꼭 가져야겠습니다.
Originally published at styleshare.github.io on February 6, 2014.