스택큐힙리스트

Git에서 가장 최근 로컬 커밋을 실행 취소하려면 어떻게 하나요? 본문

카테고리 없음

Git에서 가장 최근 로컬 커밋을 실행 취소하려면 어떻게 하나요?

스택큐힙리스트 2023. 2. 27. 23:01
반응형

실수로 잘못된 파일을 Git에 커밋했지만 아직 서버에 커밋을 푸시하지 않았습니다.

로컬 리포지토리에서 이러한 커밋을 취소하려면 어떻게 해야 하나요?

 

깃에 필요한 게 뭔지 아세요? 깃 실행 취소, 그게 다예요. 그러면 인간이 저지른 실수를 처리한다는 깃의 평판이 사라집니다. git 명령을 실행하기 전에 현재 상태를 git 스택에 푸시하여 구현하세요. 성능에 영향을 줄 수 있으므로 활성화 여부에 대한 구성 플래그를 추가하는 것이 가장 좋습니다. - 

 

Git의 별칭 기능을 사용하여 수행 할 수 있습니다 : git-scm.com/book/ko/v2/Git-Basics-Git-Aliases -. 

VsCode 사용자의 경우 ctrl + Shift + G를 입력 한 다음 세 개의 점, 즉 추가 옵션을 클릭 한 다음 마지막 커밋 실행 취소를 클릭하십시오. 

정확히 무엇을 실행 취소합니까? "실행 취소"가 완전히 다른 것을 의미하는 매우 다른 기능적 경우가 수십 가지 있습니다. 새롭고 멋진 "마술 지팡이"를 추가하면 더 혼란스러워 질 것입니다. - 

안 믿어요. 사람들은 여전히 되돌리지 말아야 할 일을 더듬거리며 되돌릴 것입니다. 하지만 더 중요한 것은, 깃 리플로그는 이미 설명하신 것과 비슷하지만 사용자가 무엇을 (취소)해야 하는지에 대한 더 많은 제어권을 준다는 점입니다. 하지만 '실행 취소'는 모든 곳에서 동일하게 작동하지 않으며, 사람들은 이 기능으로 달성할 수 있는 다양한 것을 기대할 것입니다. 마지막 커밋을 실행 취소하시나요? 마지막 작업을 실행 취소한다고요? 마지막 작업이 푸시였다면 정확히 어떻게 되돌리나요, (리셋 후 푸시) 또는 (되돌리고 푸시)? - 

 

 

커밋을 실행 취소하고 다시 실행
$ git commit -m "뭔가 끔찍하게 잘못된 것" # (0: 당신의 사고)
git reset HEAD~ # (1)
[필요에 따라 파일 편집 ] # (2)
$ git add .                                    # (3)
$ git commit -c ORIG_HEAD # (4)
git reset은 실행 취소를 담당하는 명령이다. 이 명령은 작업 트리(디스크에 있는 파일 상태)는 그대로 유지하면서 마지막 커밋을 실행 취소한다. 다시 커밋하려면 다시 추가해야 한다).
작업 트리 파일을 수정한다.
새 커밋에 포함할 내용을 git에 추가한다.
이전 커밋 메시지를 재사용하면서 변경 사항을 커밋한다. 재설정 이전 헤드를 .git/ORIG_HEAD에 복사하고 -c ORIG_HEAD로 커밋하면 이전 커밋의 로그 메시지가 포함된 편집기가 열리고 이를 편집할 수 있다. 메시지를 편집할 필요가 없다면 -C 옵션을 사용할 수 있다.
또는 이전 커밋(또는 해당 커밋 메시지만)을 편집하려면 커밋 --amend를 사용하면 현재 인덱스 내의 변경 내용을 이전 커밋에 추가합니다.

서버로 푸시된 커밋을 제거하려면(되돌리지 않으려면) git push origin main --force[-with-lease]로 히스토리를 다시 작성해야 한다. 거의 항상 --force를 사용하는 것은 좋지 않은 생각이며, 대신 --force-with-lease를 사용하는 것이 좋으며, git 매뉴얼에 명시된 대로 사용한다:

이미 [히스토리 재작성]이 게시된 경우 히스토리 재작성의 의미를 이해해야 한다.

추가 읽기
git reflog를 사용하여 되돌리려는 커밋의 SHA-1을 확인할 수 있다. 이 값을 찾으면 위에서 설명한 명령어 순서를 사용한다.

HEAD~는 HEAD~1과 동일하며, 여러 커밋을 커밋 취소하려는 경우 git에서 HEAD란 무엇인가요? 문서가 도움이 될 수 있습니다.

 

 

 

커밋을 실행 취소하는 것은 어떻게 작동하는지 모른다면 조금 무섭습니다. 하지만 실제로 이해하면 놀라울 정도로 쉽습니다. 커밋을 실행 취소하는 4가지 방법을 보여드리겠습니다.

C는 HEAD이고 (F)는 파일 상태라고 가정해 보겠습니다.

   (F)
A-B-C
    ↑
  마스터
옵션 1: git reset --hard
커밋 C를 삭제하고 커밋되지 않은 변경 사항도 모두 버리려고 한다. 이렇게 한다:

git reset --hard HEAD~1
결과는 다음과 같다:

 (F)
A-B
  ↑
master
이제 B가 HEAD가 되었다. hard를 사용했기 때문에 파일은 커밋 B의 상태로 초기화된다.

옵션 2: git 리셋
커밋 C가 재앙은 아니었지만 약간 잘못되었을 수도 있습니다. 커밋을 되돌리고 싶지만 더 나은 커밋을 하기 전에 약간의 편집을 위해 변경 내용을 유지하려고 한다. 여기서부터 다시 시작하여 C를 HEAD로 사용한다:

   (F)
A-B-C
    ↑
  마스터
하드에서 --hard를 빼고 이렇게 한다:

git reset HEAD~1
이 경우 결과는 다음과 같다:

   (F)
A-B-C
  ↑
마스터
두 경우 모두 HEAD는 최신 커밋에 대한 포인터일 뿐이다. HEAD~1을 재설정하면 Git에게 HEAD 포인터를 한 커밋 뒤로 이동하라고 지시한다. 하지만 (--hard를 사용하지 않는 한) 파일은 그대로 유지된다. 이제 git 상태에 C에 체크 아웃한 변경 사항이 표시됩니다. 아무것도 잃지 않았어요!

옵션 3: git 리셋 --soft
가장 가볍게 커밋을 실행 취소하되 파일과 인덱스는 그대로 둘 수도 있다:

git reset --soft HEAD~1
이렇게 하면 파일뿐만 아니라 인덱스도 그대로 유지된다. git status를 실행하면 이전과 동일한 파일이 인덱스에 있는 것을 볼 수 있습니다. 실제로 이 명령을 실행한 직후에 git 커밋을 실행하면 방금 실행한 것과 동일한 커밋을 다시 실행하게 됩니다.

옵션 4: git 리셋 --hard를 수행했는데 해당 코드를 다시 가져와야 하는 경우
한 가지 더: 첫 번째 예제에서와 같이 커밋을 지웠는데 나중에 커밋이 필요하다는 것을 알게 되었다고 가정해보자. 운이 나쁘죠?

아니요, 다시 되돌릴 수 있는 방법이 아직 있습니다. 다음과 같이 입력한다.

git reflog
를 입력하면 이동한 (부분) 커밋 샤(즉, 해시) 목록이 표시됩니다. 파괴한 커밋을 찾아서 다음과 같이 하세요:

git checkout -b someNewBranchName shaYouDestroyed
이제 해당 커밋이 부활했다. 커밋은 실제로 약 90일 동안 Git에서 파기되지 않으므로, 의도하지 않은 커밋을 다시 돌아가서 복구할 수 있습니다.

반응형
Comments