방금이 작업을 수행 할 수 facepalmed :
git reset
그렇습니다. 이는 자습서 "git 명령 사용"과 동일합니다. 최종 효과는 정확히 git diff HEAD의 결과를 제외하고 모든 것을 맨 위 커밋으로 롤백 한 다음 해당 diff를 HEAD에 다시 적용하여 원래 작업 트리를 다시 만드는 것과 같습니다.
그러나 실제로 삭제 된 변경 사항이 인덱스에서 제외되므로 해당 삭제 된 변경 사항이 실제로 작업에서 제외됩니다. 이 경우, 어떤 나는 변경을 잇기 대화 형 REBASE를 사용하는 것입니다 할 것 : 온다 편집기 창에서
git commit # commit the index
git commit -a # commit the remaining changes
git rebase --interactive HEAD^^ # rebase top two commits onto same branch
, 나는 단순히 온 원치 않는 변경을 보유하고 커밋 삭제할 것 불필요한 인덱스에서 삭제 한 다음 저장하고 종료하여 대화 형 리베이스가 나머지 작업을 수행하게하십시오. 이전에 unstaged 원한 변경이 단계적으로 원치 않는 변경에 의존했을 수 있으므로 병합 충돌이있을 수 있습니다.
결국 나는 이전에 unstaged 된 변경 사항 만있는 단일 커밋을 가지게되며 원치 않는 변경 사항은 사라집니다. 바로 커밋하고 여기에 추가하고 메시지를 업데이트하기 위해 더 많은 일을 해킹 git commit --amend하여 작업을 계속 다른
git reset HEAD^
또는 : 그 시점에서, 나는 unstaged 변경으로 돌려, 커밋을 제거 얻을 수 있습니다.
rebase --interactive (실제로 비대화 형 리베이스가 수행하는 모든 작업)은 cherry-pick 명령으로 수행 할 수 있지만 편리한 "워크 플로 자동화"를 제공합니다.
커밋의 순서 변경, 커밋 삭제, 여러 커밋을 하나로 스쿼시하고, 커밋 메시지 (최상위 패치 제외)를 다시 작성하는 것과 관련된 모든 시나리오의 경우 사용 방법을 알고있는 것이 좋습니다 대화 형 리베이스.
아이디어는 모든 변경 사항의 표현을 별도의 커밋으로 전환 한 다음 커밋 - 쿵푸로 작업하고, 필요한 경우 마지막으로 "커밋 해제"합니다.
복잡한 작업을 수행 할 때 git은 임시 영역과 같은 unstaged 변경 또는 인덱스보다 커밋 작업을하는 것이 좋습니다. 그래서 당신은 거기에서 일을하고 먼저 커밋을하고 싶습니다. 실제로 무단 변경 또는 단계적 변경이있는 경우 git은 다양한 유용한 작업을 수행하지 못하도록합니다.
작업을 커밋해야하는 한 가지 이유는 git에서 작업 복사본이나 인덱스를 영원히 잃어 버리기 쉽다는 것입니다. 작업 복사본과 인덱스는 커밋 개체가 아니므로 reflog에서 복구 할 수 없습니다. 이들 중 하나 또는 둘 모두를 지우는 명령을 잘못 입력하면 명령이 올바르게 수행됩니다. 그러나 이 변경되면 커밋은 잃어버린 경우에도, reflog를 통해, 또는 설정할 수있는 분기 포인터 나 태그를 통해 복구 할 수 있습니다.
대담한 코드를 재설정하기 위해'git reset -p'를 시도하십시오. – chepner
@chepner : 잘 이해했다면,'git reset -p'는 변경 사항을 무대 뒤에서 만 처리하지만 버리지는 않을 것입니다. – lrineau