Aynı genel projenin parçası olan birden fazla Git deposunu gruplama

Diyelim ki birden fazla bileşeni olan bir projem var: bir sunucu bileşeni, bir web uygulaması bileşeni, bir iOS bileşeni, bir Android bileşeni, vb. Bu bileşenlerin hepsi ayrı kod tabanlarıdır, ancak gevşek bir şekilde bağlanmıştır (örn. Sunucuda bir değişiklik) kodu diğer tüm bileşenlerde de değişiklik yapılmasını gerektirebilir)

Git'te bu projeyi düzenlemenin en etkili yolu nedir? Hepsini bir depoya koyarsanız, her zaman en son sürümlere sahip olursunuz, ancak diğerlerini değil, bir bileşeni değiştirmeye başladığınızda işler oldukça dağınık hale gelir.

Öte yandan, her bir bileşeni ayrı bir havuz olarak yaparsanız, uygulamanın 2.0 sürümünün sunucu bileşeninin 1.5 sürümünü gerektirdiğini bilmeniz için bu depoları nasıl "bağlayabilirsiniz"?

Git'te güncel, benioku dosyalarını (veya görmediğim daha iyi bir çözümü) tutmanın dışında, birden çok ilgili depoyu daha etkin bir şekilde yönetmenin bir özelliği var mı?

Alt projeler, dağıtılmış sürüm kontrol sistemlerinin (DVCS) dağıtıldığı yerdir, çözülmezse, kesinlikle biraz sakat hale gelir.

Git alt modüllerinin ve Mercurial alt birikimlerinin her ikisi de alt proje desteğini hedefler. Her ikisinde de serbest bırakma geliştirildi (Mercurial'ın eski "bu özelliği var, ancak muhtemelen kullanmamalısınız" uyarısı artık ön ve merkez değildir.)

Yine de, çoklu proje depoları, herkesin kullandığı bir özellikten ziyade özel bir kullanım durumudur. Belgelerde çok sayıda uyarı ve "bu projelerin nasıl kullanılacağı" talimatları, "proje projelerinin" yönetilmesinin, meta yönetimin doğrudan, tek seviyeli proje yönetiminden biraz farklı ama gerçekten farklı olduğu iki seviyeli bir endişe olduğunu açıkça ortaya koyuyor. Sonuç olarak, orada çok daha az deneyim var. Ve "git submodüllerini kullanma!" ve "cıva subreposlarından kaçının!" yorumlar ve blog gönderileri.

Subrepos ile kendi deneyimim karışıktı. İşe yaradı ... ama aynı zamanda can sıkıcıydı. Alt projeler fikrini seviyorum, ancak pratikte daha büyük (hepsi bir arada) depolar veya refakatçi kardeş projeleri - daha kolay (daha az zarif olsa da) engellenecek alternatifler buluyorum. Subreposların ana akım olduğunu ve bir acı olmadığını dört gözle bekliyorum, ancak henüz deneyimlemedim.

Bu, alt modülleri / alt depoları yönetmenin sizin için işe yaramayacağı anlamına gelmez, ancak dikkatli bir şekilde yapılması gereken bir şeydir ve kesinlikle bazı önceden deney ve planlama.

Git'e odaklandığınız göz önüne alındığında, bazılarının git alt modüllerine daha iyi bir alternatif olduğu Git alt ağaçlarını da keşfetmelisiniz .

C # kullanıyorsanız, NuGet'i kullanabilirsiniz.

Her bileşeni bir kütüphane haline getirin ve kendi havuzunda saklayın. Anlamsal sürümlemeye göre sürümlendirdiğiniz temel bileşenlerin sürümlerini alın.

Son olarak, oluşturucunuzu kütüphaneleri NuGet paketlerine paketleyin ve bu NuGet paketlerini ön uç bileşenler (iOS, Android) projelerinde tüketin.

Aynı temel yaklaşım (sürüm ve paket bağımlılıkları) diğer dillerde de kullanılabilir, ancak bu kadar uygun olmayabilir.

Git Alt Modüllerini kullanmanızı tavsiye etmem. Teoride bu tür konular için kullanılabilse de, değerinden daha büyük bir güçlük hissediyorum.

Benim düşünceme göre, bu aslında ne kadar bağlı olduklarına bağlı olacaktır. git bisectBir regresyonu izlerken otomatik olarak çalışabilmek gerçekten güzel , ancak her taahhüt diğer bağımlılıklarınızın farklı bir sürümüne bağlıysa bunu yapmak zor olacaktır.

İki olası seçenek, alt modüllere sahip bir havuz veya yerinde iyi sürüm oluşturma uygulamaları olan birden çok havuz olacaktır.

Uygulamanın 2.0 sürümünün sunucu bileşeninin 1.5 sürümünü gerektirdiğini bilmeniz için bu depoları nasıl "bağlayabilirsiniz"?

Bu genellikle Git'in değil, bazı bağımlılık yönetimi çerçevesinin (ör. Gradle, Maven) alanıdır.