Christopher melakukan pekerjaan yang sangat baik untuk menyebutkan kekurangan dari model satu proyek per repositori. Saya ingin membahas beberapa alasan mengapa Anda mungkin mempertimbangkan pendekatan multi-repositori. Dalam banyak lingkungan tempat saya bekerja, pendekatan multi-repositori telah menjadi solusi yang masuk akal, tetapi keputusan tentang berapa banyak repositori yang harus dimiliki, dan di mana membuat pemotongan tidak selalu merupakan cara yang mudah untuk dibuat.
Dalam posisi saya saat ini, saya memigrasi repositori CVS repositori tunggal dengan lebih dari sepuluh tahun sejarah ke sejumlah repositori git. Sejak keputusan awal itu, jumlah repositori telah bertambah (melalui aksi-aksi tim lain), sampai pada titik di mana saya menduga kita memiliki lebih banyak daripada yang akan optimal. Beberapa karyawan baru menyarankan penggabungan repositori tetapi saya telah membantahnya. Proyek Wayland memiliki pengalaman serupa. Dalam sebuah ceramah yang saya lihat baru-baru ini, mereka, pada satu titik, memiliki lebih dari 200 repositori git, yang mana pemimpinnya meminta maaf. Melihat situs web mereka , saya melihat sekarang mereka berada di 5, yang tampaknya masuk akal. Penting untuk mengamati bahwa bergabung dan membagi repositori adalah tugas yang dapat dikelola, dan boleh-boleh saja bereksperimen (sesuai alasan).
Jadi kapan Anda mungkin menginginkan beberapa repositori?
- Repositori tunggal akan terlalu besar untuk menjadi efisien.
- Gudang Anda secara longgar digabungkan, atau dipisahkan.
- Pengembang biasanya hanya membutuhkan satu, atau sebagian kecil dari repositori Anda untuk berkembang.
- Anda biasanya ingin mengembangkan repositori secara independen, dan hanya perlu menyinkronkannya sesekali.
- Anda ingin mendorong lebih banyak modularitas.
- Tim yang berbeda bekerja pada repositori yang berbeda.
Poin 2 dan 3 hanya signifikan jika poin 1 berlaku. Dengan membagi repositori kami, saya secara signifikan mengurangi keterlambatan yang diderita oleh kolega di luar kantor kami, mengurangi konsumsi disk, dan meningkatkan lalu lintas jaringan.
4 dan 5 lebih halus. Ketika Anda membagi repo katakanlah klien dan server, ini membuatnya lebih mahal untuk mengoordinasikan perubahan antara klien dan kode server. Ini bisa menjadi positif, karena mendorong antarmuka dipisahkan antara keduanya.
Bahkan dengan kerugian dari proyek multi-repositori, banyak pekerjaan terhormat dilakukan seperti itu - wayland dan dorongan muncul di benak. Saya tidak percaya konsensus mengenai praktik terbaik telah berkembang, dan beberapa penilaian diperlukan. Alat untuk bekerja dengan banyak repositori (git-subtree, git-submodule dan lainnya) masih sedang dikembangkan dan dicoba. Saran saya adalah bereksperimen dan bersikap pragmatis.