Birden çok projeye sahip sunucu için GIT depo düzeni

Subversion kurulum şeklimde sevdiğim şeylerden biri, birden fazla projeye sahip tek bir ana depoya sahip olabilmem. Bir proje üzerinde çalışmak istediğimde, sadece o projeye göz atabilirim. Bunun gibi

\main
    \ProductA
    \ProductB
    \Shared

sonra

svn checkout http://.../main/ProductA

Git'e yeni bir kullanıcı olarak, belirli bir iş akışını taahhüt etmeden önce alandaki en iyi uygulamaları araştırmak istiyorum. Şimdiye kadar okuduğum kadarıyla git, her şeyi proje ağacının kökünde tek bir .git klasöründe saklar. Böylece iki şeyden birini yapabilirim.

1. Her Ürün için ayrı bir proje oluşturun.
2. Tek bir büyük proje oluşturun ve ürünleri alt klasörlerde depolayın.

Ürünler arasında bağımlılıklar var, bu yüzden tek büyük proje uygun görünüyor. Tüm geliştiricilerin kodlarını paylaşabileceği bir sunucu kullanacağız. Bunu zaten SSH & HTTP ve sevdiğim kısım üzerinde çalıştırıyorum. Bununla birlikte, SVN'deki depolar zaten çok GB boyutundadır, bu nedenle her makinede tüm depoyu sürüklemek kötü bir fikir gibi görünüyor - özellikle de aşırı ağ bant genişliği için faturalandırıldığımız için.

Linux çekirdeği proje depolarının eşit büyüklükte olduğunu hayal ediyorum, bu yüzden bunu Git ile halletmenin uygun bir yolu olmalı ama henüz çözemedim.

Çok büyük çok projeli havuzlarla çalışmak için herhangi bir kılavuz veya en iyi uygulama var mı?

Kılavuz, Git sınırları açısından basittir :

• proje başına bir depo
• alt modülleri olan bir ana proje .

Buradaki fikir, her şeyi dev bir git repo'da depolamak değil , ana proje olarak küçük bir repo inşa etmektir; bu, her biri bir projeyi veya kendi ortak bileşenini temsil eden diğer depoların doğru taahhütlerini referans alır.

OP Paul Alexander comments :

Bu, yıkımın sağladığı "dışsal" desteğe benzer.
Bunu denedik ve projeler birbirine bağlı olarak eşzamanlı olarak geliştirildiğinden harici sürüm referanslarını sürekli olarak güncellemenin son derece zahmetli olduğunu gördük. Başka bir seçenek var mı?

@Paul: evet, sürümü ana projeden güncellemek yerine, ya:

• alt projelerinizi doğrudan ana proje içinden geliştirin (" Alt modüllerin Gerçek Doğası " bölümünde açıklandığı gibi ),
• veya bir alt repoda originbaşka bir yerde geliştirilen aynı alt repoya referansta bulunuyorsunuz : oradan başka yerde yapılan değişiklikleri o alt depodan çekmeniz yeterli.

Her iki durumda da, yeni konfigürasyonu kaydetmek için ana projeyi taahhüt etmeyi unutmamalısınız. Burada güncellenecek "harici" mülk yok. Tüm süreç çok daha doğal.

Dürüst olmak gerekirse, bu kulağa gerçek bir acı gibi geliyor ve geliştiricilerin her seferinde manuel olarak bir şeyler yapmasını gerektiren herhangi bir şey, düzenli bir hata kaynağı ve bakım olacak.
Sanırım bunu süper projedeki bazı komut dosyalarıyla otomatikleştirmeye bakacağım.

Yanıtladım:

Dürüst olmak gerekirse, en son Git 1.7.1 sürümüne kadar haklıydınız .
git diffve git statusher ikisi de ana projeden yürütülse bile alt modül durumlarını dikkate almayı öğrendi.
Alt modül modifikasyonunu kaçıramazsınız.

Söyleniyor ki:

• alt modüller, SVN harici modüllerinden farklıdır: " Git alt modülleri neden svn harici modülleri ile uyumsuz? "
• alt modülleri yönetmek zor olabilir: bkz. " git alt modülü tam olarak nasıl çalışır? ".

GitSlave, birkaç bağımsız depoyu tek olarak yönetmenize izin verir. Her depo, normal git komutlarıyla değiştirilebilir, gitslave ise ek olarak tüm depolar üzerinde bir komut çalıştırmanıza izin verir.

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Proje başına repo, bileşenleştirme ve Maven gibi araçlarla basitleştirilmiş yapılarda avantajlara sahiptir. Proje başına repo, geliştiricinin değiştirdiği şeyin kapsamını sınırlayarak koruma sağlar - hatalı çöp işlemleri açısından.