Büyük proje düzeni: birden fazla alt projeye yeni özellik ekleme

Sürüm kontrol yönetim sistemi ile birçok bileşeni olan büyük bir projenin nasıl yönetileceğini bilmek istiyorum.

Mevcut projemde 4 ana bölüm var.

1. ağ
2. Sunucu
3. Yönetici konsolu
4. Platform.

Web ve sunucu bölümü yazdığım 2 kütüphaneyi kullanıyor. Toplamda 5 git deposu ve 1 cıva deposu bulunmaktadır. Proje derleme betiği Platform deposundadır. Tüm bina sürecini otomatikleştirir.

Sorun, etkilenen repo her biri için şube oluşturmak zorunda birden çok bileşeni etkileyen yeni bir özellik eklemek olmasıdır. Özelliği uygulayın. Birleştir. Bağırsak hissim "bir şeyler yanlış".

Öyleyse tek bir repo oluşturmalı ve tüm bileşenleri oraya koymalıyım? Bence bu durumda dallanma daha kolay olacak. Yoksa şu an yaptığım şeyi yapıyorum. Bu durumda, her depoda şube oluşturma sorununu nasıl çözerim?

Açıkladığınız durumda, birden fazla depoya sahip olmanın herhangi bir avantajından yararlanmıyorsunuz, ancak bir maliyetiniz var: bir deponun eski bir sürümüne geri dönemezsiniz ve sisteminizin çalışmaya devam edeceğine dair güveniniz yoktur. Bunun nedeni, kodunuzun depolar arasında sıkıca bağlı olmasıdır. Geri dönme yeteneğine güven, kaynak kontrolünün temel faydalarından biri olduğundan, içinde olmak istediğiniz durum bu değildir.

Çözüm, veri havuzu yapınızı içindeki kodun birleşimine göre tanımlamaktır: A proje bileşeni, B proje bileşeniyle yalnızca kararlı arabirimleri paylaşıyorsa, ayrı depolara yerleştirilebilir. Aksi takdirde, aynı depoya birlikte yerleştirilmelidirler. Daha ayrıntılı bir havuz düzeni, daha iyi bir faktörlü sistem mimarisini yansıtacaktır.

Depolarınızın her biri bağımsız projeler veya kütüphaneler ise, projeler arasında kesişen yeni özellikler eklerken her bir repoda özellik dalları oluşturmaya ihtiyaç duymanın doğasında yanlış bir şey olmadığını söyleyebilirim. Bağımsız olarak, her biri bağımsız olarak sürümlendirilebilir ve eski API'ları kullanımdan kaldırabilirsiniz.

Ancak sizin durumunuzda, veri havuzlarınız kodunuzu etkili bir şekilde gruplandırmıyor olabilir. Bir depodaki kod değişiklikleri, başkalarında değişiklik yapılmasını gerektiriyorsa (kullanımdan kaldırılma), ya bağlantınız çok sıkıdır veya depolar yeniden düzenlenmelidir.

Tüm depolar gerçekten aynı projenin bir parçasıysa (tek başlarına duramazlar), belki de sadece 1 havuzunuz olmalıdır. (Veya belki 2: ana proje ve genel / standart işlevsellik için bir proje.)