Apakah git "Aturan Emas untuk Rebasing" begitu penting?


22

Saya baru-baru ini berdiskusi dengan orang-orang yang benar-benar menentang strategi rebase cabang fitur di GIT. Tampaknya menjadi pola yang diterima untuk menggunakan rebase hanya untuk cabang lokal, swasta tetapi tidak pernah menggunakannya ketika ada beberapa orang yang bekerja pada fitur & cabang yang sama, seperti yang disebut "Peraturan Emas untuk Rebasing" ini (seperti dijelaskan di sini: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Saya hanya terkejut ada konsensus tentang ini. Saya bekerja 3 tahun dengan strategi rebasing penuh, dengan sekitar 20 pengembang bekerja bersama dan coba tebak, itu berhasil.

Prosesnya pada dasarnya:

  • Anda membuat cabang fitur Anda, sebut saja "fitur saya", dan dorong ke fitur asli / asli
  • Orang lain mungkin memeriksanya dan mengerjakannya
  • Anda kadang-kadang dapat rebase dari master: dari "myfeature", git rebase asal / master ; dan kemudian, ya, Anda harus mendorongnya.
  • Apa yang terjadi ketika orang lain ingin mendorong komitmen mereka? Mereka hanya rebase itu: git rebase asal / myfeature . Jadi mereka sekarang maju cepat dan bisa mendorongnya tanpa memaksa.

Satu-satunya prinsip yang harus dihormati adalah bahwa cabang fitur dimiliki oleh seseorang . Pemilik adalah satu-satunya yang dapat mendorong-kekuatan.

Jadi, saya akui: begitu ada push-force, ada risiko untuk melakukan kesalahan. Itu benar. Tetapi ada juga banyak cara untuk pulih dari kesalahan, dan sungguh, dalam 3 tahun pembangunan, saya tidak melihat banyak kesalahan yang memaksa, dan ketika itu terjadi kami selalu menemukan cara untuk pulih dengan benar.

Jadi, mengapa "Aturan Emas Rebase" ini diterima secara luas? Apakah ada hal lain yang saya lewatkan? Saya mengerti itu membutuhkan minimum organisasi (setiap strategi membutuhkan beberapa organisasi), tetapi itu berhasil.


Sesuatu yang saya lupa ceritakan, tetapi memiliki arti penting: dalam pengalaman saya sebelumnya, kami menggunakan gerrit sebagai alat peninjau kode. Ini berarti bahwa jika seseorang mendorong komit saat pemilik cabang melakukan rebase, tidak ada risiko komit hilang, karena komit itu didorong ke gerrit alih-alih langsung ke repositori asal. Dan karena pemilik cabang adalah satu-satunya yang memiliki hak untuk menyerahkan komitmen dari gerrit, risiko untuk melakukan kesalahan sangat rendah.
Joel

bagaimana jika saya menggabungkan cabang fitur orang lain ke milik saya?
Winston Ewert

Jika fitur Anda tergantung pada yang lain, maka saya kira Anda bisa mengubah karakter Anda dari yang lain: git rebase origin / otherFeature (saya katakan rebase daripada bergabung, karena tujuannya adalah untuk menjaga sejarah tetap linier). Saya akui bahwa kompleksitas dari semua itu meningkat banyak ketika Anda memperkenalkan lebih banyak ketergantungan antar cabang.
Joel

Jawaban:


10

Masalah dengan kekuatan mendorong bukan tentang cabang fitur dan master Anda, tetapi tentang mendorong master Anda ke master orang lain - bahwa sinkronisasi akan menimpa master mereka dengan perubahan Anda, mengabaikan apa pun yang ada di ujung mereka.

Mempertimbangkan bahaya ini, ada alasan mengapa Anda tidak boleh menggunakannya sama sekali kecuali ada sesuatu yang kacau dan Anda benar-benar perlu menggunakannya untuk melakukan perbaikan. Sistem SCM seharusnya tidak perlu dipaksa seperti ini, jika itu terjadi karena ada sesuatu yang sangat salah (dan pendekatan pertama saya dalam kasus tersebut adalah mengembalikan cadangan dan mengulangi operasi untuk menjaga sejarah tetap utuh).

Jadi mungkin pertanyaannya adalah mengapa Anda rebasing sama sekali? Untuk riwayat 'bersih' saat mengembalikan fitur ke master? Jika demikian, Anda membuang semua sejarah bagus tentang percabangan karena alasan gaya semata. Penggabungan fast-forward IMHO juga bukan praktik terbaik, Anda harus menyimpan semua riwayat sehingga Anda dapat melihat apa yang sebenarnya Anda lakukan, bukan versi yang disanitasi sesudahnya.


Anda bisa, tentu saja, menarik master, rebase, dan kemudian memaksakan dorongan, tetapi itu bukan atom.
Kevin

@ gbjbaanb Anda memang benar, strategi rebasing adalah semua tentang alasan gaya / sejarah yang lebih mudah dibaca. Saya tidak berusaha berargumen bahwa itu lebih baik, atau tidak. Tapi itu mungkin untuk dilakukan, dan itulah yang ingin saya sampaikan. Tentu saja saya tidak berbicara tentang memaksa paksa pada master, tetapi hanya pada cabang fitur.
Joel

4
IMHO fitur desain dari kedua rebase, dan penggabungan maju cepat adalah kesalahan. SCM adalah tentang menjaga sejarah sehingga Anda dapat melihat apa yang terjadi ketika Anda perlu, dan mengambil snapshot untuk poin yang relevan dalam waktu. Setidaknya itulah yang diinginkan kebanyakan orang, saya kira Linus ingin agar sejarahnya sesederhana mungkin untuk dibaca dan oleh karena itu masukkan mereka untuk keuntungannya. IMHO dia seharusnya lebih berupaya membuat perbedaan antara 2 revisi lebih mudah dikelola (yaitu memungkinkan tampilan menjadi lebih sederhana, bukan sejarah yang mendasarinya)
gbjbaanb

2
Saat Anda menerbitkan makalah, apakah Anda menerbitkan draf pertama? Apakah ada undang-undang yang mengatakan alat yang Anda gunakan untuk menulis draf pertama tidak dapat digunakan untuk mengeditnya untuk publikasi? Git adalah alat pengembangan. Jika Anda ingin mempertahankan seri secara andal dan terverifikasi, pertahankan. Jika Anda ingin mengeditnya untuk publikasi, editlah. Bintang Git di kedua tugas.
jthill

5

Rebase tidak penting, seperti yang Anda katakan sebagian besar kosmetik. Kadang-kadang itu jauh lebih sederhana daripada penggabungan. Sehingga dapat memiliki beberapa nilai "aktual", tetapi hanya "kadang-kadang"

Penggunaan rebase yang tidak tepat bisa mahal. Tidak mungkin kehilangan data jika Anda cukup tahu untuk tidak panik dan mencari prosedur pemulihan, tetapi "hei tidak ada yang mendorong untuk sementara waktu saya harus memperbaiki ..." itu tidak bagus. Juga tidak ada orang yang menghabiskan waktu untuk pemulihan dan pengujian penelitian ketika mereka bisa saja menambahkan fitur atau meremas bug (atau rumah dengan keluarga).

Dengan pertukaran itu hasil "sangat sedikit orang melakukan rebase dan dorongan paksa" tidak terlalu mengejutkan.

Beberapa alur kerja dapat mengurangi risiko, misalnya menguranginya menjadi "nol selama Anda ingat cabang mana yang Anda boleh paksakan dan mana Anda tidak bisa". Pada kenyataannya mereka mungkin cukup aman untuk menjustifikasi risiko, tetapi orang sering membuat pilihan berdasarkan cerita rakyat yang lebih besar. Kemudian lagi pada kenyataannya manfaatnya cukup kecil, jadi seberapa kecil risikonya sebenarnya?


3
"Hei, tidak ada yang mendorong untuk sementara waktu saya harus memperbaiki ..." .. kedengarannya seperti dulu menggunakan Visual Source Safe. Saya pikir git lebih baik dari itu.
gbjbaanb

Yap, jadi orang membuat aturan seperti "jangan bermain dengan alat tajam! (Paksa dorong)" Jadi mereka bisa menghindari mengobati luka yang bisa dihindari!
Garis

2
@ gbjbaanb Ya, Git lebih baik dari itu - ketika Anda menggunakannya dengan benar. Mengeluh tentang Git karena tidak mampu menangani pengembangan bersamaan dengan elegan ketika Anda terus melakukan rebasing dan mengubah hash komit semuanya seperti mengeluh tentang mobil yang lebih rendah daripada gerbong karena mereka jauh lebih berat bagi kuda untuk menarik. Itu bukan kesalahan alat yang orang bersikeras menggunakannya salah ...
Idan Arye

4
Yah itu semacam kesalahan alat. Git memperlihatkan BANYAK tepi tajam, dan sementara kadang-kadang mencatat bahwa mereka tajam itu sering tidak. Jika Anda membandingkannya dengan mengatakan CVS di mana semua bit tajam berada dalam sub-perintah TUNGGAL ("admin cvs"? Ada manfaatnya beberapa saat ...) yang keluar dari cara untuk mengatakan "ini dapat membuat Anda buruk, jangan gunakan kecuali Anda memiliki kebutuhan yang sangat ". Atau sistem kontrol versi lain yang menghilangkan kemampuan yang dapat membahayakan.
Garis

4
Itu bukan untuk mengatakan git belum membuat pilihan desain yang valid (fungsi terkait kelompok oleh subperintah, dan lebih suka mengizinkan git untuk menyelesaikan hal-hal yang lebih kompleks di tangan kanan) ... tetapi mereka adalah PILIHAN, dan orang bisa kritis terhadap pilihan untuk memiliki begitu banyak ujung yang tajam, seperti halnya seseorang dapat kritis terhadap pilihan VCS lain untuk meninggalkan begitu banyak fitur yang berguna "hanya karena seseorang dapat terluka".
Garis

2

Untuk menambahkan suara yang berbeda:

Ya, jika Anda bekerja seperti yang Anda gambarkan, tidak ada masalah dengan menggunakan rebasedan memaksakan diri. Poin kritisnya adalah: Anda memiliki perjanjian di tim Anda.

Peringatan tentang rebasedan teman adalah untuk kasus di mana tidak ada perjanjian khusus. Biasanya, git melindungi Anda secara otomatis, dengan, misalnya, tidak memungkinkan dorongan yang tidak maju cepat. Menggunakan rebasedan mendorong secara paksa mengabaikan keamanan itu. Tidak apa-apa jika Anda memiliki sesuatu yang lain di tempatnya.

Di tim saya, kami juga kadang-kadang mengubah fitur cabang jika sejarah menjadi berantakan. Kami menghapus cabang lama dan membuat cabang baru dengan nama baru, atau kami hanya berkoordinasi secara informal (yang dimungkinkan karena kami adalah tim kecil, dan tidak ada orang lain yang bekerja di repositori kami).


Perhatikan bahwa proyek git sendiri juga melakukan hal yang serupa: Mereka memiliki cabang integrasi yang secara teratur diciptakan kembali, yang disebut "pu" ("pembaruan yang diusulkan"). Didokumentasikan bahwa cabang ini diciptakan kembali secara teratur, dan Anda tidak boleh mendasarkan pekerjaan baru di atasnya.


1

Jadi, saya akui: begitu ada push-force, ada risiko untuk melakukan kesalahan. Itu benar. Tetapi ada juga banyak cara untuk pulih dari kesalahan, dan sungguh, dalam 3 tahun pembangunan, saya tidak melihat banyak kesalahan yang memaksa, dan ketika itu terjadi kami selalu menemukan cara untuk pulih dengan benar.

Alasan mengapa pengguna Git cenderung menghindari riwayat yang dapat diubah bersama adalah karena tidak ada penghindaran otomatis atau perbaikan masalah ini. Anda harus tahu apa yang Anda lakukan, dan Anda harus memperbaiki semuanya secara manual jika Anda mengacaukannya. Mengijinkan satu orang untuk melakukan pemaksaan paksa tidak intuitif dan bertentangan dengan desain Git yang didistribusikan. Apa yang terjadi jika orang itu pergi berlibur? Apakah ada orang lain yang sementara memiliki cabang? Bagaimana Anda tahu mereka tidak akan berkeliaran apa pun yang dilakukan pemilik aslinya? Dan di dunia open source, apa yang terjadi jika pemilik cabang berangsur-angsur menjauh dari komunitas, tanpa secara resmi pergi? Anda bisa kehilangan banyak waktu menunggu untuk menyerahkan kepemilikan cabang kepada orang lain.

Tetapi masalah sebenarnya adalah ini: Jika Anda mengacau dan tidak segera menyadarinya, komitmen lama pada akhirnya akan hilang setelah waktu yang cukup berlalu. Pada titik itu, masalahnya mungkin tidak dapat dipulihkan (atau setidaknya, berpotensi sangat sulit untuk dipulihkan, tergantung pada seperti apa kisah cadangan Anda - apakah Anda membuat cadangan salinan lama dari repositori Git Anda, yaitu, bukan hanya klon?).

Bandingkan ini dengan karya evolusi Changeset Mercurial (yang, saya harus perhatikan, belum selesai atau stabil). Setiap orang dapat membuat perubahan apa pun pada riwayat yang mereka sukai, asalkan perubahan tersebut tidak ditandai untuk umum. Amandemen dan rebase ini dapat didorong dan ditarik dengan impunitas total, tidak perlu untuk pemilik cabang. Tidak ada data yang pernah dihapus; seluruh repositori lokal hanya ditambahkan. Perubahan yang tidak lagi dibutuhkan ditandai sudah usang, tetapi disimpan tanpa batas waktu. Akhirnya, ketika Anda mengacaukan riwayat Anda (yang diperlakukan sebagai bagian normal dari alur kerja sehari-hari Anda), ada perintah bagus untuk membersihkannya untuk Anda secara otomatis. Ini adalah jenis yang diharapkan orang-orang sebelum mereka berkeliling memodifikasi sejarah bersama.


Saya setuju dengan "filosofi git" ini dan saya juga berpikir bahwa filosofi terkadang dapat diretas :). Lebih serius, seperti yang saya nyatakan dalam komentar, itu sekarang 3 tahun yang lalu, saya dalam kasus tertentu memiliki Gerrit sebagai alat peninjau kode yang bertindak sebagai alat cadangan de-facto, mencegah potensi kerugian yang dramatis. Sekarang saya masih berpikir rebase tidak masalah ketika Anda yakin akan "mengendalikan" cabang. Bahkan dalam proyek opensource, jika saya mengembangkan fitur dan membuka permintaan tarik, saya "memiliki" PR itu, saya menganggap saya memiliki hak untuk rebase cabangnya, terserah saya untuk tidak mengacaukan pekerjaan saya sendiri selama rebasing ... (1/2)
Joel

..., dan jika beberapa orang ingin melakukan modifikasi pada PR itu maka saya menganggap mereka harus memberi tahu saya terlebih dahulu, dan itu masalah komunikasi. (2/2)
Joel

PS: terima kasih atas tautan evolusi Changeset, itu menarik
Joel

Sebenarnya, rebase seperti mengatakan: "mari kita menulis ulang semua pekerjaan saya dari awal (dari master terbaru), menghapus semua pekerjaan saya sebelumnya." Jika Anda boleh melakukan itu, Anda boleh melakukan rebase.
Joel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.