사용 방법에 대해 매우 혼란 스럽습니다 git archive.

최상위 수준에 Foo , Bar 및 Baz 폴더가있는 git 저장소가 있습니다. 빠른 테스트 배포를 위해 Foo 폴더를 SVN 방식으로 내 보내야합니다.

내가 사용할 수있는 것을 알게 git-archive에서 방법의 SVN 틱 수출 정렬 .

그러나 여기에 다음이 잘 작동합니다.

git archive master | tar -x -C ~/destination

대상 폴더 에 Foo , Bar , Baz 폴더가 생성됩니다 .

그러나, 다음은 밖으로 오류가 발생하지 로 fatal not a valid object name:

git archive master/foo | tar -x -C ~/destination

문서

git archive프로그램 의 시놉시스를 살펴보면 <tree-ish> [path]매개 변수로 사용할 수 있음을 알 수 있습니다 (관련 부분에 요약 된 시놉시스).

git archive <tree-ish> [path...]

하면 master/foo 되지 tree-ish, 무슨 다음?

짧은 답변 (TL; DR)

"Tree-ish"는 궁극적으로 (하위) 디렉토리 트리 (Git는 디렉토리를 "트리"및 "트리 객체"라고 함)로 이어지는 모든 식별자 ( Git 개정 문서에 지정됨)를 참조하는 용어입니다 .

원래 포스터의 경우 지정하려는 foo 디렉토리 입니다. Git에서 (하위) 디렉토리를 지정하는 올바른 방법은이 "tree-ish"구문을 사용하는 것입니다 ( Git 개정 문서의 항목 # 15 ).

<rev>:<path>예를 들면 HEAD:README, :README,master:./README

접미사 :뒤에 경로가 있으면 콜론 앞 부분에 의해 명명 된 tree-ish 개체의 지정된 경로에있는 blob 또는 트리의 이름이 지정됩니다.

즉, master:foo올바른 구문이 아니라 master/foo.

기타 "트리 스타일"(더하기 커밋)

다음은 commit-ish 및 tree-ish 식별자의 전체 목록입니다 ( Git 개정 문서 에서 지적한 LopSae 덕분에 ).

----------------------------------------------------------------------
|    Commit-ish/Tree-ish    |                Examples
----------------------------------------------------------------------
|  1. <sha1>                | dae86e1950b1277e545cee180551750029cfe735
|  2. <describeOutput>      | v1.7.4.2-679-g3bee7fb
|  3. <refname>             | master, heads/master, refs/heads/master
|  4. <refname>@{<date>}    | master@{yesterday}, HEAD@{5 minutes ago}
|  5. <refname>@{<n>}       | master@{1}
|  6. @{<n>}                | @{1}
|  7. @{-<n>}               | @{-1}
|  8. <refname>@{upstream}  | master@{upstream}, @{u}
|  9. <rev>^                | HEAD^, v1.5.1^0
| 10. <rev>~<n>             | master~3
| 11. <rev>^{<type>}        | v0.99.8^{commit}
| 12. <rev>^{}              | v0.99.8^{}
| 13. <rev>^{/<text>}       | HEAD^{/fix nasty bug}
| 14. :/<text>              | :/fix nasty bug
----------------------------------------------------------------------
|       Tree-ish only       |                Examples
----------------------------------------------------------------------
| 15. <rev>:<path>          | HEAD:README, :README, master:./README
----------------------------------------------------------------------
|         Tree-ish?         |                Examples
----------------------------------------------------------------------
| 16. :<n>:<path>           | :0:README, :README
----------------------------------------------------------------------

식별자 # 1-14는 모두 "커밋 방식"입니다. 모두 커밋으로 이어지지 만 커밋도 디렉토리 트리를 가리 키기 때문에 모두 궁극적으로 (하위) 디렉터리 트리 개체로 이어 지므로 "트리로도 사용할 수 있습니다." -ish ".

# 15는 (하위) 디렉토리를 참조 할 때 tree-ish로도 사용할 수 있지만 특정 파일을 식별하는데도 사용할 수 있습니다. 파일을 참조 할 때 여전히 "트리 다운"으로 간주되는지 또는 "blob-ish"와 비슷하게 작동하는지 확실하지 않습니다 (Git는 파일을 "blobs"라고 함).

긴 답변

가장 낮은 수준에서 Git은 네 가지 기본 개체를 사용하여 소스 코드를 추적합니다.

1. 커밋을 가리키는 주석이 달린 태그.
2. 프로젝트의 루트 디렉토리 트리를 가리키는 커밋.
3. 디렉터리 및 하위 디렉터리 인 트리.
4. 파일 인 Blob.

Linus Torvalds가 콘텐츠 주소 지정이 가능한 파일 시스템 처럼 Git을 설계했기 때문에 이러한 각 개체에는 자체 sha1 해시 ID 가 있습니다. 즉, 콘텐츠를 기반으로 파일을 검색 할 수 있습니다 (sha1 ID는 파일 콘텐츠에서 생성됨). Pro Git 책은 다음 예제 다이어그램을 제공 합니다 .

많은 Git 명령은 커밋 및 (하위) 디렉터리 트리에 대한 특수 식별자를 허용 할 수 있습니다.

• "Commit-ish"는 궁극적으로 커밋 객체로 연결되는 식별자입니다. 예를 들면

  tag -> commit

• "Tree-ish"는 궁극적으로 트리 (즉, 디렉토리) 객체로 이어지는 식별자입니다.

  tag -> commit -> project-root-directory

커밋 개체는 항상 디렉터리 트리 개체 (프로젝트의 루트 디렉터리)를 가리 키기 때문에 "commit-ish"인 식별자는 정의상 "tree-ish"이기도합니다. 즉, 커밋 개체로 연결되는 모든 식별자를 사용하여 (하위) 디렉터리 트리 개체로 연결될 수도 있습니다. .

그러나 디렉토리 트리 객체는 Git의 버전 관리 시스템에서 커밋을 가리 키지 않기 때문에 (하위) 디렉토리 트리를 가리키는 모든 식별자가 커밋을 가리 키기 위해 사용될 수도 있습니다. 다시 말해, "커밋 방식"식별자 집합은 "트리 방식"식별자 집합의 엄격한 하위 집합입니다.

문서에 설명 된대로 ( 찾을 수 있도록 도와 준 Trebor에게 감사드립니다 ) :

<tree>

트리 개체 이름을 나타냅니다.

<commit>

커밋 개체 이름을 나타냅니다.

<tree-ish>

트리, 커밋 또는 태그 개체 이름을 나타냅니다. 소요 명령 <tree-ish> 인수는 궁극적으로 작동하도록하려는 <tree>목적되지만 자동으로 역 참조 <commit>와 <tag>에서 그 점을 객체 <tree>.

<commit-ish>

커밋 또는 태그 개체 이름을 나타냅니다. <commit-ish> 인수를 사용 하는 명령은 궁극적으로 <commit>개체 에서 작동하려고 하지만를 가리키는 <tag>개체를 자동으로 역 참조 합니다 <commit>.

커밋 방식으로 사용할 수없는 트리 방식 식별자 집합은 다음과 같습니다.

1. <rev>:<path>, 이는 커밋 객체가 아닌 디렉토리 트리 로 직접 연결 됩니다 . 예를 들면 HEAD:subdirectory.

2. 디렉터리 트리 개체 의 Sha1 식별자 .

tree-ish는 다음 중 하나가 될 수있는 특정 트리의 이름을 지정하는 방법입니다.

• 다음과 같은 참조 :
  • 머리
  • 태그
  • 지점 이름
  • 리모컨이있는 지점 이름 origin/somebranch
• 해시시
• 짧은 해시

그 위에, 상기의 어느 하나가 추가 될 수있다 ^, ~. 참조는 @{}몇 가지 추가 기능에 대한 표기법을 사용할 수도 있습니다 .

• HEAD^또는 HEAD^1HEAD의 첫 번째 부모로 확인됩니다.
• HEAD^2 두 번째 부모에게 해결됩니다.
• HEAD^3더 드물고 문어 전략과 의 합병의 산물 인 세 번째 부모 등으로 해결됩니다 .
• HEAD~또는 HEAD~1머리의 첫 번째 부모로 해결됩니다.
• HEAD~2HEAD의 첫 번째 부모의 첫 번째 부모로 확인됩니다. 이것은 다음과 같습니다.HEAD^^
• HEAD@{0} 현재 HEAD로 해결됩니다.
• HEAD@{1}이전 헤드로 해결됩니다. 참조 로그를 사용하므로 참조에서만 사용할 수 있습니다. 의 경우에는 HEAD모든 커밋, 병합, 체크 아웃 HEAD의 값을 변경하며, 따라서 로그에 추가한다. git reflog HEADHEAD의 모든 움직임을 볼 수있는 참조 로그를 표시하고 제대로 @{1}해결되는 항목 등을 표시합니다.

그것은 예를 들어, 저장소에 의미가로 위의 대부분은 더 긴으로 결합 될 수있다 : HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

따라서 위에서 설명한 모든 조합과 그 조합은 문서에서 tree-ish로 의미하는 것입니다. 이는 대부분의 git 명령에 사용해야하는 트리 (또는 개정판)가 무엇인지 말하는 방법입니다.

Git 책의 개정 선택에 대한 자세한 정보 .

당신은 아마 원합니다

git archive master foo | tar -x -C ~/destination

이 표현 master/foo은 의미가 없습니다. master은 분기 이름이고 foo제가 생각하기에 디렉토리 이름입니다.

편집 : (깨진 링크를 제거했습니다. 주석을보십시오.)

의 정의 <tree-ish>및 <commit-ish>투시 자식 (1) man 페이지를. 용어를 검색해야합니다. 일반적으로 <tree-ish>git 트리 객체에 대한 참조를 의미하지만 트리를 참조하는 객체 유형 (예 : 커밋 또는 분기)을 전달하면 git은 자동으로 참조 된 트리를 사용합니다.

나는 소스 제어와 자식에 대한 초보자입니다. 이것이 내가 아는 것입니다. 트리는 저장소에있는 파일의 구조입니다. 파일 시스템의 디렉토리와 유사합니다. 참조- 이 트리보기를 생성 한 git 도구는 무엇입니까?

Tree-ish는 나무와 같은 의미입니다. 트리의 일부 또는 커밋을 참조합니다. 커밋의 SHA-1 해시의 전체 또는 일부, HEAD 포인터, 분기 참조, 태그 참조 중 하나를 사용하여 커밋을 참조 할 수 있습니다. 또 다른 방법은 커밋의 조상 또는 부모와 함께 언급 된 방법 중 하나를 사용합니다. 조상 예 :

에서 힘내 용어 트리 틱 "A 트리 객체 또는 재귀 트리 객체에 역 참조 할 수있는 개체가"입니다. 커밋, HEAD 및 태그는 나무 모양의 개체의 예입니다.