Tata letak repositori GIT untuk server dengan banyak proyek

Salah satu hal yang saya suka tentang cara saya mengatur Subversion adalah saya dapat memiliki satu repositori utama dengan banyak proyek. Ketika saya ingin mengerjakan sebuah proyek, saya dapat memeriksa proyek itu saja. Seperti ini

\main
    \ProductA
    \ProductB
    \Shared

kemudian

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

Sebagai pengguna baru di git, saya ingin menjelajahi sedikit praktik terbaik di lapangan sebelum melakukan alur kerja tertentu. Dari apa yang saya baca sejauh ini, git menyimpan semuanya dalam satu folder .git di root pohon proyek. Jadi saya bisa melakukan satu dari dua hal.

1. Siapkan proyek terpisah untuk setiap Produk.
2. Siapkan satu proyek besar dan simpan produk dalam sub folder.

Ada ketergantungan di antara produk-produk tersebut, jadi satu proyek besar tampaknya cocok. Kami akan menggunakan server tempat semua pengembang dapat membagikan kode mereka. Saya sudah mendapatkan ini berfungsi melalui SSH & HTTP dan bagian yang saya suka. Namun, repositori di SVN sudah berukuran banyak GB, jadi menyeret seluruh repositori pada setiap mesin sepertinya ide yang buruk - terutama karena kami ditagih untuk bandwidth jaringan yang berlebihan.

Saya membayangkan bahwa repositori proyek kernel Linux sama besarnya sehingga harus ada cara yang tepat untuk menangani ini dengan Git tetapi saya belum menemukannya.

Apakah ada pedoman atau praktik terbaik untuk bekerja dengan repositori multi-proyek yang sangat besar?

Panduannya sederhana, terkait dengan batas Git :

• satu repo per proyek
• proyek utama dengan submodul .

Idenya bukan untuk menyimpan semuanya dalam satu repo git raksasa, tetapi membangun repo kecil sebagai proyek utama, yang akan merujuk pada komitmen yang tepat dari repo lain, masing-masing mewakili proyek atau komponen umum miliknya sendiri.

The OP Paul Alexander komentar :

Ini terdengar mirip dengan dukungan "eksternal" yang disediakan oleh subversi.
Kami mencoba ini dan merasa sangat merepotkan untuk terus memperbarui referensi versi eksternal karena proyek dikembangkan secara bersamaan dengan ketergantungan satu sama lain. Apakah ada pilihan lain ??

@Paul: ya, alih-alih memperbarui versi dari proyek utama, Anda juga:

• mengembangkan subproyek Anda langsung dari dalam proyek utama (seperti yang dijelaskan dalam " Sifat asli submodul "),
• atau Anda merujuk dalam sub-repo originke sub-repo yang sama yang sedang dikembangkan di tempat lain: dari sana Anda hanya perlu menarik dari sub-repo itu perubahan yang dibuat di tempat lain.

Dalam kedua kasus tersebut, Anda tidak boleh lupa untuk menjalankan proyek utama, untuk merekam konfigurasi baru. Tidak ada properti "eksternal" untuk diperbarui di sini. Semua proses jauh lebih alami.

Sejujurnya, ini terdengar seperti sakit yang nyata dan apa pun yang mengharuskan pengembang untuk melakukan sesuatu secara manual setiap kali hanya akan menjadi sumber bug dan pemeliharaan rutin.
Saya kira saya akan melihat ke dalam otomatisasi ini dengan beberapa skrip dalam proyek super.

Saya membalas:

Sejujurnya, Anda mungkin benar ... sampai Git rilis 1.7.1 terbaru .
git diffdan git statuskeduanya belajar untuk memperhitungkan keadaan submodul bahkan jika dijalankan dari proyek utama.
Anda tidak dapat melewatkan modifikasi submodul.

Yang telah dibilang:

• submodul berbeda dari SVN eksternal: lihat " Mengapa submodul git tidak kompatibel dengan svn eksternal? "
• mengelola submodul bisa jadi rumit: lihat " Bagaimana tepatnya cara kerja git submodule? ".

GitSlave memungkinkan Anda mengelola beberapa repositori independen sebagai satu. Setiap repo dapat dimanipulasi dengan perintah git biasa, sementara gitslave memungkinkan Anda untuk menjalankan perintah tambahan di semua repo.

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

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

Repo-per-project memiliki kelebihan dengan komponenisasi dan build yang disederhanakan dengan alat seperti Maven. Repo-per-project menambahkan perlindungan dengan membatasi cakupan dari apa yang diubah oleh pengembang - dalam hal tindakan sampah yang salah.