Pertanyaan Alur kerja lincah untuk ~ 15 pengembang - Haruskah kita menggunakan cabang bernama?


Tim saya baru saja memulai dengan Mercurial dan repositori pusat. Kami memiliki Hudson membangun ujung cabang "default" - yang pada dasarnya adalah jalur utama kami. Kami memiliki kebijakan check-in dengan VCS lama kami bahwa tinjauan kode, pengujian, dll harus dilakukan sebelum Anda masuk ke saluran utama.

Jadi, katakanlah Anda sedang mengerjakan fitur X. Anda mengerjakan beberapa hal, mendasarkannya dari "default", dan kemudian Anda melakukan fitur parsial sebagai pos pemeriksaan. Secara lokal "default" Anda sekarang rusak - Anda belum membaginya dengan siapa pun, tetapi jika Anda melakukan push, nah sekarang Anda telah memecahkan kode di mainline.

Bahkan jika Anda menunggu untuk menekan hingga semuanya beres, sepertinya ada situasi (mis. Mengerjakan dua hal sekaligus) di mana Anda perlu mendorong beberapa perubahan tetapi tidak semua.

Selain itu, jika Anda memeriksa semua perubahan pos pemeriksaan Anda, maka akan ada beberapa revisi di jalur utama yang dibuat, dan yang lainnya di jalur utama yang tidak dibuat.

Kami telah mulai menggunakan cabang bernama - tetapi semakin banyak membaca saya lakukan semakin saya pikir kami salah menggunakan cabang bernama.

Ada saran tentang cara mengatur alur kerja yang baik yang memungkinkan kita untuk menjalankan Hudson dan menjaga kebijakan utama kami?


32
2018-02-26 16:50


asal


Jawaban:


Pertama, saya sangat merekomendasikan Panduan untuk Bercabang dalam Mercurial

Selanjutnya, Anda hanya dapat menekan cabang saat ini: Nudge - Versi Push yang Lebih Lembut

Dan mungkin Anda dapat memutuskan untuk mengizinkan hanya satu kepala per cabang: 32. Mencegah dorongan yang akan membuat banyak kepala

Pertanyaan SO lainnya terkait dengan cabang bernama:


18
2018-02-27 18:30



Anda mungkin mempertimbangkan setidaknya dua repositori. Repositori "arus utama" memiliki kode Anda yang telah diuji dan ditinjau. Kode hanya didorong ke repositori ini setelah Hudson telah mengujinya dan setelah ulasan apa pun yang Anda lakukan telah selesai. Repositori "pengujian" akan menjadi tiruan dari garis utama. Ini adalah repositori yang dipantau Hudson, sehingga setiap kali sebuah perubahan didorong ke repositori pengujian, tes Hudson adalah. Anda mungkin bisa mengatur langkah membangun Hudson yang mendorong perubahan dari repositori pengujian ke arus utama Anda jika tes lulus.

Pengembang selalu mendorong ke repositori pengujian, tetapi hanya menarik dari jalur utama, sehingga mereka hanya menarik kode yang diuji. Jika mereka perlu berbagi perubahan yang belum diuji, mereka dapat mendorong / menarik secara langsung antara repositori lokal masing-masing. Mungkin ada kemungkinan untuk mengonfigurasi Hg sehingga garis utama hanya menerima dorongan dari repositori pengujian, sehingga pengembang tidak dapat secara tidak sengaja mendorong ke jalur utama alih-alih pengujian.

Mungkin bagus juga memiliki repositori tinjauan. Jadi pengembang mendorong untuk menguji, Hudson mendorong kode yang diuji untuk ditinjau, dan kemudian meninjau kode didorong ke garis utama.

Disclaimer: Saya hanya menggunakan Hg pada proyek-proyek sepele dan dengan cara-cara sepele.


2
2018-02-26 17:01



Apa yang kami lakukan di perusahaan saya adalah menggunakan cabang bernama untuk membedakan versi stabil (di mana kami hanya melakukan perbaikan bug) dan versi berikutnya di mana pengembangan terjadi dan kami mendukung perbaikan dari stabil ke default secara rutin (dengan hg merge stable pada cabang default).

Untuk peninjauan kode, kami menggunakan ekstensi mq untuk memungkinkan pengembang mengirimkan tambalan yang bersih. Dan pengembang dapat menarik dari repositori satu sama lain, tanpa mencemari referensi repositori.

Penafian: kami tidak menggunakan Hudson.


2
2018-02-26 17:04



Ini masalah pola pikir. VCSes terdistribusi tidak mengharuskan Anda menyimpan satu pusat penyimpanan tunggal.

Daripada memiliki jalur utama terbuka untuk semua orang, periksa dengan akses tulis terbatas. Hanya perubahan-perubahan yang telah disetujui (diuji, ditandatangani, apa pun yang masuk akal bagi Anda) dimasukkan ke dalam jaringan utama.

Bagaimana Anda mengelola perubahan menjadi arus utama adalah pertanyaan terbuka lebar dengan banyak kemungkinan jawaban. Berikut ini dua dari bagian atas kepala saya:

  • Pengembang dapat mendorong dengan bebas ke pusat "pengujian" repo, dari mana perubahan ditinjau.
  • Minta pengembang menerbitkan perubahan pada workstation mereka sendiri (ingat, cabang-cabangnya murah) dan mintalah proses peninjauan arus utama mengambilnya langsung dari sana.

2
2018-02-26 20:16



Anda juga bisa mempertimbangkan menggunakan Bookmark ekstensi alih-alih cabang bernama.

Jika Anda terbiasa dengan git, bookmark berperilaku seperti git-branch, bukan cabang-cabang lincah.


0
2017-11-18 05:12