일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 머신러닝
- 딥러닝
- 네트워크보안
- 자료구조
- 데이터분석
- 빅데이터
- 2
- 코딩
- 프로그래밍
- 자바스크립트
- 웹개발
- 파이썬
- 프로그래밍언어
- 데이터과학
- 데이터구조
- 컴퓨터과학
- 보안
- 컴퓨터공학
- 버전관리
- 네트워크
- 데이터베이스
- 사이버보안
- 소프트웨어공학
- 컴퓨터비전
- 알고리즘
- 클라우드컴퓨팅
- Yes
- I'm Sorry
- 소프트웨어
- 인공지능
- Today
- Total
스택큐힙리스트
Git에서 가장 최근 로컬 커밋을 실행 취소하려면 어떻게 하나요? 본문
실수로 잘못된 파일을 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에서 파기되지 않으므로, 의도하지 않은 커밋을 다시 돌아가서 복구할 수 있습니다.