특정 커밋 제거


287

나는 프로젝트에서 친구와 일하고 있었고, 편집해서는 안되는 많은 파일을 편집했습니다. 어쨌든 나는 그의 작품을 뽑을 때 또는 내가 원하는 특정 파일을 선택하려고 할 때 내 작품을 병합했습니다. 나는 오랫동안 파일을 찾고 재생하여 해당 파일에 대한 편집 내용이 포함 된 커밋을 제거하는 방법을 알아 내려고 노력했습니다. 복귀와 rebase 사이의 던지기 인 것처럼 보이며 간단한 예제가 없으며 문서는 내가 아는 것보다 더 많은 것을 알고 있다고 가정합니다.

다음은 질문의 단순화 된 버전입니다.

다음 시나리오에서 커밋 2를 어떻게 제거합니까?

$ mkdir git_revert_test && cd git_revert_test

$ git init
Initialized empty Git repository in /Users/josh/deleteme/git_revert_test/.git/

$ echo "line 1" > myfile

$ git add -A

$ git commit -m "commit 1"
[master (root-commit) 8230fa3] commit 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ echo "line 2" >> myfile

$ git commit -am "commit 2"
[master 342f9bb] commit 2
 1 files changed, 1 insertions(+), 0 deletions(-)

$ echo "line 3" >> myfile

$ git commit -am "commit 3"
[master 1bcb872] commit 3
 1 files changed, 1 insertions(+), 0 deletions(-)

예상 결과는

$ cat myfile
line 1
line 3

다음은 어떻게 되돌리려 고했는지에 대한 예입니다.

$ git revert 342f9bb
Automatic revert failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.

5
동일한 문제를 검색하는 동안 누군가가 이것을 발견하면 다음과 같은 결과가 나타납니다. 복사하여 붙여 넣기. 진심으로. 제안 된 솔루션을 작동시키는 데 6 시간 이상이 걸렸습니다. 결국, 나는 시간이 없어서 원본을 꺼내고 약 20 개의 파일을 복사 / 붙여 넣었습니다. 5 분도 채 걸리지 않았으며 그 이후에도 문제가 해결되지 않았습니다 (이 파일이 이전에 발생한 다른 지점의 변경 사항과 병합 된 경우에도). 나는 당신 도이 접근법을 취할 것을 제안합니다. 가장 간단 할뿐만 아니라 그것이 유일한 방법이라고 생각합니다.
Joshua Cheek

나는 비슷한 문제에 직면했지만 더 복잡 할 수 있습니다. 수백 개의 커밋이있는 지점이 있었으며 스쿼시하고 싶었습니다. 불행히도 다른 지점의 커밋은 중간 지점에서 지점으로 다시 병합되었으므로 스쿼시하기 전에 "병합 해제"가 필요했습니다. 아래 tk에서 제안한 것과 비슷한 경로로 내려갔습니다 (체리 선택 + 범위 표기법 사용). 다른 파일에서 충돌이 발생했습니다. 마지막 복사 및 붙여 넣기 + 몇 가지 수동 편집이 가장 쉽고 예측 가능한 경로였습니다. 당신이 이것에 너무 많은 시간을 소비하는 것을 발견하면 확실히 고려해야 할 가치가 있습니다.
Federico

답변:


73

diff를 되돌릴 때 Git이 사용하는 알고리즘은

  1. 되돌려지는 행은 이후 커밋에 의해 수정되지 않습니다.
  2. 나중에 역사에서 다른 "인접한"커밋은 없습니다.

"adjacent"의 정의는 컨텍스트 diff의 기본 줄 수 (3)를 기반으로합니다. 따라서 'myfile'이 다음과 같이 구성된 경우 :

$ cat >myfile <<EOF
line 1
junk
junk
junk
junk
line 2
junk
junk
junk
junk
line 3
EOF
$ git add myfile
$ git commit -m "initial check-in"
 1 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ perl -p -i -e 's/line 2/this is the second line/;' myfile
$ git commit -am "changed line 2 to second line"
[master d6cbb19] changed line 2
 1 files changed, 1 insertions(+), 1 deletions(-)

$ perl -p -i -e 's/line 3/this is the third line/;' myfile
$ git commit -am "changed line 3 to third line"
[master dd054fe] changed line 3
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git revert d6cbb19
Finished one revert.
[master 2db5c47] Revert "changed line 2"
 1 files changed, 1 insertions(+), 1 deletions(-)

그런 다음 모두 예상대로 작동합니다.

두 번째 답변은 매우 흥미로웠다. Revert Strategy라는 공식적으로 아직 출시되지 않은 기능이 있습니다 (Git v1.7.2-rc2에서 사용 가능하지만). 다음과 같이 git을 호출 할 수 있습니다.

git revert --strategy resolve <커밋>

그리고 당신이 의미하는 것을 알아내는 것이 더 나은 일을해야합니다. 사용 가능한 전략 목록이 무엇인지, 전략의 정의를 모릅니다.


1
perl -psed와 유사하게 입력을 루프 하여 출력으로 전달 하는 매우 짧은 (한 줄) 프로그램을 작성하는 데 유용합니다 . perl -i파일 을 제자리 에 편집하는 데 사용됩니다 . 평가할perl -e 코드를 제출하는 방법 입니다.
Hal Eisen

281

그렇게하는 네 가지 방법이 있습니다.

  • 깨끗한 방법, 되돌리기, 되돌리기를 기록하십시오.

    git revert --strategy resolve <commit>
    
  • 가혹한 방법, 마지막 커밋 만 제거하십시오.

    git reset --soft "HEAD^"
    

참고 : git reset --hard마지막 커밋 이후 파일의 모든 변경 사항도 삭제되므로 사용 하지 마십시오 . 경우 --soft작동하지 않는, 오히려 시도 --mixed--keep.

  • 리베이스 (최근 5 개의 커밋 로그를 표시하고 원하지 않는 행을 삭제하거나 한 번에 여러 커밋을 다시 정렬하거나 스쿼시하거나 원하는 것을 수행하십시오. 이것은 매우 다양한 도구입니다).

    git rebase -i HEAD~5
    

실수 한 경우 :

git rebase --abort
  • 빠른 리베이스 : ID를 사용하여 특정 커밋 만 제거하십시오.

    git rebase --onto commit-id^ commit-id
    
  • 대안 : 당신은 또한 시도 할 수 있습니다 :

    git cherry-pick commit-id
    
  • 또 다른 대안 :

    git revert --no-commit
    
  • 최후의 수단으로, 히스토리 편집의 완전한 자유가 필요한 경우 (예를 들어, git은 원하는 것을 편집 할 수 없기 때문에)이 매우 빠른 오픈 소스 애플리케이션 reposurgeon을 사용할 수 있습니다 .

참고 : 물론 이러한 모든 변경 사항은 로컬에서 수행되므로 git push나중에 변경 사항을 리모컨에 적용 해야합니다 . 그리고 리포지토리가 커밋을 제거하지 않으려는 경우 (이미 푸시 한 커밋을 제거 할 때 발생하는 "빨리 감기 금지") git push -f변경 사항을 강제로 적용 할 수 있습니다 .

참고 2 : 지점에서 작업 중이고 강제로 푸시해야하는 git push --force경우 다른 지점을 덮어 쓸 수 있으므로 절대로 피해야 합니다 (현재 체크 아웃이 다른 지점에 있더라도 변경 한 경우). 선호하는 당신이 밀어 강제로 할 때 항상 원격 지사를 지정 : git push --force origin your_branch.


@gaborous의 제안에 따라 : "git rebase -i HEAD ~ 2"를 수행하십시오. 이제 몇 가지 옵션이 있습니다. vim에서 주석 처리 된 행을 볼 수 있습니다. 그 중 하나는 단순히 행을 삭제 (커밋을 제거하려는 커밋이어야 함) 할 수 있으며이 커밋은 기록에있는 로그와 함께 제거됩니다.
Ilker Cat

git revert --strategy resolve <commit>이 명령은 저에게 효과적이었습니다. 고마워요 :)
Swathin

2
git rebase -i HEAD~5나를 위해 일했다. 그런 다음 필요하지 않은 커밋을 제거하고 30 초 이내에 문제를 해결할 수있었습니다. 감사합니다.
lv10

118

쉬운 해결책은 다음과 같습니다.

git rebase -i HEAD~x

(참고 : x커밋 횟수입니다)

메모장 파일을 실행하면 열립니다. drop커밋 외에 입력하십시오 .
Vim을 모르는 경우 편집 할 각 단어 선택을 클릭 한 다음 "I"키를 누르십시오 (삽입 모드). 입력을 마치면 "esc"키를 눌러 삽입 모드를 종료하십시오.



여기에 이미지 설명을 입력하십시오

git 대시 보드를 동기화하면 변경 사항이 원격으로 푸시됩니다.

삭제 한 커밋이 이미 원격에있는 경우 강제로 푸시해야합니다. --force는 유해한 것으로 간주되므로 사용하십시오 git push --force-with-lease.


해당 커밋의 해시 만 알고 있다면 'x'가 무엇인지 알아내는 좋은 방법이 있습니까?
jlewkovich

1
cpp- 멘탈리티 사용자 : x (커밋 수)가 포함됩니다. 예를 들어 HEAD ~ 4에는 마지막 4 개의 커밋이 포함됩니다.
헤르페스 무료 엔지니어

완벽한 제안. 추가하기를 원하면 삭제 된 커밋의 변경 사항도 삭제됩니다.
celerno

3 커밋을 되돌리려 노력 : 자식 REBASE -i HEAD-3있어 오류 치명적 : 단일 개정 상류 잘못된 필요한 'HEAD-3'
Ustin

1
@Ustin ~ 3이 아닌 -3
JD-V

37

당신의 선택은

  1. 오류를 유지하고 수정 사항을 소개하고
  2. 오류를 제거하고 기록을 변경합니다.

(1) 다른 사람이 잘못 변경 한 항목을 선택했으면 (2) 오류가 비공개 푸시되지 않은 지점으로 제한되는 경우 선택해야합니다.

힘내 되돌리기는 (1) 자동 도구로, 이전 커밋을 취소하는 새 커밋을 만듭니다. 프로젝트 기록에 오류와 제거가 표시되지만 저장소에서 가져온 사람들은 업데이트 할 때 문제가 발생하지 않습니다. 당신이 편집 'myfile을'필요 그래서 그것은 당신의 예에서 자동화 된 방식으로 작동하지 않습니다, (2 호선을 제거) 할 git add myfilegit commit충돌을 처리 할 수 있습니다. 그러면 커밋 4가 커밋 2를 되돌 리면서 히스토리에 커밋 4 개가 생깁니다.

아무도 당신의 히스토리 변경을 신경 쓰지 않는다면, 그것을 다시 작성하고 커밋 2 (선택 2)를 제거 할 수 있습니다. 이 작업을 수행하는 쉬운 방법은 사용하는 것 git rebase -i 8230fa3입니다. 이렇게하면 편집기가 열리고 커밋을 제거하고 다른 커밋 메시지 옆에 "pick"을 유지하여 잘못된 커밋을 포함하지 않도록 선택할 수 있습니다.이 작업의 결과 에 대해 읽으십시오 .


Rebase는 병합 된 것처럼 들리기 때문에 까다로울 수 있습니다.
Cascabel

3
git rebase -i 8230fa3, 커밋 라인을 삭제하면 로컬 전용 변경 사항이 적용되었습니다. 감사!
사무엘

26

접근법 1

먼저 되돌려 야 할 커밋 해시 (예 : 1406cd61)를 가져옵니다. 간단한 수정은 명령 아래에 있습니다.

$ git revert 1406cd61

1406cd61 commit 후 1406cd61 파일과 관련된 변경 사항을 더 커밋하면 위의 간단한 명령이 작동하지 않습니다. 그런 다음 체리 따기 인 아래 단계를 수행해야합니다.

접근법 2

--force를 사용하고 있으므로 아래 작업을 수행하십시오 .git repo에 대한 관리자 권한 이 있어야 합니다.

1 단계 : 제거하려는 커밋 전에 커밋 찾기git log

2 단계 : 커밋 체크 아웃git checkout <commit hash>

3 단계 : 현재 결제 커밋을 사용하여 새 지점 만들기git checkout -b <new branch>

4 단계 : 이제 제거 된 커밋 후에 커밋을 추가해야합니다.git cherry-pick <commit hash>

5 단계 : 이제 유지하려는 다른 모든 커밋에 대해 4 단계를 반복하십시오.

6 단계 : 모든 커밋이 새 브랜치에 추가되고 커밋 된 후. 모든 것이 올바른 상태에 있고 의도 한대로 작동하는지 확인하십시오. 모든 것이 커밋되었는지 다시 확인하십시오.git status

7 단계 : 부서진 지점으로 전환git checkout <broken branch>

8 단계 : 이제 제거하려는 브랜치보다 커밋 된 브랜치에서 하드 리셋을 수행하십시오.git reset --hard <commit hash>

9 단계 : 고정 지점을이 지점으로 병합git merge <branch name>

10 단계 : 병합 된 변경 사항을 다시 원래 위치로 푸시하십시오. 경고 : 원격 저장소를 덮어 씁니다!git push --force origin <branch name>

2 단계와 3 단계를 8 단계로 바꾸고 7 단계와 9 단계를 수행하지 않으면 새 분기를 작성하지 않고 프로세스를 수행 할 수 있습니다.


1
첫 번째 접근 방식은 매력처럼 작동했습니다. 원하는 커밋이 되돌려 졌음을 지정하는 커밋이 포함되어있어 추적 목적으로 정말 좋습니다.
9

18

으로 원치 않는 커밋을 제거 할 수 있습니다 git rebase. 동료의 토픽 브랜치에서 토픽 브랜치에 커밋을 포함했지만 나중에 해당 커밋을 원하지 않는다고 결정했다고 가정하십시오.

git checkout -b tmp-branch my-topic-branch  # Use a temporary branch to be safe.
git rebase -i master  # Interactively rebase against master branch.

이 시점에서 텍스트 편집기는 대화식 rebase보기를 엽니 다. 예를 들어

git-rebase-todo

  1. 원하지 않는 커밋을 삭제하십시오.
  2. 저장하고 종료

리베이스가 실패한 경우 임시 분기를 삭제하고 다른 전략을 시도하십시오. 그렇지 않으면 다음 지시 사항을 계속하십시오.

git checkout my-topic-branch
git reset --hard tmp-branch  # Overwrite your topic branch with the temp branch.
git branch -d tmp-branch  # Delete the temporary branch.

토픽 브랜치를 리모트로 푸시하는 경우, 커밋 히스토리가 변경되었으므로 강제로 푸시해야 할 수도 있습니다. 다른 사람들이 같은 지점에서 일하고 있다면, 머리를 숙여주십시오.


'다른 전략 시도'의 예를 들어 주시겠습니까?
pfabri

@pfabri 예를 들어 잘못된 커밋을 생략하는 두 가지 커밋 범위를 체리 선택하십시오. 잘못된 커밋을 되돌릴 수 있습니다. 변경 사항을 수동으로 취소하거나 커밋이 잘못된 상태에서 새로운 브랜치에서 시작하여 좋은 변경 사항을 수동으로 다시 실행하여 git 솔루션을 사용하지 않을 수 있습니다. 잘못된 커밋에 민감한 데이터가 포함되어 있으면 help.github.com/en/articles/…와
Dennis

8

여기에있는 다른 답변에서 git rebase -i커밋을 제거하는 데 어떻게 사용 되는지 혼동 스러웠 으므로 테스트 사례를 여기에 적어 두는 것이 좋습니다 (매우 OP와 유사).

다음은 폴더에 bash테스트 저장소를 작성하기 위해 붙여 넣을 수 있는 스크립트입니다 /tmp.

set -x

rm -rf /tmp/myrepo*
cd /tmp

mkdir myrepo_git
cd myrepo_git
git init
git config user.name me
git config user.email me@myself.com

mkdir folder
echo aaaa >> folder/file.txt
git add folder/file.txt
git commit -m "1st git commit"

echo bbbb >> folder/file.txt
git add folder/file.txt
git commit -m "2nd git commit"

echo cccc >> folder/file.txt
git add folder/file.txt
git commit -m "3rd git commit"

echo dddd >> folder/file.txt
git add folder/file.txt
git commit -m "4th git commit"

echo eeee >> folder/file.txt
git add folder/file.txt
git commit -m "5th git commit"

이 시점에서 file.txt다음과 같은 내용이 있습니다.

aaaa
bbbb
cccc
dddd
eeee

이 시점에서 HEAD는 5 번째 커밋에 있으며 HEAD ~ 1은 4 번째이고 HEAD ~ 4는 첫 번째 커밋입니다 (따라서 HEAD ~ 5는 존재하지 않음). 세 번째 커밋을 제거하고 싶다고 가정 해 봅시다. myrepo_git디렉토리 에서이 명령을 실행할 수 있습니다 .

git rebase -i HEAD~4

( "치명적인 : 단일 개정이 필요했습니다; 유효하지 않은 업스트림 HEAD ~ 5"의 결과를 참고하십시오 git rebase -i HEAD~5. ) 텍스트 편집기 ( @Dennis의 답변 스크린 샷 참조 )는 다음 내용으로 열립니다.

pick 5978582 2nd git commit
pick 448c212 3rd git commit
pick b50213c 4th git commit
pick a9c8fa1 5th git commit

# Rebase b916e7f..a9c8fa1 onto b916e7f
# ...

따라서 요청 된 HEAD ~ 4 이후 ( 포함 하지는 않음 ) 모든 커밋을받습니다 . 줄을 삭제하고 pick 448c212 3rd git commit파일을 저장하십시오. 이 응답은 git rebase다음 에서 얻을 수 있습니다 .

error: could not apply b50213c... 4th git commit

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
Could not apply b50213c... 4th git commit

이 시점 folder/file.txt에서 텍스트 편집기에서 myrepo_git /를여십시오 . 당신은 그것이 수정 된 것을 볼 수 있습니다 :

aaaa
bbbb
<<<<<<< HEAD
=======
cccc
dddd
>>>>>>> b50213c... 4th git commit

기본적으로 gitHEAD가 2 차 커밋 할 때 aaaa+의 내용이 있음을 알 수 있습니다 bbbb. 다음은 추가 패치가 cccc+ dddd는 기존 내용에 추가하는 방법을 알고하지 않습니다.

그래서 여기에 git이 - 당신을위한 결정할 수없는 당신 (여기에 선을 당신도 그것에 의해 도입 된 변경 내용을 유지, 커밋 3을 제거하여 : 결정을 내려야하는 사람 cccc) - 또는 당신은하지 않습니다. 그렇지 않으면 텍스트 편집기 ccccfolder/file.txt사용하여 추가 라인을 포함하여 추가 라인을 제거하면 다음과 같습니다.

aaaa
bbbb
dddd

... 그리고 저장하십시오 folder/file.txt. 이제 myrepo_git디렉토리 에서 다음 명령을 실행할 수 있습니다 .

$ nano folder/file.txt  # text editor - edit, save
$ git rebase --continue
folder/file.txt: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add

아-그래서 우리가 갈등을 해결했다는 것을 표시 하려면 git add 다음 folder/file.txt을 수행하기 전에 해야 합니다 git rebase --continue.

$ git add folder/file.txt
$ git rebase --continue

여기에 텍스트 편집기가 다시 열리고 행이 표시됩니다. 4th git commit여기에서 커밋 메시지를 변경할 수 있습니다 (이 경우 의미있게 변경 될 수 있음 4th (and removed 3rd) commit). 원하지 않는다고 가정 해 봅시다. 저장하지 않고 텍스트 편집기를 종료하십시오. 일단 그렇게하면, 당신은 얻을 것이다 :

$ git rebase --continue
[detached HEAD b8275fc] 4th git commit
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/master.

이 시점에서, 당신은 (원래 커밋의 타임 스탬프가 변경되지 않은) gitk .내용에 대해 다음과 같은 이력을 가지고 있습니다 (말 이나 다른 도구로 검사 할 수 있음 folder/file.txt).

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   dddd
                |  +eeee

그리고 이전에 라인을 유지하기로 결정했다면 cccc(우리가 제거한 3 번째 자식 커밋의 내용) :

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +cccc
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   cccc
                |   dddd
                |  +eeee

글쎄, 이것은 내가 찾길 바라는 일종의 독서였습니다. git rebase커밋 / 개정 삭제 측면에서 어떻게 작동 하는지 파악하기 시작했습니다 . 다른 사람들도 도울 수 있기를 바랍니다.


내가 겪고있는 정확한 유스 케이스-이것이 귀중한 연습이었습니다. 이것은 엄청난 도움이되었습니다.
pfabri

2

따라서 잘못된 커밋이 특정 시점에 병합 커밋에 통합 된 것처럼 들립니다. 병합 커밋이 아직 풀렸습니까? 그렇다면 다음을 사용하고 싶을 것입니다 git revert. 이를 갈고 갈등을 해결해야합니다. 그렇지 않다면 아마도 리베이스 또는 되돌릴 수 있지만 병합 커밋 전에 그렇게 할 수 있습니다 . 그런 다음 병합을 다시 실행하십시오.

우리가 첫 번째 사건에 대해 당신에게 줄 수있는 도움은별로 없습니다. 되돌리기를 시도한 후 자동으로 실패한 것을 발견 한 후에는 충돌을 검사하고 적절하게 수정해야합니다. 이것은 병합 충돌을 수정하는 과정과 정확히 동일합니다. 당신이 사용할 수있는 git status갈등이있는 곳,이를 해결하는 방법을 알아낼를 충돌 심술쟁이을 찾아,보고, 편집 병합되지 않은 파일을 충돌 파일을 추가하고, 마지막 커밋합니다. 단독으로 사용 git commit하는 경우 (아니오 -m <message>), 편집기에서 팝업되는 메시지는 다음에 의해 작성된 템플리트 메시지 여야합니다 git revert. 충돌을 해결 한 방법에 대한 메모를 추가 한 다음 저장하고 커밋을 종료 할 수 있습니다.

두 번째 경우, 병합 하기 전에 문제를 해결 하기 위해 병합 이후 더 많은 작업을 수행했는지 여부에 따라 두 가지 하위 사례가 있습니다. 그렇지 않은 경우 git reset --hard HEAD^병합을 중단하고 되돌리기를 수행 한 다음 병합을 다시 실행할 수 있습니다. 그러나 나는 당신이 추측하고 있습니다. 따라서 다음과 같은 작업을 수행하게됩니다.

  • 병합 직전에 임시 브랜치를 만들고 체크 아웃하십시오.
  • 되돌리기를 수행하십시오 (또는 git rebase -i <something before the bad commit> <temporary branch>잘못된 커밋을 제거하는 데 사용 하십시오)
  • 병합을 다시 실행
  • 다음 작업을 다시 기반으로하십시오. git rebase --onto <temporary branch> <old merge commit> <real branch>
  • 임시 지점을 제거

1

그래서 당신은 몇 가지 일을하고 그것을 밀어 붙이고 A와 B를 커밋이라고 부를 수 있습니다. 동료도 몇 가지 일을하고 C와 D를 커밋합니다. (F를 커밋) 동료가 자신이 가져야 할 것들을 바꾼 것을 발견했습니다.

커밋 기록은 다음과 같습니다.

A -- B -- C -- D -- D' -- E -- F

당신은 정말로 C, D, D '를 제거하고 싶습니다. 동료 작업을 자신의 작업에 병합했다고 말했기 때문에 이러한 커밋은 이미 "밖으로"있으므로 git rebase를 사용하여 커밋을 제거하는 것은 아닙니다. 날 믿어 봐

이제 두 가지 방법이 있습니다.

  • E 또는 F를 동료 나 다른 사람 (일반적으로 "원본"서버)에게 아직 푸시하지 않은 경우에도 여전히 과거의 기록에서 해당 항목을 제거 할 수 있습니다. 이것은 저장하려는 작업입니다. 이것은 할 수 있습니다

    git reset D'
    

    (D '를 실제 커밋 해시로 바꾸십시오. git log

    이 시점에서 커밋 E와 F는 사라지고 변경 사항은 로컬 작업 영역에서 다시 커밋되지 않은 변경 사항입니다. 이 시점에서 나는 그것들을 가지로 옮기거나 패치로 바꾸어 나중에 저장하려고합니다. 이제 자동으로 git revert또는 수동 으로 동료의 작업을 되돌 립니다. 그렇게하면 그 위에 작업을 다시 재생하십시오. 당신은 병합 충돌이있을 수 있지만, 적어도 그들은 코드에있을 것이다 당신이 대신 동료의 코드로 썼다.

  • 동료의 커밋 후에 수행 한 작업을 이미 푸시 한 경우에도 수동으로 또는를 사용하여 "역 패치"를 시도 할 수 git revert있지만 작업이 " 중단 "상태이므로 계속해서 얻을 수 있습니다. 더 많은 병합 충돌과 더 혼란스러운 충돌. 그게 당신이 끝 났던 것 같습니다 ...


0

자식 되돌리기 --strategy 해결 커밋 경우는 병합입니다 : --strategy 해결 -m 1 되돌리기 사용 자식

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.