Apakah ada justifikasi untuk meninggalkan penanda konflik dalam kode check-in?

Pertimbangkan penanda konflik. yaitu:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

Dalam kasus tertentu yang memotivasi saya untuk mengirim pertanyaan ini, anggota tim yang bertanggung jawab baru saja menyelesaikan penggabungan dari hulu ke cabang kami, dan dalam beberapa kasus meninggalkannya, sebagai komentar, sebagai semacam dokumentasi tentang apa yang baru saja terjadi terselesaikan. Dia meninggalkannya dalam keadaan terkompilasi, tes lulus, jadi itu tidak seburuk yang Anda pikirkan.

Namun secara naluriah, aku benar-benar keberatan dengan hal ini, namun sebagai iblis yang mengadvokasi diriku, aku bisa mengerti mengapa dia melakukannya:

• karena menyoroti kepada pengembang tim lain apa yang telah berubah sebagai hasil penggabungan.
• karena mereka yang lebih ahli dengan potongan kode tertentu kemudian dapat mengatasi masalah yang diilustrasikan oleh komentar sehingga ia tidak perlu menebak.
• karena penggabungan hulu adalah rasa sakit yang tepat dan mungkin sulit untuk membenarkan waktu untuk menyelesaikan semuanya dengan baik dan lengkap, sehingga beberapa pemberitahuan FIXME semi-lengkap diperlukan, jadi mengapa tidak menggunakan konflik asli sebagai komentar untuk mendokumentasikan ini.

Keberatan saya bersifat naluriah, tetapi saya ingin dapat membenarkannya secara rasional, atau melihat posisi saya lebih bijak. Adakah yang bisa memberi saya beberapa contoh atau bahkan pengalaman di mana orang-orang memiliki waktu yang buruk dengan orang lain melakukan ini dan / atau alasan mengapa itu adalah praktik yang buruk (atau Anda dapat berperan sebagai penasihat setan dan mendukungnya).

Kekhawatiran saya sendiri adalah bahwa itu jelas akan mengganggu jika saya mengedit salah satu file yang bersangkutan, menarik perubahan, mendapat konflik nyata, tetapi juga menarik yang berkomentar. Maka saya akan memiliki file yang sangat berantakan. Untungnya itu tidak terjadi.

Ini jelas salah. Ini adalah tugas dari sistem kontrol versi untuk melacak perubahan, dan itu adalah tugas dari alat yang berbeda untuk menunjukkan apa yang telah berubah sebagai hasil penggabungan. Harus ada komentar di log komit, dan mungkin dalam kode, menjelaskan apa yang diubah dan mengapa. Namun, IMHO, membiarkan penanda konflik sebagai komentar sama dengan meninggalkan kode mati.

Saya punya masalah yang sama dengan beberapa kode baik yang dikomentari (yang entah bagaimana mirip dengan kasus Anda) atau pindah ke metode yang tidak benar-benar dipanggil di mana saja. Ketika ditanya mengapa orang melakukan ini, jawabannya adalah mereka merasa sedikit lebih aman ketika mereka masih memiliki beberapa blok kode. Argumen kontra yang paling jelas adalah bahwa itu adalah pekerjaan VCS dan bukan milik mereka. Namun, ada juga aspek lain. Ketika orang lain membaca kode sambil belajar atau membuat perubahan, dia mungkin akan dilacak oleh komentar seperti itu. Dia pasti akan membacanya dan mungkin meluangkan waktu untuk memahami mengapa itu ada di sini dan korelasi apa yang mungkin terjadi dengan pekerjaannya saat ini. Karena penanda konflik adalah tanda konflik, yang sudah diselesaikan, ini pasti buang-buang waktu.

Saya pikir komentar harus mengacu pada kode yang ada di sana, bukan ke kode yang telah ada di masa lalu, atau ke peristiwa yang terjadi pada kode di masa lalu, atau ke kode yang ada di alam semesta paralel (cabang lain) di lalu. Membiarkan spidol dengan cara yang dilakukan anggota tim Anda menciptakan setidaknya tiga masalah:

1. Kode asli mungkin adalah sesuatu seperti blah blah null, dan laporan bug mengatakan "Tidak dapat menggunakan null di sana, gunakan ini atau itu, atau apa pun." Jadi, dua orang secara mandiri memperbaiki bug dan ketika perbaikan digabung, konflik muncul. Sekarang komentar mendokumentasikan bukan apa masalahnya atau perbaikan apa yang diperbaiki, tetapi hanya bahwa ada dua perbaikan yang berbeda di beberapa titik di masa lalu. Itu tidak terlalu membantu. Komentar seperti //blah blah needs a non-null argumentsetidaknya akan memberikan indikasi apa yang berubah (dan bahkan informasi itu lebih mudah tersedia dari komentar komit sistem kontrol versi).
2. Versi yang digabungkan bahkan mungkin tidak terlihat seperti salah satu baris asli. Mungkin jika Anda ingin bla bla untuk mengambil ini dan itu, bentuk yang benar adalah blah blah (this,that)atau bahkan sesuatu yang lebih rumit. Dalam hal itu, meninggalkan pesan konflik sebagai komentar pasti akan membingungkan siapa pun yang mencoba membaca kode nanti.
3. Sebagian besar sistem kontrol versi memberi Anda akses ke riwayat proyek. Misalnya, saya dapat mengklik kanan pada file dalam gerhana (dengan svn), katakan "Tampilkan Riwayat ..." dan kemudian katakan "Bandingkan Saat Ini dengan ... 'dan dapatkan jendela berbeda yang menyoroti perbedaan. Informasi itu adalah cara lebih mudah untuk grok jika sorotan diff berisi perbedaan yang sebenarnya, dan bukan komentar di sekitar mereka. Setiap bit perubahan non-fungsional dalam kode membuat diff lebih sulit untuk dibaca.

Seberapa menjengkelkan penanda konflik dalam kode check-in?

Sangat menyebalkan.