Mengapa DVCSes tampaknya memiliki fobia irasional dari perubahan yang tidak dikomit?


10

Berasal dari latar belakang SVN, salah satu hal tersulit untuk membiasakan diri ketika bekerja dengan sistem DVCS adalah cara mereka semua tampaknya menganggap setiap perubahan yang tidak dikomit sama sekali seperti bom waktu yang sedang berdetak.

Di Mercurial, jika Anda mencoba mengambil perubahan dan Anda memiliki perubahan yang tidak dikomit di copy pekerjaan Anda, Anda harus melompat melalui lingkaran untuk mendapatkannya hanya untuk menggabungkan perubahan yang masuk. Cobalah untuk beralih cabang? Ini akan memaksa Anda untuk mengesampingkan semuanya dan kemudian Anda harus segera mengosongkan semuanya di ujung lainnya. (SVN tidak memiliki masalah dengan salah satu skenario ini.)

Git hampir sama caranya. Saya bekerja berdampingan dengan pengembang lain dalam suatu proyek, dan saya hanya mencoba untuk memilih salah satu dari komitmennya ke dalam garpu saya. Itu menolak untuk membiarkan saya karena saya memiliki perubahan komitmen dalam copy pekerjaan saya, pada file yang sama sekali berbeda dari yang diubah dalam komitnya. Bahkan tidak ada opsi penggabungan; rupanya saya harus menyimpan perubahan saya terlebih dahulu!

Jika seseorang memperlakukan sesuatu yang sama sekali tidak berbahaya dengan sangat hati-hati, saya akan menyebutnya "fobia," ketakutan irasional yang harus dianggap sebagai gangguan mental. Tapi Git dan Mercurial dirancang oleh dua tim pengembang cerdas dan rasional yang berbeda, jadi saya harus bertanya-tanya apakah mereka tahu sesuatu yang tidak saya sadari.

Apakah ada alasan teknis yang membenarkan sikap ini terhadap perubahan yang tidak dikomit? Dan jika demikian, mengapa masalah yang dipermasalahkan tampaknya hanya ada di DVCSes?


7
Bukankah seluruh poin dari hal-hal ini yang Anda dapat periksa ke cabang lokal Anda sepele? Penggabungan dari pengembang lain kemudian menjadi penggabungan yang sebenarnya daripada mencoba menyelesaikan tiga sumber (versi Anda, perubahan Anda, versi mereka). Saya bukan ahli dalam bidang ini, jadi mungkin tidak masuk akal.
Telastyn

3
Saya setuju dengan Telastyn. Saya pikir alasan Anda menghadapi pembatasan yang tampaknya tidak rasional adalah karena Anda tidak menggunakan Git secara idiomatis. Salah satu kekuatan utama Git adalah Anda dapat berkomitmen secara lokal. Jika saya harus menggabungkan kode orang lain ke dalam copy pekerjaan saya, saya pasti akan melakukan komitmen lokal terlebih dahulu. Komitmen lokal murah, mudah dibersihkan, dan jaring pengaman yang luar biasa. Saya tidak heran alur kerja Git berputar di sekitarnya (dan akibatnya peringatan dan pembatasan menganggap Anda lebih suka melakukan daripada bekerja pada file yang tidak dikomit).
MetaFight

3
@Telastyn: Tidak, Anda tidak bisa, karena checkin - bahkan ke cabang lokal Anda - memerlukan alasan komit dan membuat catatan dalam sejarah. Jadi, jika Anda memeriksa sesuatu yang belum siap untuk dikomit, akhirnya ketika Anda siap untuk mendorong perubahan ke repositori jarak jauh, sejarah itu akan ada di sana kecuali Anda pergi melalui operasi tambahan untuk menulis ulang sejarah. Itu tidak sesuai dengan definisi "sepele" yang saya kenal, dan bagi saya sepertinya banyak kompleksitas tambahan tanpa manfaat yang dapat diartikulasikan.
Mason Wheeler

Betulkah? "Stabilisasi XYZ untuk menggabungkan dari utama" apakah ada beban, atau pergi ke sejarah yang terlalu sopan?
Telastyn

1
Apakah Anda akan mengirimkan makalah untuk publikasi tanpa setidaknya mengedit untuk kejelasan? Maka jangan kirimkan seri komit draft pertama Anda untuk publikasi. Apakah setiap orang yang akan membaca kode Anda mendukung besar: kembali dan menghasilkan seri komit yang akan Anda tulis jika Anda memiliki pandangan ke depan untuk melakukannya dengan cara itu di tempat pertama. Rebase interaktif tidak sulit ..
jthill

Jawaban:


4
  1. Dalam DVCS-dunia komit murah dan sejarah bisa berubah. WIP dapat menjadi "kotor", seperti yang Anda inginkan: dan saya tidak dapat melihat alasan apa pun terhadap "jatuhkan status saya saat ini di changeset untuk disimpan"
  2. Karenanya, sejarah SVN bersifat linear - Anda harus menggabungkan konsep Anda dengan perubahan dari revisi baru. Penggunaan DVCS (secara alami) DAG, dan head tambahan (komit + tarik + ke atas) untuk riwayat yang berbeda lebih aman, daripada bergabung dengan dir yang dimodifikasi sambil bekerja dengan perubahan eksternal yang diambil
  3. Saat Anda mengganti (ke beberapa node ) WC yang dimodifikasi di Subversion, Anda menyingkirkan satu potensi tambahan penggabungan (berlawanan dengan "komit ke lama" - "switch" - "menggabungkan 1 rentang rev") ... dan kami tahu: merge di SVN bukan sisi alat yang sempurna, sementara itu bukan masalah sama sekali untuk DVCSes

Lanjut

Ini bukan fobia, penegakan (terkadang keras) untuk mengikuti tata krama yang baik "sering melakukan" (pengguna SVN kadang-kadang takut dengan gaya ini)

Dan, akhirnya, hg qnew|qpop|qpushadalah harga wajar kecil untuk kerapian dan ketertiban


1

Saat Anda bergabung atau memilih-ceri git, Anda segera membuat komit. Operasi tidak selesai sampai komit selesai dan bagian dari sejarah.

Sekarang, apa yang akan terjadi jika gitAnda memperbolehkan perubahan yang tidak dikomit di direktori kerja Anda? Anda akan memiliki (kurang lebih) waktu yang sulit untuk membedakan antara konflik perubahan / penggabungan yang harus Anda selesaikan untuk penggabungan / pemilihan ceri, dan perubahan yang Anda perkenalkan sendiri. Juga, hampir tidak mungkin bagi Anda untuk menguji apa yang sebenarnya Anda lakukan.

Dengan demikian, memaksa direktori kerja yang bersih untuk menggabungkan situasi membantu menjaga hal-hal sederhana dan mudah dikelola. Lagi pula, yang perlu Anda lakukan adalah menyembunyikan perubahan yang tidak dikomit sebelum penggabungan, dan melepaskannya setelahnya. Perhatikan, bahwa dalam alur kerja

git stash
git pull
git stash pop

Anda memiliki dua operasi penggabungan (!). Yang menggabungkan komit terakhir Anda dengan perubahan yang masuk, dan yang menggabungkan perubahan yang tidak dikomit Anda dengan komit gabungan yang dihasilkan. Dengan cara ini, Anda hanya perlu menggabungkan dua hal menjadi satu, menghindari kebingungan yang akan timbul dari upaya menggabungkan tiga hal menjadi satu dalam satu operasi sekaligus mencoba mengabaikan ketiga hal ini. Tanda git stash/ git stash popmembuatnya mudah dan eksplisit bahwa Anda mengabaikan perubahan yang tidak dikomit untuk penggabungan.

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.