Git-worktree'yi ne için kullanırdım?

Okuduğum git-worktree üzerinde Github adlı kullanıcının yayınını . Onlar yazar:

Diyelim ki feature, kullanıcı acil bir hatayı bildirdiğinde, adlı bir dalda Git deposunda çalışıyorsunuz master. Öncelikle yeni bir dal ile bağlantılı bir çalışma ağacı oluşturmak hotfix, ana göre kontrol dışarı […] Hata düzeltebilirsiniz, düzeltme itin ve bir çekme isteği oluşturabilirsiniz.

Feature adlı bir dal üzerinde çalıştığımda ve master'da bazı yüksek aciliyetli hatalar rapor edildiğinde, genellikle üzerinde çalıştığım her şeyi saklıyorum ve yeni bir dal oluşturuyorum. İşim bittiğinde çalışmaya devam edebilirim. Bu çok basit bir model, yıllardır böyle çalışıyorum.

Öte yandan, git-worktree kullanmanın kendi sınırlamaları vardır:

Örneğin, aynı şubenin aynı anda iki bağlantılı çalışma ağacında kontrol edilmesine izin verilmez, çünkü bu, bir çalışma ağacında yapılan değişikliklerin diğerini senkronize etmesini sağlar.

Zaten çözülmüş bir sorun için neden daha karmaşık bir iş akışı seçeyim?

Bu konuda git-worktreeönceden yapılamayan ve tüm bu yeni, karmaşık özelliği haklı çıkaran bir şey var mı ?

Benim için git worktree uzun zamandan beri en büyük gelişmedir. Kurumsal yazılım geliştirmede çalışıyorum. Orada, 3 yıl önce yayınladığınız gibi eski sürümleri korumanız çok yaygın. Elbette her sürüm için bir dalınız var, böylece kolayca geçip bir hatayı düzeltebilirsiniz. Bununla birlikte, anahtarlama pahalıdır, çünkü bu arada depo ve belki de inşa sistemini tamamen yeniden yapılandırdınız. Geçerseniz, IDE'niz proje ayarlarını uyarlamaya çalışırken çıldırır.

Çalışma ağacı ile bu sürekli yeniden yapılandırmayı önleyebilirsiniz. Çalışma ağacını kullanarak bu eski dalları ayrı klasörlerde kullanıma alın. Her şube için bağımsız bir IDE projeniz var.

Tabii ki bu geçmişte repoyu birkaç kez klonlayarak yapılabilirdi ve bu benim yaklaşımımdı. Bununla birlikte, bu aynı zamanda hardrive alanı boşa harcamak ve aynı değişiklikleri depodan birkaç kez almak için daha kötü bir ihtiyaç anlamına geliyordu.

Bunun bazı kullanımlarını görebiliyorum.

Uzun süre çalışan bir test paketiniz varsa, saatleri hayal edin ve başlatırsanız, testler tamamlanana kadar bu çalışma kopyasını etkili bir şekilde engeller. Bu testler sırasında dalların değiştirilmesi, anlaşılması zor yollarla onları kırabilir.

Böylece git-worktreeorada başka bir şube için ikinci bir fikrim olabilirdi.

Ayrıca, hızlı bir araştırma yapmak için başka bir şubeye geçtiğimde, IDE'm aniden değiştiğini düşünüyor ve tüm bu değişiklikleri dizine ekleyeceğim, sadece geri döndüğümde onları tekrar endekslemek zorundayım.

Üçüncü bir kullanım durumu , iki dal yerine iki dizin arasında git-diffnormalden farklı başka araçlar kullanarak dosya karşılaştırması yapmak olacaktır diff.

Bariz bir kullanım, farklı sürümlerin davranışını (kaynak değil) eşzamanlı olarak karşılaştırmaktır - örneğin bir web sitesinin veya yalnızca bir web sayfasının farklı sürümleri.

Bunu yerel olarak denedim.

• dizin yarat page1.

• içinde dizin srcve git initonu oluşturun.

• içinde srcoluşturmak page1.htmlbiraz içerikli ve bunu taahhüt.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• içinde srcusta fazla metin ekleyebilir page1.htmlve bunu taahhüt.

• $ git branch sty1

• düzenlemek page1.htmliçinde sty1şube (bazı ayırt edici CSS stil eklemek) ve bunu taahhüt ekleyin.

• $ git worktree add ../S1 sty1

Artık bu 3 sürümü aynı anda açmak ve görüntülemek için bir web tarayıcısı kullanabilirsiniz:

• ..\page1\src\page1.html // git ne olursa olsun git

• ..\page1\V0\page1.html // ilk sürüm

• ..\page1\S1\page1.html // deneysel olarak tasarlanmış sürüm

1. Dosya sisteminde aynı anda birden fazla çalışma ağacının olmasını isteyebileceğiniz / gereksinim duyabileceğinizin geçerli nedenleri vardır.

   • teslim dosyaları manipüle ederken marka gerek başka bir yere değişir (örn. derleme / test)

   • dosyaları normal fark araçlarıyla ayırma

   • Birleştirme çatışmaları sırasında, sık sık kaynak tarafında olduğu gibi kaynak koduna göz atarak istediğiniz ederken dosyalarında çatışmaları çözmek.

   • Çok fazla ileri ve geri geçiş yapmanız gerekiyorsa, zaman ödünç verme ve birden fazla çalışma dersi ile yapmanız gerekmediğini yeniden kontrol etme.

   • Git depolaması ile dallar arasında geçiş yapan zihinsel bağlamın zihinsel maliyeti gerçekten ölçülemez. Bazı insanlar sadece farklı bir dizinden dosyaları açarak saklamanın zihinsel maliyeti olduğunu buluyor.

2. Bazı insanlar "neden birden fazla yerel klon yapmıyor" diye soruyor. "--Local" bayrağı ile fazladan disk alanı kullanımı hakkında endişelenmenize gerek olmadığı doğrudur. Bu (ya da benzer fikirler) şimdiye kadar yaptığım şey. Yerel klonlara göre bağlantılı çalışma yöntemlerinin fonksiyonel avantajları:

   1. Yerel klonlar ile (yerel klonlarda bulunan) ekstra çalışma ağaçlarınızın menşe veya yukarı akış dallarına erişimi yoktur. Klondaki 'köken', ilk klondaki 'köken' ile aynı olmayacaktır.

      • Koşmak git log @{u}..veya git diff origin/feature/other-featureçok yardımcı olabilir ve bunlar artık mümkün değil veya daha zor. Bu fikirler, bir dizi geçici çözüm aracılığıyla yerel klonlarla teknik olarak mümkündür, ancak yapabileceğiniz her geçici çözüm bağlantılı çalışma yöntemleri aracılığıyla daha iyi ve / veya daha basit yapılır.

   2. Referansları çalışma saatleri arasında paylaşabilirsiniz. Başka bir yerel şubedeki değişiklikleri karşılaştırmak veya ödünç almak istiyorsanız, şimdi yapabilirsiniz.

tl; dr: Ne zaman olursa olsun, aynı anda iki çalışma ağacını kontrol ettirmek istediğinizde, git-worktreebunu yapmanın hızlı ve az yer kaplayan bir yoludur.

Başka bir çalışma ağacı oluşturursanız, repo'nun çoğu bölümü .gitpaylaşılacaktır, yani bir çalışma ağacındayken bir şube oluşturursanız veya veri alırsanız, buna sahip olduğunuz diğer çalışma ağaçlarından da erişilebilir. Diyelim ki test paketinizi klonlamak için bir yere itmek zorunda kalmadan dal foo üzerinde çalıştırmak istiyorsunuz ve deponuzu yerel olarak klonlama zahmetinden kaçınmak istiyorsanız, kullanmak git-worktree, geçici veya kalıcı olarak ayrı bir yer. Tıpkı bir klonda olduğu gibi, işiniz bittiğinde yapmanız gereken tek şey onu silmek ve ona referans bir süre sonra çöp toplanacak.

Başlangıçta bu süslü çalışmaların ne için kullanılabileceğini merak ettikten sonra bu soru üzerine tökezledim. O zamandan beri onları iş akışımla bütünleştirdim ve ilk şüpheciliğime rağmen onları oldukça faydalı bulmaya geldim.

Derlemek oldukça zaman alan oldukça büyük bir kod tabanı üzerinde çalışıyorum. Genellikle şu anda üzerinde çalıştığım özellik dalının yanı sıra canlı sistemin geçerli durumunu temsil eden ana dal ile birlikte makinemdeki geçerli geliştirme dalına sahibim.

Benim için en büyük faydalardan biri, şubeleri her değiştirdiğimde (yani çalışma saatleri) her şeyi yeniden derlemem gerekmediği. Güzel bir yan etkisi, geliştirme çalışma ağacına gidebilir, orada bir şeyler yapabilir, mevcut özellik dalım için çalışma ağacına dizini değiştirebilir ve sonra ilk önce çekmeye gerek kalmadan yeniden oluşturabilirim.

Oldukça sıradışı bir tane var: Aynı makinede Windows ve Linux geliştirme yapıyorum . Windows kutumun içinde Linux çalıştıran bir VirtualBox var. VirtualBox bazı Windows dizinlerini bağlar ve bunları doğrudan Linux makinesinin içinde kullanır. Bu, dosyaları yönetmek için Linux kullanmamı ancak Linux içinde oluşturmamı sağlıyor. Bu, çapraz platformlu bir projedir, bu nedenle aynı dizin yapısından hem Windows hem de Linux üzerine kurulur.

Sorun şu ki, Linux ve Windows derleme sistemleri aynı dizinde kullanıldıklarında birbirine çarpıyor; aynı dizin adlarını kullanan kütüphaneleri vb. indirmek için bazı karmaşık oluşturma adımları vardır. Derleme sisteminin Windows sürümü Windows'a özel kütüphaneleri indirir ve derleme sisteminin Linux sürümü Linux'a özel kütüphaneleri indirir.

İdeal bir dünyada, Windows ve Linux dizinde birlikte bulunabilecek şekilde yapı sistemi değiştirilecek, ancak şimdilik sorun çalışma ağaçlarıyla ilgileniliyor. "Linux" klasörü Linux'a özgü yapı yapıları oluşturabilir ve "Windows" klasörü Windows'a özgü yapı yapıları oluşturabilir. Bu neredeyse ideal bir çözüm olmasa da, derleme sistemi hatalarının ele alınmasını beklerken hoş bir durma aralığı oluşturur.

Kuşkusuz, çalışma ağacı bunun için tasarlanmamıştır; Gerçekten aynı dalda olmalarını tercih etsem de, Windows sürümünü ve Linux sürümünü ayrı dallarda tutmam gerekiyor. Yine de, bu işi yapıyor ve günü kurtarmak biraz alışılmadık bir çalışma vakası.

Benim için yeni projede bir özellik yarattım. Ancak bazı özellikler başarısız oldu. Sonuçları karşılaştırmak için masterbir work-treerepo oluşturdum . Neyin yanlış gittiğini anlayana kadar sonuçları çalışma kodunda adım adım karşılaştırdım.

git worktreeMakine öğrenimi gelişimi için kullanıyorum .

Ben bir ana fonksiyonel kod var ve sonra farklı deneyler (farklı algoritmalar ve farklı hiperparametreler) dallarını bölmek istiyorum. dvc kodumun farklı algoritmalara özel farklı sürümleri git worktreeile entegre etmemi sağlıyor . Tüm eğitim işlerini yürüttükten sonra son metrikleri değerlendirir ve en iyi şube / modelde ustalaşmak için birleşirim.