Depomda işlem yapmak istemediğim bir dosyada yerel değişikliklerim var. Uygulamayı bir sunucuda oluşturmak için bir yapılandırma dosyasıdır, ancak farklı ayarlarla yerel olarak oluşturmak istiyorum. Doğal olarak, dosya her zaman "git status" i sahnelenecek bir şey olarak gösterir. Bu özel değişikliği gizlemek ve taahhüt etmek istemiyorum. Dosyada başka değişiklik yapmayacağım.

Biraz kazdıktan sonra, 2 seçenek görüyorum: 'varsayılmadan değişti' ve 'atla-çalışma tablosu'. Bir önceki soru burada ormandan bahsederdi ama gerçekten aralarındaki farklılıkları açıklamıyor. Sorum şu: iki komut nasıl farklı? Biri neden birini veya diğerini kullanır?

Sen istiyorsun skip-worktree.

assume-unchangedbir grup dosyanın değiştirilip değiştirilmediğini kontrol etmenin pahalı olduğu durumlar için tasarlanmıştır; biti ayarladığınızda, git(elbette) dizinin o kısmına karşılık gelen dosyaların çalışan kopyada değiştirilmediğini varsayar. Böylece bir statarama karmaşasından kaçınır . Bu bit, dosyanın dizine girişi her değiştiğinde kaybolur (bu nedenle, dosya akış yukarı değiştiğinde).

skip-worktreeBundan daha geçerli: durumlarda bile git bilir dosya değiştirilmiş olduğunu (ya da modifiye edilmesi gerekmektedir reset --hardbenzeri veya), bunun yerine dizinden sürümünü kullanarak, bu olmamıştır davranacağım. Dizin atılana kadar bu devam eder.

Bu farkın sonuçları ve tipik kullanım durumlarının iyi bir özeti vardır: http://fallengamer.livejournal.com/93321.html .

Bu makaleden:

• --assume-unchangedbir geliştiricinin bir dosyayı değiştirmemesi gerektiğini varsayar . Bu bayrak, SDK'lar gibi değişmeyen klasörler için performansı artırmak içindir .
• --skip-worktreeEğer değil git'e talimat geliştiriciler çünkü daha önce belirli bir dosyayı dokunmak zaman yararlıdır gerektiğini değiştirin. Örneğin, ana depo akış yukarı bazı üretime hazır yapılandırma dosyaları barındırıyorsa ve yanlışlıkla bu dosyalarda değişiklik yapmak --skip-worktreeistemiyorsanız, tam olarak istediğiniz şeydir.

Not: fallengamer 2011'de bazı testler yaptı (bu yüzden eski olabilirler) ve işte bulguları :

Operasyonlar

• Dosya hem yerel depoda hem de yukarı akışta değiştirilir
  git pull
  yönünde değiştirilir : Git yine de yerel değişiklikleri korur.
  Bu nedenle, bayraklardan herhangi biriyle işaretlediğiniz verileri yanlışlıkla kaybetmezsiniz.
  • assume-unchangedBayraklı dosya : Git yerel dosyanın üzerine yazmaz. Bunun yerine çatışmalar çıkarır ve bunların nasıl çözüleceğine dair tavsiyeler verir
  • İle dosya skip-worktreeBayraklı : Git yerel dosyanın üzerine yazmaz. Bunun yerine çatışmalar çıkarır ve bunların nasıl çözüleceğine dair tavsiyeler verir

• Dosya hem yerel depoda hem de yukarı akışta değiştirilir, yine de çekmeye çalışıyor Bazı ekstra manuel çalışmalarda sonuçları kullanmak , ancak en azından yerel değişiklikleriniz varsa hiçbir veri kaybetmezsiniz.
  git stash
git pull
skip-worktree
  • assume-unchangedBayraklı dosya : Tüm yerel değişiklikleri geri yükleme olanağı olmadan atar. Etkisi ' git reset --hard' gibidir. ' git pull' çağrı başarılı olacak
  • skip-worktreeBayraklı dosya : Stash skip-worktreedosyalar üzerinde çalışmaz . ' git pull' yukarıdakiyle aynı hatayla başarısız olur. Geliştirici, skip-worktreesaklamak ve başarısızlığı tamamlamak için bayrağı manuel olarak sıfırlamak zorunda pull.

• Yerel değişiklik yok, yukarı akış dosyası değişti Her iki bayrak da yukarı akış değişikliklerini engellemez. Git söz verdiğinizi algılar ve bayrağı sıfırlayarak gerçeği yansıtmayı seçer.
  git pull
assume-unchanged
  • assume-unchangedBayraklı dosya : İçerik güncellenir, bayrak kaybolur.
    ' git ls-files -v', bayrağın H(den h) olarak değiştirildiğini gösterir .
  • skip-worktreeBayraklı dosya : İçerik güncellenir, bayrak korunur.
    ' git ls-files -v', önceki ile aynı Sbayrağı gösterirpull .

• Yerel dosya değiştiğinde
  git reset --hard
  Git skip-worktreedosyaya dokunmaz ve dosya için gerçekliği (değişmeden vaat edilen dosya değiştirildi) yansıtır assume-unchanged.
  • İle dosya assume-unchanged bayrak: Dosya içeriği döndürülür. Bayrak H(başlangıç h) konumuna sıfırlanır .
  • İle dosya skip-worktree bayrak: Dosya içeriği bozulmamış. Bayrak aynı kalır.

Aşağıdaki analizi ekliyor:

• Görünüşe skip-worktreeolan yerel verileri korumak için çok sıkı çalışıyor . Ancak güvenli olması durumunda yukarı yönde değişiklikler almanızı engellemez. Artı git bayrağı açmaz pull.
  Ancak 'reset --hard ' komutunu bir geliştirici için kötü bir sürpriz olabilir .

• Assume-unchanged üzerinde bayrak kaybolabilir pull işlem ve bu dosyalar içindeki yerel değişiklikler git için önemli görünmüyor.

Görmek:

• Junio'nun (şimdiki git sürdürücüsü) niyetiyle ilgili yorumuassume-unchanged ,

  Özellikle, Junio değişiklikler olduğuna dikkat çekiyor assume-unchanged"Git olarak işaretlenmiş bir yolunu belirlemek eğer: dosyaların yanlışlıkla işlenen olabilir assume-unchangedekstra lstat ödemeden değişti (2) maliyet, bu yolun bu rapora saklı tutar olmuştur değiştirilmiş ( Sonuç olarak, git commit -abu değişikliği yapmak ücretsizdir). "

• yama eklendikten sonra git posta listesindeki assume-unchangedve arasındaki farkskip-worktreeskip-worktree .

Sonuç olarak:

Aslında hiçbir bayrak yeterince sezgisel değil .

• assume-unchangedbir geliştiricinin bir dosyayı değiştirmemesi gerektiğini varsayar. Bir dosya değiştirildiyse - bu değişiklik önemli değildir. Bu bayrak, SDK'lar gibi değişmeyen klasörler için performansı artırmak içindir.
  Ancak söz bozulursa ve bir dosya gerçekten değiştirilirse git, gerçeği yansıtmak için bayrağı geri döndürür. Muhtemelen değiştirilmemesi gereken klasörlerde bazı tutarsız bayraklara sahip olmak iyidir.

• Diğer yandan skip-worktreegit'e belirli bir dosyaya dokunmama talimatı verdiğinizde kullanışlıdır. Bu, önceden izlenen bir yapılandırma dosyası için kullanışlıdır.
  Akış yukarı ana depo, üretime hazır bazı yapılandırmaları barındırır, ancak bazı yerel sınama yapabilmek için yapılandırmadaki bazı ayarları değiştirmek istersiniz. Ayrıca, üretim yapılandırmasını etkilemek için bu dosyadaki değişiklikleri yanlışlıkla kontrol etmek istemezsiniz. Bu durumda skip-worktreemükemmel bir sahne yapar.

Git 2.25.1 (Şubat 2020) ile, yukarıda belirtilen "Aslında hiçbir bayrak yeterince sezgisel değildir" daha da açıklığa kavuşturulmuştur:

Bkz. Taahhüt 7a2dc95 , taahhüt 1b13e90 (22 Ocak 2020), brian m. carlson ( bk2204) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 53a8329 tamamlama 2020 30 Ara)}
( Git posta listesini )

doc: kullanıcıları izlenen dosyaları yok saymaya çalışmaktan caydırın

^{İmzalayan: Jeff King
İmzalayan: brian m. carlson}

Kullanıcıların Git'in izlediği bir dosyadaki değişiklikleri yoksaymak istemeleri oldukça yaygındır.

Bu durum için sık karşılaşılan senaryolar IDE ayarları ve yapılandırma dosyalarıdır, bunlar genellikle bir mekanizma kullanılarak izlenen dosyalardan izlenmemeli ve muhtemelen izlenen dosyalardan oluşturulmalıdır.

Ancak, kullanıcılar varsayım-değiştirilmemiş ve atlama-atölyesi bitleri hakkında bilgi sahibi olurlar ve yine de bunu yapmak için bunları kullanmaya çalışırlar.

Bu sorunludur, çünkü bu bitler ayarlandığında, birçok işlem kullanıcının beklediği gibi davranır, ancak genellikle git checkout bir dosyayı değiştirmeniz gerektiğinde .

Bu durumda mantıklı bir davranış yoktur, çünkü bazen belirli yapılandırma dosyaları gibi veriler değerlidir ve bazen kullanıcının atmaktan mutlu olacağı alakasız verilerdir.

Bu desteklenen bir yapılandırma olmadığından ve kullanıcılar mevcut özellikleri istenmeyen amaçlarla kötüye kullanmaya eğilimli olduklarından, genel üzüntü ve karışıklığa neden olurlar , mevcut davranışları ve belgelerindeki tuzakları belgeleyelimgit update-index , kullanıcıların alternatif çözümleri keşfetmeleri gerektiğini bilmesi .

Ek olarak, birçok yapılandırmada başarılı bir şekilde kullanılan iyi bilinen yaklaşımlar olduğundan, yapılandırma dosyalarının yaygın durumuyla başa çıkmak için önerilen bir çözüm sağlayalım.

git update-indexAdam sayfa şimdi içerir:

Kullanıcılar, Git'e izlenen dosyalarda yapılan değişiklikleri yok saymasını bildirmek için genellikle assume-unchangedve skip-worktreebitlerini kullanmaya çalışırlar . Git beklendiği gibi çalışmaz, çünkü Git yine de belirli işlemleri gerçekleştirirken çalışma ağacı dosyalarını dizine göre kontrol edebilir. Genel olarak Git, izlenen dosyalarda yapılan değişiklikleri yok saymanın bir yolunu sunmaz, bu nedenle alternatif çözümler önerilir.

Örneğin, değiştirmek istediğiniz dosya bir tür yapılandırma dosyasıysa, havuz daha sonra yok sayılan ada kopyalanıp değiştirilebilen örnek bir yapılandırma dosyası içerebilir. Depo, örnek dosyayı şablon olarak işlemek, otomatik olarak değiştirmek ve kopyalamak için bir komut dosyası da içerebilir.

Bu son kısım, bulaşma / temiz komut dosyalarına dayanan tipik bir içerik filtresi sürücüsünü tarif ettiğim şey .