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:

1. Setiap plugin akan memiliki repositori sendiri di Gitorious di dalam suatu proyek. Misalnya, portlet untuk menampilkan anak kucing akan memiliki kittens-portletrepositori di dalam liferay-portletsproyek.
2. Saat membuat plugin baru, buat di cabang bernama sesuai dengan versi Liferay (misalnya, lf5.2).
3. Setiap kali pembaruan dilakukan pada plugin, pembaruan disetujui dan digunakan dalam produksi, beri tag plugin dengan versi (misalnya lf5.2v1,, lf5.2v2dll.) *
4. Setiap kali sebuah plugin harus di-porting ke versi baru Liferay, kami membuat cabang versi terbaru (membuat, misalnya, cabang lf6.0).
5. Setelah dalam produksi, kepala cabang baru akan menerima tag seperti lf6.0v1.
6. Setiap kali kami harus menyesuaikan plugin dengan cara khusus klien, kami membuat cabang dengan nama klien (misalnya, kami akan membuat cabang lf5.2clientcorpuntuk klien kami "ClientCorp Inc.")

Ini adalah model yang tidak biasa: ia tidak memiliki masterdan 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-portletdan kemudian a kittens-lf6.0-portlet), masing-masing dengan mastercabang dan developcabang. Itu masterakan selalu siap untuk ditempatkan. (Atau bisa juga sebaliknya, masterdan stable, seperti yang disarankan oleh Steve Losh ).

Ini sangat sederhana, tetapi saya tidak suka sistem ini:

1. itu bisa menghasilkan banyak sekali repositori dalam sebuah proyek, membuat Gitorious sulit untuk dijelajahi.
2. Nama direktori proyek relevan. Jika seseorang mengkloning repositori ke kittens-lf6.0-portletdir dan menghasilkan WAR dengan semut (seperti biasa), nama WAR juga akan kittens-lf6.0-portlet. Versi lama portlet ini (dinamai kittens-portletmisalnya) akan dianggap portlet yang berbeda (dan mungkin hilang) di portal yang ditingkatkan. Sedikit perhatian bisa menghindarinya, tetapi saya lebih suka menghindarinya.
3. Versi berbeda dari plugin yang sama akan dipertahankan terpisah. Aku menghancurkan hatiku :(
4. 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:

1. Apa yang akan menjadi model terbaik? Lamaran ku? Model teman saya? Sistem Vincent Driessen yang sekarang tradisional?
2. Model percabangan apa lagi yang akan Anda sarankan?
3. 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 v1tetapi ternyata tag di git tidak dicakup dalam cabang - yaitu, saya tidak bisa memiliki 1 v1tag lf5.2dan satu lagi di lf6.0- jadi saya harus memberi nama cabang. Apakah benar BTW?

Jika saya membaca ini dengan benar, cabang pada dasarnya merupakan penyimpangan satu tembakan dari jalur utama pengembangan Anda, tidak pernah dimaksudkan untuk digabungkan kembali ke jalur utama dan kemajuan di jalur utama tidak pernah diterapkan ke cabang-cabang ini. Satu-satunya penyimpangan adalah perbaikan bug yang sesuai dengan versi cabang didasarkan pada kebutuhan untuk diterapkan ke cabang.

Jawabannya sekarang berporos pada alur kerja Anda sehari-hari, jumlah pengembang yang bekerja pada satu cabang atau jumlah perubahan apa pun adalah red herring. Saya melihat kebutuhan utama Anda ingin mengetahui cabang mana yang mendapatkan pembaruan perbaikan bug dari perubahan cabang utama dan untuk ini saya pikir repositori gabungan dengan cabang akan lebih efisien karena semuanya ada di satu tempat. Jika tidak pernah diperlukan penyerbukan silang maka repositori yang terpisah akan menegakkan itu, tetapi skenario itu tidak sesuai dengan kenyataan proyek Anda seperti yang saya mengerti.

Model Driessen akan bekerja dengan baik jika proyek Anda perlu menggabungkan cabang kembali ke jalur utama pengembangan, tetapi Anda tidak membutuhkannya. Meski begitu saya pikir ada manfaat dalam mempertahankan konsep InDevelopment dan StableRelease jika Anda bekerja pada produk yang hidup.

Jadi untuk meringkas saya pikir bahwa proyek Anda akan bekerja dengan baik dengan model percabangan Anda ditambah sedikit Driessen untuk jalur utama Anda. Jarak tempuh Anda dapat bervariasi; Saya selalu bekerja dengan cabang "pending release" yang berubah menjadi cabang "live" dan "release berikutnya" terpisah yang semuanya membutuhkan penyerbukan silang untuk perbaikan dan perubahan di berbagai titik agar persepsi saya bias.

Apa yang mengejutkan saya adalah fakta bahwa setiap portlet memiliki repositori sendiri (tetapi kisah Anda mungkin tidak lengkap). Secara pribadi saya akan membuat repositori per proyek. Proyek sering memiliki beberapa portlet dan semuanya dibangun dalam versi yang sama terhadap versi yang sama dari Liferay. Setiap proyek dapat menjadi duplikat dari proyek yang ada yang dibangun melawan versi Liferay yang berbeda tetapi saya hanya akan membagi produk jika perbedaannya terlalu besar. Jika sebuah bangunan bekerja melawan Liferay 5.1 dan 5.2 saya tidak akan membagi proyek. Saya akan menggunakan scripting atau Maven (atau keduanya) untuk membuat semuanya berfungsi. Saya akan menggunakan Wiki (atau Trello) untuk manajemen masing-masing produk dan dengan versi apa Liferay dapat dibangun.

Ngomong-ngomong: Saya seorang programmer Java, spesialis Maven, Build spesialis dan memiliki pengalaman dengan Liferay dan server portal lainnya (IBM WebSphere dan Glassfish).

Tapi ini hanya € 0,02 saya.