Dosya öznitelikleri

.gitattributes, git'te neredeyse kimsenin yazmadığı ama en çok değer üreten dosyadır. Bir deponun git'e kendi içeriğini öğretme yoludur: hangi dosyalar ikilidir, hangileri çakışmak yerine uç uca eklenmelidir, hangileri bir arşive hiç girmemelidir, herkes hangi satır sonlarını alacaktır.

Asıl önemli kısım: bu dosya commit'lenir. Eklediğiniz bir kural, depoyu klonlayan herkes için, her işletim sisteminde, kalıcı olarak sorunu çözer — kendi yapılandırmanızdaki bir ayarın aksine; o yalnızca sizi kurtarır ve meslektaşlarınızı aynı sorunu zor yoldan keşfetmeye bırakır.

⌘K → Dosya öznitelikleri.

Kurallar ne işe yarar

binary, -diff -merge -text kısaltmasıdır; yani "bu dosya hakkında tahmin yürütmeyi bırak" cevabının üçünü birden tek kelimede verir.

Düzenleme

Hazır ayarlar bir desen ile özniteliklerini doldurur; eklemeden önce deseni düzenleyin — CHANGELOG.md bir öneridir, projeniz hakkında bir kural değil.

Düzenlemeler cerrahidir. Zaten kuralı olan bir desen için kural eklemek, o satırı bulunduğu yerde yeniden yazar; sonradan geldiği için kazanan ikinci bir kural eklemez. Dosyadaki yorumlar olduğu gibi kalır, çünkü bir kuralın yanındaki "neden" genellikle kuralın kendisinden daha değerlidir.

Her kaydetme sıradan bir Gitcito eylemidir: bildirim çıkar ve Geri al dosyayı tam olarak eski hâline döndürür.

Bir depoda birden fazla öznitelik dosyası olabilir. Kök dizinde bir tane, herhangi bir alt dizinde bir tane ve hiçbir zaman commit'lenmeyen, yalnızca sizin makinenizde geçerli olan özel bir .git/info/attributes — projeyle değil sizinle ilgili bir kuralın doğru yeri. Gitcito hepsini listeler ve hangisinin ne olduğunu söyler.

Bir yola ne uygulanıyor?

Kurallar birden çok dosyadan gelir, daha özgül olan kazanır ve cevabı bulmak için hepsini okumak tahminden ibarettir. Bir yola ne uygulanıyor?, git check-attr çalıştırır ve git'in kendi vardığı sonucu gösterir — geçerli olan tek cevap.

Diff sürücüleri: bir Word belgesini okunabilir kılmak

Bir .docx aslında bir zip'tir. Bir .pdf sıkıştırılmış bir nesne çizgesidir. Git bunları ne iseler öyle diff'ler — yani gürültü olarak — ve böylece belge okunabilir olduğu hâlde geçmişi okunmaz olur.

Bir diff sürücüsü bunu textconv ile çözer: dosyayı yalnızca diff için metne çeviren bir komut. Çalışma dizinindeki dosyaya dokunulmaz; git sadece dönüştürülmüş metni karşılaştırır.

İki yarısı vardır ve ikisi de gereklidir:

1. Git yapılandırmasında diff.<name>.textconv — dönüştürücü komutu.
2. .gitattributes içinde *.docx diff=<name> — hangi dosyalara uygulanacağı.

Buradaki düğmeler ikisini birden yapar. Word, Excel, JSON ve .strings için dönüştürücüyü Gitcito'nun kendisi paketinde getirir — önizlemelerinin kullandığı belge ayrıştırmanın aynısı, uygulamanın içinde küçük bir gitcito-textconv komutu olarak sunulur — dolayısıyla bu dördü hiçbir şey kurmadan çalışır. Geri kalanların hâlâ PATH'inizde gerçek bir araca ihtiyacı vardır: Gitcito bunu denetler ve eksik olanı soluklaştırır; ilk diff'te başarısız olacak bir sürücü yazmaz.

iOS projelerini ısıran dosya

Localizable.strings, Xcode'un tarihinin neredeyse tamamında UTF-16'dır ve UTF-16 NUL baytlarıyla doludur; git de ona ikili der ve hiçbir şey göstermez:

diff --git a/Localizable.strings b/Localizable.strings
Binary files a/Localizable.strings and b/Localizable.strings differ

Oysa birinin hangi metni oynattığını görmenin en çok önem taşıdığı dosya tam da budur. strings sürücüsü onu yalnızca fark için çözer — bayt sırası işaretini varsaymak yerine okuyarak, böylece modern bir UTF-8 .strings bozulmadan geçer, anlamsız karakterlere dönüşmez.

String Catalog dosyaları (.xcstrings, Xcode 15 ve sonrası) JSON'dur ve json sürücüsü onları kapsar: anahtarları sıralar, böylece en üste eklenen bir çeviri farkta bütün dosyayı yeniden yazmayı bırakır.

Paketle gelen dönüştürücünün sınırları, açıkça söylersek: .doc (Word'ün eski ikili biçimi) anlaşılmaz, yalnızca .docx; PDF kapsanmaz — Gitcito PDF'leri tarayıcının görüntüleyicisiyle önizler ve yeniden kullanabileceği bir metin çıkarıcısı yoktur; ayrıca bir belgenin her diff'i kısa bir dönüştürücü başlatma bedeli öder. git config diff.<name>.cachetextconv true ayarı, git'in çıktıyı blob başına önbelleğe almasını sağlar.

Dönüştürücü yarısı sizin yapılandırmanızda yaşar, depoda değil — git, bir klonun size uzattığı komutları çalıştırmaz ve bu, korunmaya değer bir güvenlik özelliğidir. Paketle gelen sürücüler ayrıca sizin Gitcito kurulum yolunuzu gösterir; dolayısıyla depoyu klonlayan bir ekip arkadaşınız diff=word kuralını alır ama kendi dönüştürücüsünü (Gitcito ya da başka bir şey) bağlayana kadar yine eski okunaksız diff'i görür. Bunu README'nizde belirtin.

Clean/smudge filtreleri — önce bir deneme çalıştırmasıyla

Bir filtre, içeriği depoya girerken ve depodan çıkarken yeniden yazar: clean hazırlama sırasında (çalışma dizini → depo), smudge checkout sırasında (depo → çalışma dizini) çalışır. git-lfs böyle çalışır; ekipler de commit'lenen içerikten kimlik bilgilerini ya da üretilmiş gürültüyü böyle ayıklar.

Aynı zamanda .gitattributes'ın işaret edebileceği en tehlikeli şeydir: bir filtre eşleşen her dosyanın her checkout'unda çalışır ve yanlış bir filtre çalışma dizininizi sessizce bozar. Bu yüzden Gitcito burada düz bir metin kutusu olmayı reddeder. Bir filtreyi yapılandırmak, deponuzdaki gerçek eşleşen dosyalara karşı bir deneme çalıştırmasından geçer:

1. clean komutu, eşleşen her dosyanın bir kopyası üzerinde çalışır (en fazla beş dosya) — depoda veya yapılandırmasında hiçbir şeye dokunulmaz.
2. Bir smudge komutu verilmişse, temizlenmiş çıktı üzerinde çalıştırılır ve sonuç, özgün dosyayla bayt bayt karşılaştırılır — gidiş-dönüş denetimi. Gidiş-dönüşü tutmayan bir filtre, checkout'un elinizdekini geri getirmeyeceği anlamına gelir.
3. Kaydet düğmesi ancak tam olarak kaydettiğiniz değerler üzerindeki bir deneme çalıştırmasından sonra etkinleşir. Başarısız olmuş bir deneme çalıştırması — komut hatası, hiçbir eşleşme olmaması ya da farklı bir gidiş-dönüş — yine de kaydedilebilir, ama yalnızca neyin kaybolabileceğini söyleyen açık bir uyarı üzerinden.

Kaydetme, filter.<name>.clean/smudge girdisini yerel git yapılandırmanıza, filter=<name> kuralını da öznitelik dosyasına yazar ve yapılandırmanın önceki içeriğini geri getiren bir geri alma kaydı bırakır. required anahtarı filter.<name>.required ayarını yapar; bu da filtre bozulduğunda git'in dosyaları sessizce olduğu gibi geçirmek yerine işlemi başarısız saymasını sağlar.

Sınırlar, açıkça söylersek: deneme çalıştırması, her biri en fazla 5 MB olan en fazla beş eşleşen dosyayı örnekler ve komut başına 10 saniyelik bir zaman aşımı uygular — örneklemde uslu duran bir filtre, örneklemin kaçırdığı bir dosyada yine de yoldan çıkabilir. Komutlar sizin yapılandırmanızda yaşar; dolayısıyla depoyu klonlayan bir ekip arkadaşınız filter=<name> kuralını alır ama komutları almaz; onlar olmadan (ve required olmadan) dosyaları değişmeden geçer.

Bilinmeye değer sınırlar

• text=auto neyin commit'lendiğini değiştirir, satır sonlarını girişte normalleştirir. Mevcut bir depoda önce ekleyin, sonra bilinçli olarak git add --renormalize . çalıştırın — kendine ait tek bir commit içinde.
• Öznitelikler geriye dönük işlemez. Bir dosyayı bugün binary olarak işaretlemek geçmiş diff'lerinin nasıl saklandığını değiştirmez; yalnızca git'in bundan sonra ona nasıl davranacağını değiştirir.
• Kurallar yalnızca dosyanın göründüğü yerde geçerlidir. design/.gitattributes içindeki bir kural src/ hakkında hiçbir şey söylemez.
• Gitcito dosyaların tamamını yazar; bu yüzden elle biçimlendirilmiş bir dosya biçimiyle birlikte geri gelir — ama Gitcito'nun yeniden yazdığı bir kural, git'in kanonik pattern attr attr aralığına göre yeniden biçimlendirilir.

Ayrıca bakınız: LFS ve seyrek checkout · Bundle'lar ve arşivler · Merge seçenekleri · Hook'lar