Git deposundaki Tekil veya çoklu projeler arasında seçim yapmak

gitÇoğu projeyi modüle ettiğimiz bir ortamda, depo başına bir projeyle veya depo tasarımı konusu başına birden çok projeyle karşı karşıyayız . Modüler bir proje düşünelim:

myProject/
   +-- gui
   +-- core
   +-- api
   +-- implA
   +-- implB

Bugün depo başına bir proje yapıyoruz . Bu özgürlük verir

• release kişisel bileşenler
• tag kişisel bileşenler

Ancak, aynı zamanda branch, dallanma ve sık sık dallanma api, eşdeğer dallar coreve belki de diğer bileşenler gerektirdiği için de zahmetlidir .

releaseAyrı ayrı bileşenlere ulaşmak istediğimizde, depo tasarımı başına birden fazla proje kullanarak hala benzer esnekliği elde edebiliriz .

Hangi deneyimler var ve bu sorunları nasıl / niçin ele aldınız?

one project per repositoryYukarıda tanımladığınız şekilde, üç büyük dezavantajı vardır . Gerçekten farklı projelerlerse bunlar daha az doğrudur, ancak seslerinden bir tanesine değişen sesler genellikle bir başkasında değişiklik gerektirir, bu da gerçekten bu sorunları abartır:

1. Hataların ne zaman ortaya çıktığını keşfetmek daha zor. Araçlar sever git bisectsen alt depoları içine depo kırılma kullanılacak çok daha zor hale gelir. Bu var , mümkün olduğu çok daha zordur bunun kriz zamanlarında böcek avı anlamına kadar kolay değil.
2. Bir özelliğin tüm geçmişini takip etmek çok daha zordur. Tarihçe gezme komutları, git loggeçmişi kırılmış depo yapılarıyla anlamlı şekilde göstermez. Alt modüller veya alt ağaçlarla veya diğer komut dosyası yöntemleriyle bazı yararlı çıktılar elde edebilirsiniz , ancak bu sadece ilgilendiğiniz tüm taahhütleri yazmak tig --grep=<caseID>veya git log --grep=<caseID>taramakla aynı değildir . Tarihinizin anlaşılması zorlaşır, bu gerçekten ihtiyacınız olduğunda daha az kullanışlı olmasını sağlar.
3. Yeni geliştiriciler, Kodlamaya başlamadan önce Sürüm Denetimi'nin yapısını öğrenmek için daha fazla zaman harcarlar. Her yeni iş, toplama prosedürleri gerektirir, ancak bir proje havuzunu kırmak, kodun mimarisine ek olarak VC yapısını almak zorunda oldukları anlamına gelir. Tecrübelerime göre, bu, tek bir depo kullanan daha geleneksel, merkezileştirilmiş mağazalardan gelen git için yeni olan geliştiriciler için özellikle zordur.

Sonunda, bu bir fırsat maliyet hesaplaması. Eski bir işverende, birincil başvurumuzu 35 farklı alt havuza ayırdık. Bunların üzerine, tarih aramak için karmaşık bir senaryo dizisi kullandık, devletin (yani üretim-gelişim dalları) aynı olduğundan ve onları ayrı ayrı ya da toplu olarak kullandıklarından emin olduk.

Sadece çok fazlaydı; en azından bizim için çok fazla. Genel gider yönetimi, özelliklerimizi daha az çevik hale getirdi, konuşlandırmayı daha da zorlaştırdı, yeni aygıtlara ders vermek çok zaman aldı ve sonunda, depoyu neden kırdığımızı hatırlayamadık. Güzel bir bahar gününde, EC2'deki küme hesaplama zamanı öğleden sonra için 10 dolar harcadım. Depoları birkaç düzine çağrıyla birlikte geri ördüm git filter-branch. Asla geriye bakmadık.

Christopher , havuz başına bir proje modelinin dezavantajlarını sıralamak için çok iyi bir iş yaptı. Çoklu havuz yaklaşımını göz önünde bulundurmanızın nedenlerinden bazılarını tartışmak istiyorum. Çalıştığım birçok ortamda, çok havuzlu bir yaklaşım makul bir çözümdü, ancak kaç depoya sahip olacağına ve kesimleri nereye yapacağına karar vermek her zaman kolay bir iş değildi.

Şu anki durumumda, on yıldan fazla bir geçmişe sahip tek havuzlu CVS deposunu çok sayıda git havuzuna geçirdim. Bu ilk karardan beri, depo sayısı (diğer takımların eylemleri ile) çoğaldıklarından daha uygun olacağından şüphelendiğim noktaya geldi. Bazı yeni çalışanlar depoları birleştirmeyi önerdi ancak ben buna karşı savundum. Wayland projesi de benzer bir deneyime sahiptir. Geçenlerde gördüğüm bir konuşmada, bir noktada, liderin özür dilediği 200'den fazla git deposu vardı. Web sitelerine bakarken şimdi 5 yaşında olduklarını görüyorum, bu makul görünüyor. Depolara katılmanın ve bölmenin yönetilebilir bir görev olduğunu gözlemlemek önemlidir ve (aklın içinde) denemenin bir sakıncası yoktur.

Peki ne zaman birden fazla havuz isteyebilirsiniz?

1. Tek bir depo verimli olamayacak kadar büyük olacaktır.
2. Havuzlarınız gevşek bir şekilde bağlanmış veya ayrılmıştır.
3. Bir geliştirici genellikle geliştirmek için depolarınızın yalnızca birine veya küçük bir alt kümesine ihtiyaç duyar.
4. Genellikle depoları bağımsız olarak geliştirmek istersiniz ve yalnızca zaman zaman senkronize etmeniz gerekir.
5. Daha fazla modülerliği teşvik etmek istiyorsun.
6. Farklı ekipler farklı depolarda çalışır.

Puan 2 ve 3 yalnızca puan 1 tutarsa ​​önemlidir. Depolarımızı bölerek, site dışındaki meslektaşlarımızın uğradığı gecikmeleri, disk tüketimini azalttığımı ve ağ trafiğini artırdım.

4 ve 5 daha incedir. Bir istemci ve sunucu deyince depolarını böldüğünüzde bu, istemci ve sunucu kodu arasındaki değişiklikleri koordine etmeyi daha maliyetli hale getirir. Bu, ikisi arasında ayrık bir arayüzü teşvik eden bir pozitif olabilir.

Çok havuzlu projelerin dezavantajları olsa bile, bu şekilde birçok saygın çalışma yapılır - wayland ve boost akla geliyor. En iyi uygulamalarla ilgili bir uzlaşmanın henüz geliştiğine inanmıyorum ve bazı kararlar alınması gerekiyor. Çoklu depolarla (git-subtree, git-submodule ve diğerleri) çalışmak için araçlar halen geliştirilmekte ve denenmektedir. Benim tavsiyem deney yapmak ve pragmatik olmaktır.

Biz GitHub kullanırken, biz aslında bir repo birden fazla proje var ama emin bu projelerin / modüller düzgün modüler bir yapıya ki (biz -API ve -çekirdek kurallarını kullanmasını + Maven + statik ve çalışma zamanı kontrol ve hatta önyükleme için bir gün OSGi gidebileceğini) .

Ne tasarruf eder? Birden fazla projede küçük bir şeyi değiştiriyorsak, birden fazla Çekme İsteği düzenlemek zorunda değiliz. Konular ve Wiki merkezileştirildi vs.

Her bir modül / projeyi hala bağımsız ve bağımsız bir proje olarak görüyor ve bunları ayrı ayrı CI sunucumuza entegre ediyoruz.

Benim için, bir veya daha fazla havuz kullanmanın temel farkı, aşağıdaki soruların cevaplarıdır:

• Aynı ekip tarafından geliştirilen çoklu parçalar, aynı sürüm döngüsüne, aynı müşteriye mi sahip? Öyleyse bir depoyu bölmek için daha az neden var.
• Birden parçalardır yüksek birbirlerine bağımlı? Bu nedenle, bölünme modeli, denetleyici ve UI (farklı parçalar olsalar bile), birbirlerine olan yüksek bağımlılık nedeniyle pek mantıklı değildir. Ancak, 2 bölüm sadece birkaç yılda bir değiştirilen kararlı bir arayüz tarafından uygulanan küçük bir bağımlılığa sahipse, 2 bölümün 2 depoda bölünmesi akıllıca olacaktır.

Örnek olarak, bir Subversion deposunun "kalitesini" kontrol eden küçük bir uygulamam var (yalnızca müşteri). Komut satırından başlatılabilen ve Java 6 ile iyi çalışan bir çekirdek uygulama var. Fakat JavaFX'i Java 8'in bir parçası olarak kullanan bir kullanıcı arayüzü uygulamaya başladım. ikinci bir depo (ikinci bir derleme işlemiyle), farklı zamanlamalarla ...

Yukarıdaki cevapları seviyorum (oy kullandı), ancak bence gerçek hikaye değil. Bu yüzden depoları bölmek için argümanlar eklemek istedim. Yani gerçek cevap (ne zaman ayrılmalı) ortada bir yerde olabilir ...

O olabilir git-alt ağaç (bkz Atlassian blog , orta blog veya çekirdek bağlantısını sahip olduğunuz için uygun olacaktır). Bu nedenle, üst düzey projenizin her biri muhtemelen farklı sürümlerde bir alt ağacı kullanır.

Örneğinizden, depolar ne kadar bağımlı olduklarına göre ayarlanmalıdır. MicroServices ve Domain Driven Design tasarlama konusundaki tüm akıl yürütme burada geçerlidir: bazı durumlarda yinelenen kod kabul edilebilir, arayüzlerle çalışılabilir, gerçekten gerekmediğiniz sürece uyumluluğu bozmazsınız, vb.

Şimdi benim görüşüme göre bir kullanıcı arayüzü arka uçtan bağımsız olmalıdır. Bu nedenle, bir UI proje deposunun tipik olarak UI kodunu ve İstemci Denetleyicisini içermesi gerekir. Müşteri Kontrolörü Servis Kontrol Cihazlarına soyut bir şekilde bağlanacaktır. Bir hizmet istemcisini / hizmet soyutlamasını, hizmetten ayrı olarak sürümlendirilmiş olarak kullanacaklar, böylece bir hizmet müşteriyi / müşterileri bozmadan güncellenebilir (birkaç farklı müşteri olabilir).

Bu nedenle, bir servisin kendi deposu olması gerekir. Benim görüşüme göre, hizmet sadece tek bir gerçek-dışı iş mantığı mantığıdır. Bu nedenle, iş mantığı genellikle onu barındıran hizmet teknolojisinden ayrı olmalıdır. Öte yandan, depo uygulaması tipik olarak işletme mantığına o kadar sıkı bağlanır ki, bu aynı depoya entegre edilebilir. Fakat orada bile kilometreniz değişebilir.

Tabii ki, tüm UI'nin arka uçla aynı kaynaktan ve arka uç servislerinin tipik olarak yalnızca aynı müşteri tarafından kullanılabildiği, teknoloji açısından çok fazla değişiklik yapma ihtimali olmayan veya birden fazla desteyi destekleyen basit projeler daha fazla yararlanabilir sıkıca entegre havuzlar.

Bu durumda, muhtemelen sadece bir havuzda tam dikey olacak şekilde iyi olacak ve işlevsel alanlarınızın kendi depolarında uygun şekilde tek başlarına olmalarına odaklanmaya odaklanacaksınız. O zaman hala daha küçük havuzların ve diğer ek masrafların çoğu avantajına sahipsiniz.