Pertanyaan Apakah mungkin menggunakan model git-flow dengan Subversion?


Kami menggunakan Subversion dan selain dari beberapa individu seperti saya sendiri ada sedikit atau tidak ada pengalaman dengan bercabang dan bergabung dalam Subversion. Pengalaman Subversi saya terbatas pada cabang fitur sederhana di mana gabungan dan konflik pohon, meskipun tidak terlalu jarang, tidak terlalu sulit untuk diselesaikan.

Karena itu, saya membantu mengelola proyek di mana komitmen kami saat ini terhadap metode trunk tidak dapat dipertahankan untuk kebutuhan kami. Saya memperkenalkan fitur percabangan dan bergabung dengan tim lokal saya dan kami memiliki beberapa keberhasilan. Namun pencabangan fitur sederhana masih belum dapat menjawab semua pertanyaan kami seperti:

  1. Bagaimana kita mengembangkan kode secara paralel untuk rilis ini dan rilis selanjutnya?
  2. Kode apa yang dianggap stabil?
  3. Apa (dalam pengembangan) kode yang akan masuk ke rilis berikutnya?
  4. Apa (dalam pengembangan) kode yang akan menjadi rilis berikutnya?
  5. Versi kode apa yang merupakan lingkungan Uji, Penerimaan, atau Produksi kami?
  6. Bagaimana kita mengintegrasikan aktivitas pengembangan bersamaan dengan rilis stabil yang dikenal untuk mengurangi pengenalan bug dan pekerjaan yang tidak lengkap?
  7. Bagaimana kami menyediakan perbaikan panas untuk kode yang dirilis?
  8. Bagaimana kita tahu, dari kontrol sumber kami, kegiatan pengembangan apa yang sedang berlangsung saat ini?
  9. Bagaimana kita bereksperimen atau R & D tanpa mengganggu basis kode saat ini sambil memanfaatkan?

Tampaknya aliran git seperti yang didefinisikan di sini akan sangat membantu untuk menjawab banyak pertanyaan ini. Saya bereksperimen dengan metode ini di Mercurial dan sepertinya itu mungkin untuk menerapkan metode ini di sana juga. Sayangnya, bermigrasi ke DVCS adalah dari meja pada saat ini.

Namun, usaha singkat saya untuk meniru metode ini di Subversion gagal dengan banyak penggabungan dan konflik pohon. Opsi gabungan dan kasus tepi banyak dan membingungkan.

Dapat Subversion digunakan untuk menerapkan aliran git dan jika demikian apa tingkat rasa sakitnya?


32
2017-11-12 14:39


asal


Jawaban:


Kami menggunakan apa yang disebut tidak stabil metode pengembangan batang. Ini adalah metodologi pengembangan yang diciptakan Pencipta Subversi ketika mereka menciptakan Subversion. Ini sederhana dan mudah diterapkan.

  • Anda melakukan semua pengembangan Anda bagasi. Dengan demikian disebut tidak stabil bagasi.
  • Ketika Anda mendekati rilis, Anda membuat cabang untuk rilis itu. Idenya adalah untuk membuat cabang cukup lama untuk menjaga perkembangan paralel sesingkat mungkin, tetapi tidak demikian nanti bahwa beberapa pengembang tidak dapat melakukan pekerjaan mereka karena mereka tidak lagi perlu bekerja pada rilis saat ini, tetapi harus mulai bekerja pada rilisan berikutnya. Di Agile, ini biasanya dilakukan tepat sebelum firming berlari cepat. Ini biasanya dilakukan ketika rilis fitur selesai, dan sekarang Anda hanya memperbaiki bug.
  • Pelepasan berlangsung dari cabang. Anda menandai cabang. Jika ada tambalan yang dibutuhkan, mereka selesai dari cabang.

Berikut ini ide cara kerjanya:

  • Bayangkan Anda sedang mengerjakan Release 1.2. Anda sedang mengerjakan batang pohon. Sekarang, Anda semakin dekat dengan waktu ketika Release 1.2 akan dirilis, dan tidak ada cukup pekerjaan di Release 1.2 untuk membuat pengembang Anda sibuk. Anda membuat 1,2 cabang untuk rilis Anda.
  • Sekarang, orang-orang yang masih bekerja di Release 1.2 beralih ke cabang Release 1.2. Sementara itu, pengembang yang bekerja di 1.3 tetap aktif bagasi.
  • Anda sekarang siap untuk Release 1.2. Anda memberi Rilis 1,2 tepat di cabang. Cabang tidak digabung kembali ke dalam bagasi. Batangnya untuk Rilis 1.3.
  • Bug dilaporkan, dan Anda ingin memperbaikinya dalam Release 1.2.1. Anda terus bekerja dari 1,2 cabang. Tidak ada cabang baru yang diperlukan untuk 1.2.1. (Anda dapat mengunci cabang di antara rilis untuk menyimpannya murni.
  • Ketika Anda akan melakukan Release 1.3, Anda mengulangi proses - cabang 1.3 dan bekerja untuk 1.4 berlanjut di bagasi.

Akan ada beberapa penggabungan. Ini terutama menggabungkan cacat tetap pada cabang rilis kembali ke bagasi. Ada tiga opsi untuk melakukan ini:

  • Setelah Anda melakukan rilis, Anda menggabungkan enmass semua perubahan pada cabang kembali ke trunk. Ada sedikit sekali pelacakan. Anda hanya berasumsi bahwa semua perbaikan bug di cabang juga berlaku untuk bagasi.
  • Anda menggunakan sistem pelacakan yang memahami masalah dapat hidup di lebih dari satu rilis. Dalam hal ini, Anda cukup menandai bug yang ditemukan di cabang ke batang juga. Anda dapat memilih perubahan yang berlaku untuk bagasi berkat sistem pelacakan masalah Anda.
  • Beberapa situs tidak tergabung. Mereka juga melacak melalui perubahan sistem pelacakan cacat yang perlu diterapkan pada bagasi yang diterapkan pada cabang, dan cukup terapkan kembali. Mereka mungkin menyalin perubahan dari cabang ke batang, tetapi mereka tidak pernah melakukan penggabungan formal. Namun, setelah Anda melakukan ini, Anda tidak dapat menggabungkan (kecuali Anda bergabung dengan --record-only bendera).

Anda, tentu saja, menyadari bahwa metode ini membutuhkan sesuatu yang disebut perencanaan. Anda harus memprioritaskan pekerjaan Anda, sehingga para pengembang melakukan pekerjaan untuk rilis yang akan datang sebelum mengerjakan rilis mendatang. Anda hanya bercabang setelah Anda tidak lagi memiliki cukup pekerjaan pada rilis yang akan datang untuk membuat semua pengembang Anda sibuk.

Anda dapat menerapkan alur kerja Git standar yang menggunakan pengembangan cabang pengembangan terpisah untuk setiap pengembang atau masalah, dan kemudian pengiriman perubahan itu ke bagasi. Ini akan membutuhkan banyak cabang, satu untuk setiap pengembang / fitur.

Anda pertama kali menggabungkan dari batang ke cabang ke rebase kode Anda. Setelah Anda melakukan rebase, Anda bergabung dari cabang kembali ke batang menggunakan --reintegrate beralih. Pra-1.6, Anda seharusnya menghapus cabang dan membuatnya lagi --reintegrate semacam pelacakan penggabungan kacau. Namun, ini telah diperbaiki di Rilis 1.6.x dan lebih tinggi.


28
2017-11-12 19:29



Itu pertanyaan besar. Saya hanya memiliki ide bagaimana memecahkan beberapa masalah:

  1. Saya tidak berpikir ini dapat dengan mudah diselesaikan tanpa menggunakan banyak cabang. Tidak yakin apakah ini dapat dengan mudah dipecahkan dengan menggunakan GIT. Cabang fitur sangat membantu dalam memecahkan masalah ini, tetapi secara umum Anda mungkin harus mencoba berkonsentrasi pada fitur untuk rilis berikutnya saja.
  2. trunk- Saya menganggap itu master cabang.
  3. Saya akan mengatakan itu development cabang adalah kode untuk rilis berikutnya
  4. Tampaknya sulit tanpa menggunakan banyak cabang, tidak tahu bagaimana memecahkannya dengan benar.
  5. Anda bisa menggunakan cabang atau mencatat nomor revisi dalam TEST dan ACC. PROD harus dimasukkan ke dalam tag kurasa.
  6. Saya akan mengatakan menggunakan tes regresi otomatis dan integrasi berkelanjutan. Juga menggunakan ulasan rekan dapat membantu di sini, paling baik Anda menggunakan semacam alat untuk menandai file sebagai Ulasan. Dengan cara itu Anda dapat memastikan bahwa Anda hanya menggabungkan file yang telah ditinjau. Mungkin juga menarik untuk mengikat pesan commit Anda ke bugtracker Anda, untuk secara otomatis mencari tahu file mana yang telah disentuh sehubungan dengan masalah tersebut, dan kemudian pastikan semua masalah benar-benar tertutup untuk file yang ingin Anda gabungkan. Ini adalah tugas yang tidak sepele, terutama jika Anda berpikir untuk menggabungkan hanya bagian-bagian dari cabang. Dengan demikian, semacam, melakukan penggabungan fitur.
  7. Gunakan tag untuk rilis. Anda dapat memeriksanya seperti cabang dan menambahkan tambalan jika perlu
  8. Buat daftar semua svn commit untuk seluruh repositori pada satu halaman (misalnya gambaran trac / redmine / jira)
  9. Gunakan salinan lokal saya takut / atau cabang lagi. Atau membuat R & D menggunakan git svn secara lokal untuk penelitian.

Beberapa masalah ini dapat, setidaknya sebagian, diselesaikan dengan menggunakan git svn. Dengan menggunakannya, Anda dapat, misalnya, melakukan eksperimen secara lokal menggunakan fitur gits branch, tanpa menyimpannya di repositori global. Tentu saja ini tidak menarik jika Anda menjelajahi fitur baru dengan banyak anggota dalam satu tim, kecuali mereka semua merasa nyaman menggunakan git dan menarik satu sama lain melalui jaringan. Dengan menggunakan git svn Anda juga bisa menggunakan git cherrypick untuk memilih satu komit untuk diterapkan dari satu cabang ke cabang lainnya (misalnya pengembangan ke dilepas-x.x-tag).

Hanya itu yang bisa saya dapatkan untuk saat ini, semoga itu membantu.


2
2017-11-12 15:09



Dalam kegiatan saya, saya menggunakan SVN dengan pendekatan berikut.

  1. Batang adalah cabang "tuan". Anda tidak boleh melakukan apa pun secara langsung di bagasi. Trunk selalu harus sama persis dengan versi rilis terbaru dalam produksi. Jadi, batang selalu mewakili cabang yang stabil. Batang hanya diperbarui dengan reintegrasi cabang.

  2. Anda membutuhkan cabang untuk pekerjaan Anda. Setiap cabang baru harus dibuat dari bagasi, jadi setiap cabang baru sama persis dengan versi produksi pada waktu pembuatan. Perubahan dan perbaikan dilakukan di cabang-cabang.

  3. Anda harus memiliki setidaknya 2 cabang utama:

    • berkembang: dimaksudkan untuk perkembangan masa depan yang belum direncanakan untuk rilis.
    • hotfix: digunakan untuk melakukan semua perbaikan bug dan hanya perbaikan. Untuk penggunaan yang sering, Perlu diperbarui dengan versi batang ketika bagasi diperbarui.
  4. Buat cabang untuk setiap aliran utama pekerjaan: proyek, subproyek, permintaan perubahan. Anda dapat bekerja dengan pengembangan paralel.

  5. Buat cabang "integrasi" untuk bergabung dengan cabang yang harus Anda lepaskan. Anda perlu bergabung ke dalam cabang integrasi setiap cabang yang diikutsertakan untuk rilis. Jadi, cabang integrasi dapat menggabungkan perbaikan terbaru dan proyek, misalnya.

  6. Bangun artefak Anda dari cabang-cabang integrasi atau dari cabang-cabangnya sendiri.

  7. Ketika Anda telah merilis cabang, buat tag untuk rilis itu, sehingga Anda dapat memiliki salinan versi yang dirilis dan Anda masih dapat bekerja di cabang. Dalam tag Anda seharusnya hanya merilis versi. Jangan lakukan perubahan pada tag!

  8. Setelah cabang dilepaskan, Anda perlu memperbarui bagasi. Jadi, reintegrasi kembali cabang di batang pohon. Anda dapat mengintegrasikan kembali cabang integrasi, atau cabang secara langsung (jika Anda tidak lulus dari integrasi).

  9. Ketika bagasi lagi dicocokkan dengan versi produksi, laporkan di semua cabang aktif Anda.

Metode ini tidak benar-benar merupakan replika dari konsep aliran git, tetapi ini mengikuti beberapa persyaratannya.

Dengan pendekatan ini Anda dapat memiliki keuntungan sebagai berikut:

  • batangnya stabil. Anda selalu tahu apa yang diwakili oleh batang pada saat itu.

  • Setiap cabang hanya berisi perubahannya sendiri.

  • Dengan cabang-cabang integrasi Anda dapat mengelola cabang paralel dalam satu rilis

  • Dengan tag Anda selalu memiliki salinan versi yang dirilis

Kerugiannya adalah:

  • Banyak cabang untuk dikelola.

  • Anda harus menggabungkan dan beralih sangat sering, terutama untuk melaporkan perubahan ke cabang-cabang integrasi

  • Banyak konflik yang harus dipecahkan setiap saat

By the way, ini adalah pendekatan terbaik yang pernah saya kerjakan karena ini memungkinkan Anda untuk tetap mengontrol versi.


0
2018-05-26 00:13