Git alt modüllerini kullanmanın geliştirme iş akışım için bir şekilde sorunlu olduğunu düşünüyorum. Git subtree ve Gitslave hakkında bir şeyler duydum.
Yanıtlar:
Hangisinin sizin için en iyisi, ihtiyaçlarınıza, isteklerinize ve iş akışınıza bağlıdır. Bazı açılardan yarı izomorfiktirler, sadece bazılarının belirli görevler için diğerlerine göre kullanımı çok daha kolaydır.
gitslave , alt projeleri süper projeyle aynı anda çok daha az kontrol ettiğinizde ve geliştirdiğinizde ve ayrıca tüm depoları aynı anda etiketlemek, dallara ayırmak, itmek, çekmek vb. istediğinizde kullanışlıdır. gitslave bildiğim pencerelerde hiç test edilmedi. Perl gerektirir.
git-submodule , alt projeleri kontrol etmediğinizde veya alt proje değişse bile alt projeyi belirli bir revizyonda düzeltmek istediğinizde daha iyidir. git-submodule, git'in standart bir parçasıdır ve bu nedenle pencerelerde çalışır.
git-subtree , git'in yerleşik alt ağaç birleştirme stratejisi için bir ön uç sağlar. Tek depolu "birleşik" git geçmişine sahip olmayı tercih ettiğinizde daha iyidir. Alt ağaç birleştirme stratejisinden farklı olarak, farklı (dizin) ağaçlardaki değişiklikleri orijinal projeye geri aktarmak daha kolaydır, ancak gitslave ve hatta git-submodule ile olduğu kadar otomatik değildir.
repo teoride gitslave'e benzer, ancak bulduğum android dışı işlemler için o kadar iyi belgelenmedi. Oldukça Google Android geliştirme modeline adanmıştır ve yalnızca bir avuç git komutunu yerel olarak destekler (isteğe bağlı komutlar çalıştırabilirsiniz) ve sınırlı yerel destek, örneğin, bir şube oldukça zor görünüyor.
kitenet'in mr , kullanımda birden fazla sürüm kontrol sisteminiz varsa kullanmak isteyeceğiniz şeydir, ancak en düşük ortak payda yaklaşımı nedeniyle çoğunlukla yalnızca git özellikli süper projeler için sınırlıdır. Rasgele komutları çalıştırmanın yolları vardır, ancak bunlar çok iyi entegre değildir.
mr run git config ...belirli komutları adlara takma ad vermek için yapılandırma dosyası yöntemi gibi veya belki (daha da kötüsü) hakkında konuştuğunuzu varsayıyorum . Elbette, man sayfasından hemen anlaşılmayan bazı mr işlevlerinin farkındaysanız, bunu bilmek isterim.
git/contrib. İle Ubuntu yükleyin sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-corea Git kaynak ağacından (yok değil paketlenmiş Git ile çalışmak).
Alternatifler listesine yeni bir ekleme Git X-Modules'dir . Burada açıklandığı gibi Git Alt Modüllerinin tipik dezavantajlarından kaçınmak içindir . Temel fark, tüm senkronizasyonun sunucu tarafında yapılmasıdır, bu nedenle son kullanıcılar için klonladıkları ve ittikleri normal bir Git deposu vardır.
Şu anda geliştirme için alt modülleri kullanıyorum ve sadece 3. parti kitaplıklarla ilgili değil. Alt modüller ile hayatı kolaylaştırmanın bazı yolları vardır, özellikle bunlar birleştirme veya yeniden yapılandırma çatışmalarının kaynağı olduklarında. Alt modüldeki bir çatışmaya dahil olan 2 commit'i almak için ls-tree'ye bakın. Bu muhtemelen alt modüllerin insanların uğraşması için en zor kısmıdır. Şimdilik komut dosyası oluşturma, bununla çalışmayı çok daha kolay hale getirecek. Git'in gelecekteki sürümleri, bunlarla başa çıkmak için daha iyi yerel desteğe sahip olmalıdır.
Bu yardımcı olur umarım.
Çeşitli dillerde bağımlılıklarımızın olduğu projelerde Git alt modüllerini kullanırken benzer bir sorunla karşılaştık. Bunlarla başa çıkmak için, size Git alt modüllerine benzer işlevselliğe sahip, ancak sinir bozucu iş akışı olmadan bildirimsel sürüm kontrollü Git bağımlılıkları sağlayan MDLR ("Modüler") adlı bir araç geliştirdik ve açık kaynaklı hale getirdik. GitHub deposundaki talimatlar / indirmelerle kurabilir ve bağımlılıklarınızı yönetebilirsiniz.
Bazı kullanım durumlarında, aşağıdaki iki basit yaklaşımın her birini beğendim:
İç içe geçmiş depolar. Yazılım projenizin bir eklenti mekanizması varsa, her eklenti kendi alt dizininde bulunursa, bu eklenti dizinlerini git-yok saymak ve yerel dosya sisteminizde her birini kendi git deposuna dönüştürmek mantıklı olabilir. Bu şekilde, tüm dosyalarınız tek bir dizin ağacı oluşturur, ancak farklı git depolarında yönetilir. Git'i karıştırmayacak.
Paket başına havuzlar. Bir tür kaynak kodu paket yönetim sistemi (gem / bundler, npm, pear veya benzeri) kullandığınız yazılım projeleri için, yeniden kullanılan kodunuzu ayrı git depolarına koymak ve ardından bunlardan kaynak paketleri oluşturmak mantıklı olabilir. ve sonra bunları paket yönetimi aracıyla ana projeye yüklemek için. Ana projenizin git deposu yalnızca gerekli paketlere ve bunların sürümlerine bir referans içerirken, bu paketlerin gerçek kodu, diğer tüm paketlerde ve dış kitaplıklarda olduğu gibi git-yok sayılır. Yukarıda önerilen yuvalanmış depolarla karşılaştırıldığında bu, hangi paket sürümünün kurulacağını belirlemeye izin verdiği için daha ayrıntılı bir yaklaşımdır.