Nasıl kullanılacağı konusunda kafam çok karışık git archive.

En üst düzeyde Foo , Bar ve Baz klasörüne sahip bir git depom var . Hızlı test dağıtımı için Foo klasörünü SVN benzeri bir şekilde dışa aktarmam gerekiyor .

Ben kullanabilirsiniz öğrendim git-archivebir in yol SVN-imsi ihracat tür .

Ama olay şu: Aşağıdakiler iyi çalışıyor:

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

hedef klasörde Foo , Bar , Baz klasörleri ile sonuçlanır .

Ancak, şu dışarı hata olacaktır ile fatal not a valid object name:

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

Dökümantasyon

git archiveProgramın özetine baktığımda, <tree-ish> [path]bir parametre olarak alabileceğini görüyorum (özet, ilgili bölümlere özetlenmiştir):

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

Eğer master/foo değil tree-ish, ne zaman?

Kısa Cevap (TL; DR)

"Ağaç benzeri", sonuçta bir (alt) dizin ağacına (Git dizinlere "ağaçlar" ve "ağaç nesneleri" olarak atıfta bulunur) yol açan herhangi bir tanımlayıcıya ( Git revizyon belgelerinde belirtildiği gibi) atıfta bulunan bir terimdir .

Orijinal posterin durumunda, belirtmek istediği foo bir dizindir . Git'te bir (alt) dizin belirtmenin doğru yolu, bu "ağaç benzeri" sözdizimini kullanmaktır ( Git revizyonları belgelerinden öğe # 15 ):

<rev>:<path>Örneğin HEAD:README, :README,master:./README

Bir :yolun izlediği bir sonek , iki nokta üst üste işaretinden önceki kısım tarafından adlandırılan ağaç benzeri nesnede verilen yolda blob veya ağacı adlandırır.

Yani, başka bir deyişle, master:foodoğru sözdizimi, değil master/foo.

Diğer "Tree-ish" (Plus Commit-ish)

İşte taahhüt-ish ve ağaç imsi tanımlayıcıları tam listesi (geliyor Git revizyonları dokümantasyon , bunu işaret için LopSae sayesinde ):

----------------------------------------------------------------------
|    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 no'lu tanımlayıcıların tümü "commit-ish" dir, çünkü hepsi kaydetmeye yol açar, ancak işlemeler aynı zamanda dizin ağaçlarına da işaret ettiğinden, sonuçta (alt) dizin ağaç nesnelerine yol açar ve bu nedenle "ağaç" olarak da kullanılabilir -imtrak".

# 15, bir (alt) dizine atıfta bulunduğunda ağaç benzeri olarak da kullanılabilir, ancak belirli dosyaları tanımlamak için de kullanılabilir. Dosyalara atıfta bulunduğunda, hala "ağaç benzeri" olarak kabul edilip edilmediğinden veya daha çok "blob-ish" gibi davranıp çalışmadığından emin değilim (Git, dosyalara "blob" olarak atıfta bulunur).

Uzun Cevap

En düşük seviyelerinde Git, dört temel nesne kullanarak kaynak kodunu izler:

1. Kaydetmeye işaret eden açıklamalı etiketler.
2. Projenizin kök dizin ağacına işaret eden Commits.
3. Dizinler ve alt dizinler olan ağaçlar.
4. Bloblar, dosyalardır.

Linus Torvalds Git'i içerik adreslenebilir bir dosya sistemi gibi tasarladığından, bu nesnelerin her birinin kendi sha1 hash ID'si vardır, yani dosyalar içeriklerine göre alınabilir (sha1 ID'leri dosya içeriğinden üretilir). Pro Git kitabı şu örnek diyagramı verir :

Birçok Git komutu, işlemeler ve (alt) dizin ağaçları için özel tanımlayıcıları kabul edebilir:

• "Commit-ish", sonuçta bir commit nesnesine götüren tanımlayıcılardır. Örneğin,

  tag -> commit

• "Ağaç benzeri", nihayetinde ağaç (yani dizin) nesnelerine götüren tanımlayıcılardır.

  tag -> commit -> project-root-directory

Commit nesneleri her zaman bir dizin ağacı nesnesine (projenizin kök dizini) işaret ettiğinden, "commit-ish" olan herhangi bir tanımlayıcı, tanımı gereği, aynı zamanda "tree-ish" dir. Başka bir deyişle, bir commit nesnesine götüren herhangi bir tanımlayıcı, bir (alt) dizin ağaç nesnesine yönlendirmek için de kullanılabilir .

Ancak, dizin ağacı nesneleri hiçbir zaman Git'in sürüm oluşturma sistemindeki işlemlere işaret etmediğinden, bir (alt) dizin ağacına işaret eden her tanımlayıcı da bir yürütmeyi işaret etmek için kullanılamaz. Diğer bir deyişle, "kesinleştirme" tanımlayıcıları kümesi, "ağaç benzeri " tanımlayıcılar kümesinin katı bir alt kümesidir.

Belgelerde açıklandığı gibi ( bulmama yardım ettiği için Trebor'a teşekkürler ):

<tree>

Bir ağaç nesnesi adını belirtir.

<commit>

Kaydetme nesnesi adını gösterir.

<tree-ish>

Bir ağaç, kaydetme veya etiket nesnesi adını belirtir. Bir <tree-ish> argümanı alan bir komut, nihayetinde bir <tree>nesne üzerinde işlem yapmak ister, ancak otomatik olarak başvurulardan <commit>ve <tag>bir <tree>.

<commit-ish>

Bir kaydetme veya etiket nesnesi adını belirtir. Bir <commit-ish> argümanı alan bir komut, nihayetinde bir <commit>nesne üzerinde işlem yapmak ister, ancak <tag>bir <commit>.

Ağaç imsi tanımlayıcılar kümesi olarak kullanılamaz tamamlama-imsi vardır

1. <rev>:<path>, doğrudan dizin ağaçlarına götürür , nesneleri işlemeye değil. Örneğin HEAD:subdirectory,.

2. Dizin ağacı nesnelerinin Sha1 tanımlayıcıları .

Ağaç benzeri, aşağıdakilerden biri olabilen belirli bir ağacı adlandırmanın bir yoludur:

• Gibi referanslar:
  • BAŞ
  • Etiketler
  • Şube isimleri
  • Uzaktan kumandalı şube adları origin/somebranch
• esrar
• Kısa karmalar

Bunun üzerine, yukarıda belirtilen herhangi biri ile eklenebilir ^, ~. Referanslar ayrıca @{}bazı ek özellikler için gösterimi kullanabilir :

• HEAD^veya HEAD^1HEAD’in ilk ebeveynine çözümlenecektir.
• HEAD^2 ikinci ebeveyne karar verecek
• HEAD^3üçüncü ebeveyne çözülür ve bu daha nadirdir ve ahtapot stratejisiyle birleşmenin bir ürünüdür .
• HEAD~veya HEAD~1başın ilk ebeveynine karar verecek
• HEAD~2HEAD'in ilk ebeveyninin ilk ebeveynine çözümlenecektir. Bu aynı olacaktırHEAD^^
• HEAD@{0} mevcut HEAD ile çözülecek
• HEAD@{1}önceki kafaya çözümlenecek. Bu, referans günlüğünü kullandığından yalnızca referanslar tarafından kullanılabilir. HEADHer kaydetme, birleştirme, teslim alma durumunda HEAD'in değerini değiştirir ve böylece günlüğe ekler. git reflog HEADHEAD'in tüm hareketlerini görebileceğiniz ve neye @{1}vb. çözüleceğini düzgün bir şekilde görebileceğiniz referans günlüğünü görüntüler .

Örneğin, sizin deposundaki mantıklı olarak yukarıda çoğu ayrıca sürece birleştirilebilir: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Dolayısıyla, yukarıda açıklananlardan herhangi biri ve kombinasyonları, belgelerde ağaç benzeri olarak kastedilen şeydir; bu, git komutlarının çoğu için hangi ağacın (veya revizyonun) kullanılması gerektiğini söylemenin bir yoludur.

Git kitabındaki Revizyon Seçimi hakkında daha fazla bilgi .

Muhtemelen istiyorsun

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

İfade bir master/fooanlam ifade etmiyor: masterbir dal adı ve footahmin ettiğim gibi bir dizin adı.

Düzenle : (Bozuk bağlantı kaldırıldı. Yorumlara bakın.)

Tanımları için <tree-ish>ve <commit-ish>bakın budala (1) man sayfası. Terimleri aramanız gerekecek. Genel olarak <tree-ish>, bir git ağaç nesnesine bir başvuru anlamına gelir, ancak bir ağaca (commit veya dallanma gibi) başvuran bir nesne türü iletirseniz, git, başvurulan ağacı otomatik olarak kullanır.

Kaynak kontrolü ve git konusunda acemiyim. Bildiğim bu. Ağaç, bilgi havuzundaki dosyaların yapısıdır. Bir dosya sistemindeki bir dizine benzer.Bkz. - Bu ağaç görünümünü hangi git aracı oluşturdu?

Tree-ish, ağaç gibi demektir. Bir ağacın bir kısmına veya işlemesine başvurur. Şunlardan herhangi birini kullanarak bir işleme referans verebilirsiniz: Bir işlemenin SHA-1 karmasının tamamı veya bir kısmı, HEAD işaretçisi, dal referansı, etiket referansı. Başka bir yöntem, bir commit'in ataları veya ebeveynleri ile birlikte belirtilen yöntemlerden herhangi birini kullanır. Atalar örneği:

Gönderen Git Sözlüğü ağaç ish "Bir ağaç nesne veya yinelemeli bir ağaç nesnesine indirgenmedikleri edilebilir bir nesne" dir. commit, HEAD ve tag ağaç benzeri nesnelere örnektir.