Ulasan kode Gerrit, atau model fork and pull Github?

Saya memulai proyek perangkat lunak yang akan menjadi tim DAN komunitas dikembangkan. Saya sebelumnya dijual di gerrit, tetapi sekarang model permintaan garpu dan tarik Github tampaknya hampir menyediakan lebih banyak alat, cara untuk memvisualisasikan komitmen, dan kemudahan penggunaan.

Untuk seseorang yang setidaknya memiliki sedikit pengalaman dengan keduanya, apa pro / kontra dari masing-masing, dan yang akan lebih baik untuk proyek berbasis tim yang ingin membiarkan terbuka kemungkinan untuk pengembangan masyarakat?

— pengguna1366476
sumber

Perbedaan utama antara alur kerja Gerrit dan GitHub adalah bagaimana perubahan dimodelkan.

Dalam Gerrit, setiap komit adalah perubahan yang berdiri sendiri. Meskipun Gerrit akan menunjukkan kepada Anda hubungan antara komitmen, ulasan dilakukan berdasarkan komitmen. Tim yang pandai memecah perubahan besar menjadi komit kecil dan mandiri cenderung lebih sukses dengan Gerrit. Namun, karena model Gerrit mencakup revisi berturut-turut untuk komit tertentu, ini mendorong alur kerja Git yang tidak biasa digunakan oleh banyak pengembang, seperti mengubah komit sebelumnya dan mendorongnya kembali, atau memecah set komit yang tumbuh dari cabang topik menjadi satu. melakukan.

Di Github, permintaan tarik memodelkan hubungan antara dua cabang. Alur kerja yang diharapkan pada Github adalah untuk melakukan satu atau lebih perubahan ke cabang topik (sering dalam cabang repositori, tetapi tidak harus) dan membuat permintaan tarik antara cabang itu dan cabang "hulu". Dalam hal ini, apa yang sedang ditinjau adalah serangkaian komitmen yang terus tumbuh seiring peninjauan berlanjut. Hasilnya adalah serangkaian perubahan yang kemudian dapat digabungkan secara atom ketika mereka selesai. Permintaan tarikan dapat efektif dalam melacak perubahan dengan cakupan yang lebih besar yang dapat diterapkan pada banyak komitmen. Permintaan penarikan juga mendukung alur kerja SCM yang biasa digunakan oleh banyak pengembang, seperti menanggapi komentar ulasan dengan mengirimkan komitmen tindak lanjut di cabang yang sama.

Keuntungan besar dalam mendukung Github adalah jumlah pengembang yang akrab dengannya dibandingkan dengan Gerrit. Gerrit dapat menjadi populer dengan pengguna daya Git, tetapi penggunaan bebas gesekan membutuhkan pengetahuan git menengah atau lanjutan, dan toleransi kurva pembelajaran yang curam.

Keuntungan Gerrit adalah hubungan yang lebih dalam dengan Git. Permintaan Tarik Github cukup jauh dihapus dari model data standar Git sehingga seseorang harus menggunakan UI web Github atau API miliknya untuk membuat permintaan tarik. Antarmuka Gerrit untuk membuat dan memperbarui perubahan adalah protokol git itu sendiri.

— Martin Atkins
sumber

Terima kasih Martin, itu jawaban yang menarik. Aku bermaksud memandangi Gerrit sebentar, tapi kupikir aku akan mengesampingkannya. Jika itu mendorong pengeditan riwayat dan melakukan squashing, saya ingin tidak ada hubungannya dengan itu. * 8 '(

— Mark Booth

Hanya untuk memperjelas (saya sering menggunakan Gerrit di tempat kerja saya), apa yang dikatakan Martin di sini, "Gerrit ... mendorong alur kerja Git ... seperti mengubah komit sebelumnya dan mendorongnya kembali, atau menekan serangkaian komitmen yang berkembang. ..into satu komit "persis benar. Klarifikasi saya adalah bahwa komentar @ MarkBooth tentang "pengeditan sejarah" bukanlah yang dikatakan Martin. Mengubah komit (saat masih di Gerrit, dan tidak belum bergabung ke asal / master) tidak tidak melibatkan "sejarah editing". Bahkan, alur kerja ini berfungsi dengan baik. Pengeditan 'buruk' yang mengacu pada Mark Booth adalah mendorong kembali sejarah yang diedit ke sumber / master.

— likethesky

Terima kasih atas klarifikasi @likethesky tetapi saya memiliki interpretasi yang agak lebih literal tentang 'riwayat penyuntingan', dan sejauh yang saya ketahui, apa pun yang menghasilkan perubahan yang berisi konten yang tidak Anda lakukan secara eksplisit adalah 'riwayat penyuntingan'. Namun saya menyadari bahwa ini adalah penafsiran yang agak kejam dan hanya sedikit orang yang mematuhinya. * 8 ')

— Mark Booth

Cukup adil. :-) Tidak yakin saya mengerti apa yang Anda maksud dengan "perubahan yang berisi konten yang tidak Anda lakukan secara eksplisit," jadi silakan. rumit ... Saya berasumsi bahwa Anda tidak mengatakan bahwa Anda tidak pernah melakukan sementara (lokal, atau dibagi di antara anggota tim melalui cabang terpencil) melakukan seperti, "WIP: upaya ini untuk memecahkan masalah lengkung yang kita bahas," diikuti oleh squash / ubah yang lebih bermanfaat yang mengatakan, "Edisi 123: Refactored XYZ untuk meningkatkan ketahanan dan kemudahan penskalaan horizontal" sebagai pesan komit terakhir untuk pekerjaan itu. Tapi bagaimanapun, tentu saja Anda dapat memilih untuk menggunakan git dengan cara apa pun yang membuat Anda bahagia!

— likethesky

Ini jawaban yang fantastis. Untuk menambahkan, saya telah menemukan bahwa permintaan tarikan GitHub menumbuhkan komitmen yang lebih kecil, lebih iteratif dan sering berakhir dengan git log yang jauh lebih deskriptif yang tidak hanya menunjukkan produk kerja tetapi juga proses kerja. Ulasan kode Gerrit mendorong banyak sejarah repositori yang lebih bersih (ada sangat sedikit komitmen gabungan sebenarnya) dengan komitmen yang lebih besar dan lebih halus.

— tophyr