Git에서 tree-ish는 무엇을 의미합니까?

Git에서 tree-ish는 무엇을 의미합니까?

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

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

사용할 수 있다는 것을 배웠습니다.git-archiveSVN식 수출 방식으로

하지만, 다음과 같은 것들이 잘 작동합니다.

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은 디렉토리를 "tree" 및 "tree objects"로 지칭).

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

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

접미사:다음 경로는 콜론 앞에 있는 부분으로 명명된 트리 같은 개체의 주어진 경로에서 블롭 또는 트리의 이름을 지정합니다.

그러니까, 다시 말해서,master:foo정확한 구문입니다. 그렇지 않습니다.master/foo.

기타 "트리시"(게다가 커밋시)

다음은 커밋식 식별자와 트리식 식별자의 전체 목록입니다(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"이지만 커밋은 디렉토리 트리를 가리키기 때문에 결국 모두 (하위) 디렉토리 트리 개체로 이어지므로 "트리-ish"로도 사용할 수 있습니다.

#15는 (서브) 디렉토리를 지칭할 때 트리시(tree-ish)로 사용될 수도 있지만 특정 파일을 식별하는 데 사용될 수도 있습니다.파일을 언급할 때 여전히 "나무 같은" 것으로 간주되는지 아니면 "블롭 같은"(Git은 파일을 "블롭"으로 지칭함)처럼 행동하는지 잘 모르겠습니다.

긴 대답

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

1. 주석이 달린 태그로, 커밋을 가리킵니다.
2. 프로젝트의 루트 디렉터리 트리를 가리키는 커밋입니다.
3. 트리, 디렉토리 및 하위 디렉토리입니다.
4. 블롭, 파일입니다.

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

수많은 Git 명령어들은 커밋과 (서브) 디렉토리 트리에 대한 특별한 식별자를 받아들일 수 있습니다.

• "커밋-ish"는 궁극적으로 커밋 개체로 이어지는 식별자입니다.예를들면,

  tag -> commit

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

  tag -> commit -> project-root-directory

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

그러나 디렉터리 트리 개체는 Git의 버전 시스템에서 커밋을 가리키는 경우가 없기 때문에, (하위) 디렉터리 트리를 가리키는 모든 식별자가 커밋을 가리키는 데에도 사용될 수 있는 것은 아닙니다.즉, "커밋-ish" 식별자 집합은 "트리-ish" 식별자 집합의 엄격한 부분 집합입니다.

설명서에서 설명한 바와 같이(찾을 수 있도록 도와준 Trebor 덕분에):

<tree>

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

<commit>

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

<tree-ish>

트리, 커밋 또는 태그 개체 이름을 나타냅니다.명령어가 필요할 때는<tree-ish>논쟁은 궁극적으로 a에 작용하기를 원합니다.<tree>객체이지만 자동으로 참조를 제거합니다.<commit>그리고.<tag>a를 가리키는 물건들<tree>.

<commit-ish>

커밋 또는 태그 개체 이름을 나타냅니다.명령어가 필요할 때는<commit-ish>논쟁은 궁극적으로 a에 작용하기를 원합니다.<commit>객체이지만 자동으로 참조를 제거합니다.<tag>a를 가리키는 물건들<commit>.

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

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

2. 디렉토리 트리 개체의 Sha1 식별자입니다.

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

• 참조 내용:
  • 머리
  • 태그
  • 지점명
  • 원격이 있는 분기 이름, 예를 들어origin/somebranch
• 해시
• 짧은 해시

여기에 위의 내용 중 하나를 첨부할 수 있습니다.^,~. 참조는 다음을 사용할 수도 있습니다.@{}일부 추가 기능에 대한 표기법:

• HEAD^아니면HEAD^1HAD의 첫번째 부모에게 해결될 것입니다.
• HEAD^2두번째 부모에게 해결할 것입니다.
• HEAD^3세 번째 부모에게 해결할 것이고, 이것은 더 희귀하고 문어 전략과의 결합의 산물입니다.
• HEAD~아니면HEAD~1머리의 첫번째 부모에게 결심할 것입니다.
• HEAD~2HAD의 첫 번째 부모에게 확인됩니다.이것은 다음과 같습니다.HEAD^^
• HEAD@{0}현재 헤드로 해결됩니다.
• HEAD@{1}이전 머리로 해결할 것입니다참조 로그를 사용하므로 참조에서만 사용할 수 있습니다.의 경우HEAD모든 커밋, 머지, 체크아웃 시 헤드 값이 변경되어 로그에 추가됩니다.git reflog HEAD헤드의 모든 움직임을 볼 수 있는 참조 로그를 표시합니다. 그리고 올바르게 무엇을 표시할 것인가요?@{1}곧 해결될 겁니다

다음과 같이 저장소에서 이해가 되는 한 위의 대부분을 추가로 조합할 수 있습니다.HEAD@{2}~3,somebranch^2~4,c00e66e~4^2,anotherbranch~^~^~^.

따라서 위에서 설명한 모든 것과 그 조합은 문서에서 트리-ish로 의미하는 것이며, 이는 대부분의 git 명령에 사용되어야 하는 트리(또는 리비전)가 무엇인지를 말할 수 있는 방법일 뿐입니다.

Git book의 Revision Selection(수정본 선택)에서 자세한 내용을 확인할 수 있습니다.

당신은 아마도 당신이 원할 것입니다.

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

이.master/foo의미가 없습니다.master는 지점명이고.foo제가 추측하는 대로 디렉토리 이름입니다.

편집: (중단된 링크를 제거했습니다.댓글참조)

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

저는 컨트롤과 깃의 소스를 처음 접하는 사람입니다.이것이 제가 아는 것입니다.트리는 저장소에 있는 파일의 구조입니다.파일 시스템의 디렉토리와 유사합니다.참조 - 이 트리 보기를 생성한 깃 도구는 무엇입니까?

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

Git Glossary tree-ish에서 "트리 객체 또는 트리 객체에 재귀적으로 참조될 수 있는 객체"입니다. commit, HEAD 및 tag는 트리 객체의 예입니다.

언급URL : https://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git