고정 헤더 영역
상세 컨텐츠
본문
상황 설명
JSP 게시판 프로젝트의 전체 소스코드를 다시 읽어보며 소스코드에 대한 설명을 추가하는 작업을 진행하였다. 그러고 나서 서버에 재배포를 하고 테스트까지 마친 뒤 GitHub에 프로젝트를 업로드했다. 그런데 나중에 확인해 보니 DB와 관련된 민감한 정보를 수정하지 않고 올려둬 버린 게 확인되어서 GitHub에 올라간 커밋을 취소해야 하는 상황이다.
위와 같이 6453b5e가 가장 최근 커밋이고 이미 이 커밋은 깃허브에 기록된 상태이다.
이 상황에서 6453b5e라는 최근 커밋을 삭제하고 그 직전 커밋인 2c6a14e이 최근 커밋인 상태로 되돌리려고 한다.
git reset --soft로 커밋 취소하고 작업 디렉터리와 스테이지 상태는 유지하기
git reset --soft <되돌아갈 커밋 해시>
우선 가장 최근 커밋에 DB와 관련된 민감한 정보가 있기 때문에 되돌아갈 커밋 '이후에 존재하는 모든 커밋을 삭제'하는 reset명령을 사용했다. 이때 이전 작업 디렉터리와 스테이지의 상태를 유지하기 위해서 --soft옵션을 사용했다.
reset 명령어가 수행된 후 log명령으로 확인해 보면 되돌아가려던 2c6a14e가 최근 커밋으로 지정되어 있고 작업 디렉터리와 스테이지는 최근에 작업한 상태로 유지되어 있는 것을 확인할 수 있다. 이후 commit 명령으로 다시 커밋을 새로 생성하면 된다.
git push -f origin main으로 GitHub 저장소에 강제로 덮어씌우기
커밋을 새로 만든 다음 GitHub에 업로드하려고 했더니 다음과 같은 에러 메시지가 떴다..
https://jupiny.com/2019/03/19/revert-commits-in-remote-repository/
원격 저장소에 올라간 커밋 되돌리기
Git으로 버젼 관리를 하며 개발하다보면, 작성한 커밋들을 되돌려서 다시 이전 상태로 원상복구하고 싶은 경우가 한번쯤 있을 것이다. 만약 로컬까지만 저장된 커밋인 경우는 $ git reset 명령어를
jupiny.com
찾아보니 이 에러는 로컬 저장소의 커밋 히스토리가 원격 저장소의 커밋 히스토리보다 뒤처져있을 때 발생하는 에러라고 한다. 해결 방법으로는 push 명령 사용 시 -f 옵션을 사용하는 방법이 있다. 이 옵션을 사용하면 로컬 저장소의 커밋 히스토리를 원격 저장소의 커밋 히스토리에 강제로 덮어씌우게 된다. 그러나 이 옵션은 팀 프로젝트에서 pull 명령을 사용한 다른 팀원들의 커밋 히스토리에 삭제되지 않은 커밋이 공유되어 프로젝트가 꼬일 수 있으므로 주의해서 사용해야 한다.
명령어가 수행되면 GitHub에 정상적으로 업로드(강제 덮어쓰기)가 된 것을 볼 수 있다.
마치며
GitHub를 통해 프로젝트를 관리하다 보면 종종 이렇게 민감한 정보까지 업로드해 버리는 실수를 한다. 그럴 때마다 revert와 reset 명령어의 차이가 명확하게 이해되지 않다보니 어떤걸 써야하는지 헷갈릴때가 많았다. 하지만 이번 기회를 통해 두 명령어의 차이에 대한 기준을 명확히 이해할 수 있게 되었다.
[참고]
https://iseunghan.tistory.com/324 : Git Head, reset 옵션 3가지(hard, mixed , soft)
