답변:
Git은 자체적으로 정보 를 버리지 않습니다 *. 모든 파일의 모든 이전 버전은 되돌리기, 차이, 검사 등에 항상 사용할 수 있습니다.
조정하려고 시도하는 것은 Git의 히스토리 모델이 전체 트리에 집중되어 있다는 사실과 개별 파일의 이전 버전에 액세스한다는 아이디어입니다. 전체 트리 버전 관리는 foo.c10 개의 foo.c변경 이전에 존재했던 버전 과 10 개의 전체 트리 변경 이전에 존재했던 버전을 보려면 약간의 작업이 더 필요합니다 .
# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c
# 10 whole-tree-changes ago
git show HEAD~10:foo.c
트리 방향의 이점, 주로 커밋을 전체 트리의 여러 부분에 대한 상호 의존적 변경 단위로 볼 수있는 기능은 일반적으로 여분의 타이핑 (별칭, 스크립트 등으로 완화 할 수 있음) 및 CPU 시간보다 훨씬 큽니다. 과거 커밋을 파헤쳐 보냈습니다.
새로운 객체 (예 : 이전에 보이지 않은 내용을 가진 파일)가 시스템에 들어가면 일반 (zlib) 압축으로“느슨한 객체”로 저장됩니다. gc.auto구성 옵션 에 따라 충분한 느슨한 객체가 누적 되거나 사용자가 git gc 또는 하위 레벨 패킹 명령 중 하나를 실행할 때 Git은 많은 느슨한 객체를 단일 "팩 파일"로 수집합니다.
팩 파일의 객체는 일반 압축 데이터 (느슨한 객체와 동일, 다른 객체와 번들로 제공) 또는 다른 객체에 대한 압축 델타로 저장 될 수 있습니다. 델타는 구성 가능한 깊이 ( pack.depth)에 함께 연결될 수 있으며 적절한 객체에 대해 만들어 질 수 있습니다 ( pack.windowGit이 최고의 델타베이스를 얼마나 광범위하게 검색하는지 제어합니다. 좋은 델타 압축). 깊이 및 창 크기 구성이 델타 압축 엔진에 제공하는 위도는 종종 CVS 스타일의 간단한 1- 버전 대 다음 / 이전 버전 "diff"압축보다 델타 압축이 더 우수합니다.
Git 리포지토리 (전체 히스토리 및 압축되지 않은 작업 트리가있는)가 단일 SVN 체크 아웃 (압축되지 않은 작업 트리 및 깨끗한 사본 사용)보다 공간을 덜 차지하게하는 것은이 공격적인 델타 압축 (일반 zlib 압축과 결합)입니다.
Git 커뮤니티 북의 Git 이 객체를 저장 하는 방법 및 Packfile 섹션을 참조하십시오 . 또한 자식 팩 - 객체 맨 .
* Git에게 커밋을“기록을 다시 작성”하고 git reset 과 같은 명령 을 사용하여 커밋을 폐기 할 수는 있지만, 이러한 경우에도 Git은 새로 폐기 된 커밋을 필요로하는 경우를 대비하여 잠시 동안 중단됩니다. git reflog 및 git prune을 참조하십시오 .
같은 페이지에서 읽을 수 있습니다 :
...
따라서 Git은 소스 코드 트리 아래의 어떤 수준에서도 파일 개정 관계를 명시 적으로 기록하지 않습니다.
...
전체 프로젝트보다 단일 파일의 변경 기록을 검사하는 것이 약간 더 비쌉니다. 주어진 파일에 영향을주는 변경 히스토리를 얻으려면 Git이 글로벌 히스토리를 따라 간 다음 각 변경 사항이 해당 파일을 수정했는지 판별해야합니다. 그러나 히스토리를 검사하는이 방법은 Git이 임의의 파일 세트에 대한 변경 사항을 보여주는 단일 히스토리를 동일한 효율로 생성하도록합니다. 예를 들어, 소스 트리의 하위 디렉토리와 관련 전역 헤더 파일이 매우 일반적인 경우입니다.
...
따라서 이전 버전의 파일로 돌아가서 두 파일을 비교할 수 있습니다.
git은 실제로 델타 파일을 저장하지만 전체 파일 트리의 델타로 저장합니다.
버전 간 차이점을 보려면 다음 중 하나를 수행하십시오.
git add실행 되지 않은 파일의 차이점을 보여줍니다 .git add실행되었지만 커밋되지 않은 모든 파일의 차이점을 보여줍니다.