이 질문은 약간 A/B입니다. 오래 전에 커밋 레코드를 삭제하는 시나리오를 설명하지 않았기 때문입니다. 이는 이후 Git 사용 선택에 영향을 미치기 때문에 매우 중요합니다. 예:
시험 전에 제출한 제출물을 기록에서 삭제하고 싶지만 나중에 보관해야 할 제출물이 여전히 많은 경우 다음을 수행하세요.
1.2 삭제할 이력 기록이 흩어져 있는 경우 Interactive Rebase, 직접 선택/병합 등을 고려해 볼 수 있습니다. git rebase -i <ref> 등
1.1 삭제할 이력 레코드가 연속적일 경우, 예를 들어 처음부터 특정 순간까지의 모든 레코드를 삭제하거나 중간 부분을 삭제할 수 있는 경우 Onto Rebase 등을 고려해 볼 수 있습니다. git rebase --onto <ONTO_BASE_ref> <START_ref> <END_ref>과 같이 START은 END 사이의 부분을 유지해야 하는 부분이고, ONTO_BASE은 최신 기준점입니다. 즉, ONTO_BASE과 START 사이의 기록은 삭제됩니다.
많은 기록 기록을 삭제하고 아주 적은 기록만 유지하려는 경우(예: 가장 최근 기록만 유지하고 더 이상 원하지 않음) 고아 분기 기록을 재구성합니다. 예를 들어 , 이 명령은 git checkout --orphan new_start이라는 분기를 생성합니다. 이 분기에는 기록이 없지만 모든 파일은 그대로 존재하므로 이에 따라 다시 제출을 시작할 수 있습니다. 완료 후에는 이전 분기를 직접 삭제할 수도 있습니다. 또한 새 분기의 시작점을 지정할 수도 있습니다. 기본값은 물론 new_start부터 시작됩니다. HEAD
역사 기록을 두 부분(또는 그 이상)으로 나눌 수도 있는데, 그 중 일부는 완전하고 일부는 단순화된 등입니다. 자세한 내용은
에 대한 이 문서를 참조하세요: http://git -scm.com/2010/03/17/replace.html
git replace
사실 Git의 사용법은 매우 유연하다고 할 수 있습니다. 일시적으로 사용하지 않더라도 어떤 일을 할 수 있는지 주의 깊게 읽어 볼 가치가 있습니다. 그러면 다양하고 복잡한 시나리오에 직면했을 때 스스로 추론할 수 있습니다.
Repo의 관리자로서 가장 일반적인 일은 특정 참조부터 HEAD까지 보관한 후 이전 기록을 삭제하는 것입니다. 이 작업은 비교적 일반적이므로 공유할 쉘 스크립트는 다음과 같습니다.
으아악
은 다음과 같이 사용됩니다(예: 스크립트가
로 저장됨): git-detach, 여기서 git-detach <ref>는 보관하려는 기록 기록의 시작점입니다. <ref>
이 스크립트는 기록 레코드만 "분리"하며 그 중 일부는 눈에 띄는 참조가 없고 기록 레코드에 표시되지 않는다는 점에 유의해야 합니다. 그러나 해당
git 개체는 여전히 존재합니다( 즉, 을 직접 복구하고 확인할 수 있습니다. 이 기록을 완전히 삭제하려면(저장소의 무게를 줄이기 위해) git-reflog을 사용하면 절대 얻을 수 없습니다. 다시. git gc --prune
추신: 이 스크립트는 Orphan Branch에 의존하며, 이는 Git의 하위 버전(아마 < v1.7.x)에서 지원되지 않습니다. 대안이 있는 경우 직접 Google에 문의하세요.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
이 질문은 약간 A/B입니다. 오래 전에 커밋 레코드를 삭제하는 시나리오를 설명하지 않았기 때문입니다. 이는 이후 Git 사용 선택에 영향을 미치기 때문에 매우 중요합니다. 예:
- 시험 전에 제출한 제출물을 기록에서 삭제하고 싶지만 나중에 보관해야 할 제출물이 여전히 많은 경우 다음을 수행하세요.
- 많은 기록 기록을 삭제하고 아주 적은 기록만 유지하려는 경우(예: 가장 최근 기록만 유지하고 더 이상 원하지 않음) 고아 분기 기록을 재구성합니다. 예를 들어 , 이 명령은
역사 기록을 두 부분(또는 그 이상)으로 나눌 수도 있는데, 그 중 일부는 완전하고 일부는 단순화된 등입니다. 자세한 내용은 - 에 대한 이 문서를 참조하세요: http://git -scm.com/2010/03/17/replace.html
사실 Git의 사용법은 매우 유연하다고 할 수 있습니다. 일시적으로 사용하지 않더라도 어떤 일을 할 수 있는지 주의 깊게 읽어 볼 가치가 있습니다. 그러면 다양하고 복잡한 시나리오에 직면했을 때 스스로 추론할 수 있습니다.1.2 삭제할 이력 기록이 흩어져 있는 경우 Interactive Rebase, 직접 선택/병합 등을 고려해 볼 수 있습니다.
git rebase -i <ref>등 1.1 삭제할 이력 레코드가 연속적일 경우, 예를 들어 처음부터 특정 순간까지의 모든 레코드를 삭제하거나 중간 부분을 삭제할 수 있는 경우 Onto Rebase 등을 고려해 볼 수 있습니다.
git rebase --onto <ONTO_BASE_ref> <START_ref> <END_ref>과 같이START은END사이의 부분을 유지해야 하는 부분이고,ONTO_BASE은 최신 기준점입니다. 즉,ONTO_BASE과START사이의 기록은 삭제됩니다.git checkout --orphan new_start이라는 분기를 생성합니다. 이 분기에는 기록이 없지만 모든 파일은 그대로 존재하므로 이에 따라 다시 제출을 시작할 수 있습니다. 완료 후에는 이전 분기를 직접 삭제할 수도 있습니다. 또한 새 분기의 시작점을 지정할 수도 있습니다. 기본값은 물론new_start부터 시작됩니다.HEADgit replaceRepo의 관리자로서 가장 일반적인 일은 특정 참조부터 HEAD까지 보관한 후 이전 기록을 삭제하는 것입니다. 이 작업은 비교적 일반적이므로 공유할 쉘 스크립트는 다음과 같습니다.
으아악
은 다음과 같이 사용됩니다(예: 스크립트가로 저장됨):
이 스크립트는 기록 레코드만 "분리"하며 그 중 일부는 눈에 띄는 참조가 없고 기록 레코드에 표시되지 않는다는 점에 유의해야 합니다. 그러나 해당git-detach, 여기서git-detach <ref>는 보관하려는 기록 기록의 시작점입니다.<ref>git 개체는 여전히 존재합니다( 즉, 을 직접 복구하고 확인할 수 있습니다. 이 기록을 완전히 삭제하려면(저장소의 무게를 줄이기 위해)
git-reflog을 사용하면 절대 얻을 수 없습니다. 다시.git gc --prune추신: 이 스크립트는 Orphan Branch에 의존하며, 이는 Git의 하위 버전(아마 < v1.7.x)에서 지원되지 않습니다. 대안이 있는 경우 직접 Google에 문의하세요.