커밋 되돌리기

사건 발단

ide와 깃허브 사이트로 하는 커밋은 처음이다보니(평소에는 습관적으로 bash명령어 이용) 실수로 풀 리퀘스트를 날리는 과정에서 merge를 하는 실수를 범해버렸다.
엎친데 덮친 격으로 merge를 취소한답시고 체리픽을 잘못된 생성을 하는 바람에 main브런치에는 잘못된 내용이 그대로 들어가고 새 브런치 하나에는 원래 main내용 새브런치2에는 내가 pull request를 남기고 싶은 내용이 들어가있는 상황이었다.

1번째 수습

처음에는 내가 앞서 말했다시피 체리픽을 시도했다.
체리픽을 하는 방법은 bash 기준으로 git.log를 사용해 내가 원하는 커밋의 번호를 알아낸뒤(이때에 커밋 메시지가 함께 나오니 메시지를 제대로 작성해두는 습관을 가지는 게 좋다) 내가 origin과 연결한 브런치에 $ git cherry-pick 커밋 넘버를 입력하면 된다.
나는 내가 위 과정에서 실수로 main과 연결하지 않고 새로운 브런치를 만드는 바람에 상황이 복잡해졌다.

수습 방법 소개

만약 나처럼 헉 싶은 상황이 이미 전개되었다면, 제일 먼저 확인해야하는 것은 커밋 넘버이다.
이후 커밋 넘버를 통해 브런치에 상황들을 입력하고 혹시나 나처럼 잘못 만든 브런치가 있다면, 내용을 제발 확인하고 과감하게 삭제하면 된다.

git branch -f main 커밋 넘버
git push origin본인이 등록한 원격 이름 main 실제 브런치 --force

나는 충돌이 일어나도 push가 강제로 될 수 있도록(이미 내용 확인을 철저하게 했기 때문)--force를 사용하였지만, 직장에서는 이렇게 해도 될지 잘은 모르겠다.

수습 중 일어날 수 있는 오류

간단한 conflict오류의 경우 gpt가 시키는 대로 하면 수습이 된다.
만약 vscode에서 터미널을 통해 push하는데 자꾸 commit을 거부당한다면 사용자 인증이 필요한 걸 수도 있으니 나처럼 토큰 방식으로 로그인을 하거나 output오류에서 시키는 대로 깃허브 네임과 본인의 이메일 주소를 입력하는 방식으로 인증을 거치면 된다.

좋은 방법

원래 좋은 방법은 add를 사용해서 수습을 하는 것이다
pull과 add를 적절하게 사용하여 수습을 하는 것이 좋지 나처럼 –force를 사용했을 경우 문제가 생기면 무조건 덮어써지기 때문에 최악의 경우 다른 팀원이 작성한 귀한 코드가 날아갈 수도 있다.
물론 나의 경우 코드를 정말 꼼꼼히 보고 신중히 진행했지만, 사람이니까 실수를 할 수도 있으니 웬만해서는 –force는 최후의 수단으로 여겨두자.