Mengapa tidak melakukan perubahan yang belum terselesaikan?

Dalam VCS tradisional, saya bisa mengerti mengapa Anda tidak akan melakukan file yang tidak terselesaikan karena Anda dapat merusak build. Namun, saya tidak mengerti mengapa Anda tidak boleh melakukan file yang tidak terselesaikan dalam DVCS (beberapa dari mereka benar-benar akan mencegah Anda melakukan file).

Sebaliknya, saya pikir repositori Anda harus dikunci dari mendorong dan menarik , tetapi tidak melakukan.

Mampu berkomitmen selama proses penggabungan memiliki beberapa keuntungan (seperti yang saya lihat):

• Perubahan gabungan yang sebenarnya ada dalam riwayat.
• Jika penggabungan itu sangat besar, Anda bisa membuat komitmen berkala.
• Jika Anda melakukan kesalahan, akan lebih mudah untuk memutar kembali (tanpa harus mengulang seluruh penggabungan).
• File-file dapat tetap ditandai sebagai tidak terselesaikan sampai ditandai sebagai terselesaikan. Ini akan mencegah mendorong / menarik.

Anda juga bisa berpotensi membuat set perubahan bertindak sebagai penggabungan, bukan hanya satu. Ini akan memungkinkan Anda untuk tetap menggunakan alat seperti git rerere.

Jadi mengapa melakukan dengan file yang tidak terselesaikan disukai / dicegah? Apakah ada alasan selain tradisi?

Masalah terbesar yang bisa saya lihat adalah menciptakan jendela komit di mana segala sesuatunya digabungkan dan (mungkin) tidak berfungsi dengan benar. Saat Anda mendorong set komit lokal terakhir, semua komit menengah tersebut juga akan muncul untuk semua orang. Di dunia ideal, saya harus dapat menarik komit apa pun dan kode harus bekerja. Jika Anda mulai melakukan di tengah penggabungan, status kode tidak terdefinisi dengan baik.

Satu hal yang bisa Anda lakukan adalah membuat komit lokal untuk penggabungan Anda, dan kemudian menggabungkannya menjadi satu komit besar ketika Anda mendorong (meskipun saya tidak yakin bagaimana (jika?) Ada vcs yang mendukung ini). Meskipun ini mungkin menghasilkan beberapa manfaat yang Anda sebutkan, saya tidak yakin itu sepadan dengan kompleksitas tambahan (kami sudah berurusan dengan daerah yang cukup membingungkan dan kompleks).

Saya paling akrab dengan Git, jadi saya akan menjawab untuk perspektif itu.

Saya tidak melihat alasan mengapa Anda atau VCS yang baik ingin memperbolehkan melakukan file yang tidak digembalakan, terutama jika itu adalah kode. Anda perlu menjaga repositori dalam kondisi yang konsisten, dan apa yang Anda sarankan akan melanggar komititas komit. Banyak VCS yang secara fisik mengubah file untuk menunjukkan di mana konflik berada - Git, SVN, dan CVS menggunakan >>>> <<<< jenis penanda. Dalam VCS dengan komit dan gabungan level-atom, Anda hanya akan membuat simpul yang tidak masuk akal bagi siapa pun selain Anda. Dalam pengembangan perangkat lunak, proyek Anda tidak dapat dibangun. Dalam dokumen grup, tidak ada yang tahu perubahan mana yang benar.

Sekarang, Git menyediakan beberapa alat yang dapat meringankan ini, adalah jenis komit yang Anda sarankan diizinkan. Misalnya, Anda bisa menekan semua komitmen yang Anda gabungkan sebelum mendorong. Yang akhirnya sama dengan komit gabungan biasa.

Kekhawatiran khusus tentang daftar manfaat Anda:

1. Perubahan gabungan yang sebenarnya ada dalam riwayat. Mengapa Anda memerlukan informasi tambahan? DVCS sangat bagus dalam membatasi konflik di wilayah terbatas. Setelah Anda memilih perubahan mana yang ingin disimpan, membandingkan salinan duplikat simpul komit dengan salinan sebelumnya akan memberi Anda persis seperti ini.
2. Jika penggabungan itu sangat besar, Anda bisa membuat komitmen berkala. Ini adalah kekhawatiran yang sahih, tetapi Anda seharusnya tidak pernah sampai di sini. Cabang harus terus-menerus melakukan perubahan di hulu supaya ini tidak akan pernah terjadi. Alat seperti rebaseatau memetik ceri yang dilakukan sekaligus dapat membantu Anda di sini dalam beberapa situasi.
3. Jika Anda melakukan kesalahan, akan lebih mudah untuk memutar kembali (tanpa harus mengulang seluruh gabungan). Lihat di atas - konflik Anda seharusnya tidak menjadi tidak terkelola.

Satu-satunya cara saran ini dapat bekerja adalah jika cabang adalah jika seluruh gabungan adalah atomik - Anda bisa melihat serangkaian commit, tetapi mereka hanya akan menjadi langkah dalam komit gabungan yang lebih besar yang harus diperlakukan sebagai satu simpul di pohon komit . Saya tidak berpikir VCS saat ini memiliki dukungan untuk jenis alur kerja ini, dan saya pikir itu tidak perlu.

Pengalaman utama saya terletak pada Mercurial, meskipun saya juga menggunakan git secara sporadis.

Mercurial tidak melarang Anda untuk melakukan file yang tidak terselesaikan, itu hanya membuat Anda kecewa . Kesepakatan yang sama dengan mendorong sebelum menarik perubahan yang tidak Anda miliki.

Yang perlu Anda lakukan di Mercurial adalah, setelah Anda memiliki file seperti yang Anda inginkan:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

--mark akan ... menandai file sebagai terselesaikan tanpa meminta Anda dengan alat gabungan. --semua akan mengurus pemilihan semua tanda file dengan konflik.

Jika Anda ingin mendorong tanpa menarik (dan akibatnya harus menggabungkan perubahan lain) lakukan seperti Jedi :

hg push --force

Pria berikutnya yang menarik akan mendapatkan +1 kepala (tidak ada permainan kata pun yang dimaksudkan)

Saya yakin ada cara untuk melakukan hal yang sama dengan Git (walaupun mungkin lebih berbelit-belit).

Ketika saya menggabungkan git, saya segera melakukan semua perubahan (termasuk konflik gabungan). Kemudian, di komit berikutnya, saya menyelesaikan konflik gabungan melalui editor teks. Setelah konflik diselesaikan, saya kemudian Push jika diinginkan.

Jujur saya tidak mengerti mengapa orang lain tidak melakukannya dengan cara ini, atau git tidak menegakkannya.

• "Menggabungkan komitmen" sekarang merupakan sejarah bersih dari apa yang perlu digabungkan.
• Komit berikut menunjukkan apa yang Anda lakukan untuk menyelesaikan konflik gabungan.
• Saat Anda Push, konflik pada saat itu terselesaikan dan build tidak terputus di ujung cabang.
• Pada titik mana pun, jika Anda mengacaukan resolusi konflik, Anda dapat dengan mudah kembali ke salah satu dari komit "gabungan pos" dan coba lagi.

Kelemahan besar alur kerja standar penyelesaian konflik sebelum melakukan adalah bahwa perubahan dari salinan lokal Anda dapat menyelinap masuk. Penambahan disembunyikan dari tinjauan kode oleh diff gabungan besar-besaran, sehingga Anda tidak melihat bahwa Anda secara tidak sengaja melakukan suatu API kunci atau lainnya.

Alur kerja saya yang dijelaskan di atas menghindari masalah penyalinan lokal ini, dan juga memungkinkan peninjau kode untuk memeriksa (hanya) detail resolusi gabungan Anda dalam diff komit yang terlihat persis seperti diff komit standar.

Saya pikir yang terbaik adalah mendorong perubahan kecil dan mendorong sering, bila memungkinkan (dan tentu saja tidak selalu), dan jangan komit kode yang tidak membangun, atau setengah selesai (kita semua membuat kesalahan, tetapi tidak dapat melakukannya dengan sengaja). Saya juga berasal dari git, dan salah satu hal terbaik yang saya pikir adalah kenyataan bahwa Anda dapat memiliki salinan repo yang bisa diterapkan di desktop Anda ... yang kemudian dapat Anda modifikasi sesuai dengan isi hati Anda. Saat perubahan besar Anda selesai, kirim pergi.

Melakukan banyak open source dengan git frustrasi terbesar bagi saya adalah mendapatkan kode setengah jadi dimasukkan ke dalam repo, dan mencoba melakukan build, tetapi tidak bisa, karena orang itu melakukan setengah pekerjaan dan berkata, "Saya sibuk sekarang , Saya akan menyelesaikannya dalam seminggu ". Jadi saya akhirnya harus menghapusnya (yang akan mengganggu pria itu), atau meluangkan waktu untuk menyelesaikan dan mengintegrasikannya sepenuhnya.

Saya kira dari sudut pandang saya, simpan barang setengah jadi secara lokal, kirim barang bagus melalui kawat.

Jangan menjadi budak alat Anda.

Tujuan dari VCS adalah untuk memungkinkan Anda melakukan pekerjaan Anda. Pekerjaan Anda bukan untuk menyimpan repositori lokal yang asli, tugas Anda adalah menulis kode. Jika melakukan lebih awal dan sering kali secara lokal memungkinkan Anda bekerja lebih baik, lakukanlah.

Namun, Anda tidak boleh mendorong kode yang rusak ke atas.

Karena pada dasarnya itu adalah ide yang buruk - itu akan menuntun Anda ke repositori yang dalam keadaan parlous (dan ruamnya untuk menganggap bahwa Anda akan pernah mendorong di mana pun, meskipun orang akan berpendapat bahwa Anda harus selalu memiliki setidaknya satu salinan).

Saya dapat melihat bahwa dalam kasus penggabungan besar / kompleks Anda mungkin ingin menyimpan pekerjaan Anda dalam proses dan untuk menetapkan titik referensi tetapi Anda masih akan meninggalkan sistem dalam keadaan kacau yang perlu diselesaikan.

Dan ada beberapa alternatif - Anda memiliki opsi untuk menggabungkan dari awal daripada kepala - yang mungkin memberi Anda kemampuan untuk beradaptasi dengan perubahan tanpa penggabungan epik (atau setidaknya dengan penggabungan yang lebih besar yang lebih mudah dipahami).

Ini adalah kasus yang saya temukan rebit git sangat berguna (tunduk pada peringatan biasa tentang rebasing) karena Anda memutar ulang perubahan Anda di atas keadaan saat ini Anda bisa memperbaiki konflik dalam potongan-potongan kecil.