Catatan: Pertanyaan saya terfokus pada masalah khusus saya (yang melibatkan Liferay) tetapi saya harap ini dapat bermanfaat bagi siapa saja yang perlu mempertahankan berbagai versi proyek yang sama dengan git.
Saya bekerja di sebuah perusahaan yang menulis banyak plugin untuk Liferay Portal . Plugin ini (portlet, tema, dll.) Biasanya dapat digunakan kembali dan, tentu saja, harus diperbarui untuk versi portal yang baru.
Namun, biasanya harus bermigrasi, katakanlah, portlet ke versi baru Liferay dan untuk mempertahankan versi sebelumnya. Juga, seringkali kita harus membuat penyesuaian yang sangat spesifik untuk beberapa klien, yang tidak masuk akal untuk ditambahkan ke "versi utama".
Syarat-syarat ini menyulitkan pekerjaan kami tetapi, untungnya, kami dapat mengasumsikan beberapa penyederhanaan. Misalnya, plugin sering diperbarui oleh hanya satu programmer pada satu waktu. Sangat jarang memiliki dua atau lebih fitur yang ditambahkan ke sebuah plugin secara bersamaan.
Sekarang, kami bermigrasi ke Gitorious . Kami mencoba menyusun model percabangan untuk skenario seperti itu.
Model saya
Apa yang saya usulkan adalah:
- Setiap plugin akan memiliki repositori sendiri di Gitorious di dalam suatu proyek. Misalnya, portlet untuk menampilkan anak kucing akan memiliki
kittens-portlet
repositori di dalamliferay-portlets
proyek. - Saat membuat plugin baru, buat di cabang bernama sesuai dengan versi Liferay (misalnya,
lf5.2
). - Setiap kali pembaruan dilakukan pada plugin, pembaruan disetujui dan digunakan dalam produksi, beri tag plugin dengan versi (misalnya
lf5.2v1
,,lf5.2v2
dll.) * - Setiap kali sebuah plugin harus di-porting ke versi baru Liferay, kami membuat cabang versi terbaru (membuat, misalnya, cabang
lf6.0
). - Setelah dalam produksi, kepala cabang baru akan menerima tag seperti
lf6.0v1
. - Setiap kali kami harus menyesuaikan plugin dengan cara khusus klien, kami membuat cabang dengan nama klien (misalnya, kami akan membuat cabang
lf5.2clientcorp
untuk klien kami "ClientCorp Inc.")
Ini adalah model yang tidak biasa: ia tidak memiliki master
dan banyak cabang yang tidak bergabung. Ini adalah bagaimana saya kira repositori dengan model seperti itu akan terlihat seperti:
Seorang teman menemukan sistem ini agak rumit dan rawan kesalahan. Dia menyarankan model Vincent Driessen yang sangat baik dan populer , yang menurut saya masih lebih sulit untuk dikelola dan menuntut disiplin. Itu hebat (dan diuji!) Tentu saja tetapi tampaknya terlalu rumit untuk situasi kita.
Model teman saya
Lalu ia menyarankan model lain: kami akan memiliki repositori untuk setiap plugin dalam versi Liferay (jadi kami akan mulai membuat kittens-lf5.2-portlet
dan kemudian a kittens-lf6.0-portlet
), masing-masing dengan master
cabang dan develop
cabang. Itu master
akan selalu siap untuk ditempatkan. (Atau bisa juga sebaliknya, master
dan stable
, seperti yang disarankan oleh Steve Losh ).
Ini sangat sederhana, tetapi saya tidak suka sistem ini:
- itu bisa menghasilkan banyak sekali repositori dalam sebuah proyek, membuat Gitorious sulit untuk dijelajahi.
- Nama direktori proyek relevan. Jika seseorang mengkloning repositori ke
kittens-lf6.0-portlet
dir dan menghasilkan WAR dengan semut (seperti biasa), nama WAR juga akankittens-lf6.0-portlet
. Versi lama portlet ini (dinamaikittens-portlet
misalnya) akan dianggap portlet yang berbeda (dan mungkin hilang) di portal yang ditingkatkan. Sedikit perhatian bisa menghindarinya, tetapi saya lebih suka menghindarinya. - Versi berbeda dari plugin yang sama akan dipertahankan terpisah. Aku menghancurkan hatiku :(
kittens-lf6.0-portlet
adalah nama jelek untuk repositori, kurasa.
Saya menduga dua poin terakhir - yang merupakan dua yang lebih subyektif juga - adalah alasan utama keengganan saya. Meskipun demikian, keempat keberatan tersebut tetap berlaku.
OTOH, proposal saya sendiri terasa aneh bagi diri saya dan saya bertanya-tanya apakah ada bug tersembunyi di dalamnya. OT3rdH git sangat kuat dan fleksibel sehingga saya pikir saya tidak perlu malu menjelajahi kemungkinannya.
Jadi, saya bertanya:
- Apa yang akan menjadi model terbaik? Lamaran ku? Model teman saya? Sistem Vincent Driessen yang sekarang tradisional?
- Model percabangan apa lagi yang akan Anda sarankan?
- Jika Anda berpikir model saya buruk, mengapa menurut Anda begitu? Saya ingin belajar apa saja kelemahan dan titik buta.
* Sebenarnya, saya lebih suka untuk menandai komit dengan versi seperti v1
tetapi ternyata tag di git tidak dicakup dalam cabang - yaitu, saya tidak bisa memiliki 1 v1
tag lf5.2
dan satu lagi di lf6.0
- jadi saya harus memberi nama cabang. Apakah benar BTW?