Mengapa saya harus menulis pesan komit?

18

Mengapa saya harus menulis pesan komit? Saya tidak mau dan saya pikir itu bodoh setiap saat.

Frontend GUI yang saya gunakan yang tidak diketahui namanya akan memaksa Anda untuk melakukannya. Saya mendengar orang lain melakukannya setiap kali walaupun mereka menggunakan VCS pada baris perintah.

Jika saya melakukan beberapa kali sehari dan belum menyelesaikan fitur apa yang saya tulis? Saya HANYA pernah menulis pesan setelah melakukan banyak dan saya merasa sudah waktunya untuk tag mini atau ketika saya melakukan tag yang sebenarnya.

Apakah saya benar atau saya kehilangan sesuatu? Saya juga menggunakan sistem terdistribusi

dvcs version-control

— pengguna2528
sumber

1

Jangan repot-repot, katakan saja "bla" di baris komentar. Selama Anda tidak pernah berbagi kode dengan orang lain dan selama tidak ada orang lain yang akan bekerja dan selama Anda tidak perlu mengembalikan kode dan selama Anda tidak pernah membuat kesalahan kode tunggal dan ... tunggu sebentar, mengapa kamu menggunakan kontrol versi lagi?

— Michael Durrant

24

Kepada semua orang yang mengatakan "komit hanya ketika Anda memiliki pesan yang berguna, dipikirkan dengan matang, dan ketika fitur Anda 100% selesai, dan Anda memiliki unit test untuk itu", saya katakan: Anda masih dalam pola pikir SVN .

Jika Anda menggunakan git , inilah yang saya sebut alur kerja cerdas:

Berkomitmen sesering mungkin . Tulis pesan cepat lama apa saja di sana. Tidak ada yang akan melihatnya.
Setelah mengatakan, 10 komit, Anda telah menyelesaikan fitur yang sedang Anda kerjakan. Sekarang tulis tes dan lakukan tes itu. Atau apa pun yang Anda inginkan. Jika Anda menyukai TDD, tulis tes terlebih dahulu, saya tidak peduli, git juga tidak.
git rebase -idari komit 'berantakan' pertama yang Anda tambahkan dan perbaiki riwayat lokal Anda dengan menekan, mengedit, menghilangkan, dan membersihkan riwayat terkini Anda menjadi komitmen yang logis dan bersih dengan pesan yang bagus .
Setelah pembersihan, minta seseorang untuk menarik dari Anda.
Bilas dan ulangi.

Perhatikan bahwa langkah 3 adalah ketika Anda berakhir dengan komitmen bagus yang Anda kejar, dan bahwa menggunakan SVN Anda harus pantang berkomitmen sampai Anda telah melakukan dua langkah pertama, yang disarankan oleh sebagian besar jawaban lainnya. TKI, Anda tidak ingin memberikan kode yang setengah tertulis, belum teruji pada orang lain, jadi Anda tidak berkomitmen selama seminggu, sampai fitur Anda selesai. Anda tidak menggunakan kontrol versi secara maksimal.

Perhatikan juga bahwa di mana saja antara langkah 1 dan 3, Anda dapat git pushmengubah mirror repo pribadi Anda di server untuk mendapatkan cadangan gratis jika HDD laptop Anda mati.

— Alex Budovski
sumber

Jawaban bagus, saya suka itu. Saya agak takut menggunakan rebase. Berikut ini adalah artikel tentang kesalahannya dan cara memulihkannya bluemangolearning.com/blog/2009/03/…

@id, jika Anda mengubah perubahan pribadi Anda sendiri, seharusnya tidak ada konflik. Selain itu, Anda harus berusaha keras untuk kehilangan apa pun di git.

— Alex Budovski

4

alur kerja saya, batu git

— Nazgob

1

@ Boris: Karena dia jelas berbicara tentang git yang jelas BUKAN subversi

3

Seharusnya bukan pekerjaan penting untuk menulis kalimat yang menyatakan apa yang baru saja Anda lakukan, dan menghancurkan sejarah dengan rebase tampaknya menjengkelkan. Misalkan Anda memperkenalkan bug pada tanggal 5 dari sepuluh komitmen yang tidak diketahui sampai seminggu kemudian. Mampu menjabarkannya dalam satu komit kecil akan banyak membantu Anda.

— Gort the Robot

55

Karena ketika beberapa pengelola yang buruk memburu bug dan menemukan bahwa itu ditambahkan dalam rev. xyz, dia akan ingin tahu apa rev. xyz seharusnya melakukannya.

— Peter Taylor
sumber

38

Kalau begitu dia bisa membaca 5.000 baris spageti yang baru saja aku periksa, JEESH !!! Beberapa orang hanya malas!

— Edward Strange

9

Karena ketika pengisap miskin datang setelah Anda (dalam waktu 3 tahun) dan melihat sejarah dan pergi ... WTF .. WTF .. WTF, ia setidaknya akan memiliki beberapa ide tentang apa yang sedang terjadi. Anda dapat dengan mudah menambahkan komentar seperti "checkin rutin, fitur X, tidak lengkap".

— cepat

3

@ acidzombie24: Karena setiap komit harus mengatakan untuk apa itu - bahkan jika itu "kesalahan ketik dikoreksi", tidak ada gunanya dalam riwayat revisi, kecuali Anda tahu untuk apa revisi itu.

— Orbling

11

@quickly_now, pengisap yang malang bahkan mungkin menjadi diri sendiri. Sayangnya ini adalah salah satu hal yang harus Anda alami sendiri untuk menghargainya sepenuhnya.

2

@acidzombie - mengapa Anda memeriksa perubahan yang tidak lengkap ??

— Edward Strange

35

Anda mengomentari kode sumber Anda, bukan?

Anda menulis komentar terbaik, yang mengatakan mengapa karena kode hanya mengatakan bagaimana ?

Pesan komit adalah komentar seperti itu, dan oleh karena itu sangat penting dan semakin Anda berpikir untuk memperbaikinya, semakin bermanfaat bagi pengelola perangkat lunak di masa mendatang.

Untuk perangkat lunak aktif apa pun, komentar khusus ini pada akhirnya akan ditampilkan dalam sesuatu seperti

gitk --semua sampel

(ditemukan di http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Hal ini memungkinkan pandangan mata burung tentang siapa yang telah bekerja pada perangkat lunak kapan , dan apa yang mereka lakukan.

Perhatikan bahwa ini adalah tujuan akhir untuk komentar komit, yaitu muncul dalam daftar seperti itu yang mengatakan " apa " bagi diri masa depan Anda atau kolega Anda, dan BAHWA adalah alasan mengapa Anda harus berhati-hati dalam menulis pesan komit yang baik.

— user1249
sumber

2

@acidzombie, saya hanya bisa berbicara untuk git, tetapi Anda dapat melakukan dalam langkah-langkah yang sangat kecil secara lokal dan kemudian mengelompokkan mereka bersama-sama dalam satu komit saat mendorong hulu. Pesan komit itu kemudian dapat bersifat deskriptif.

2

@acidzombie, mengapa Anda melakukan jika Anda belum melakukan perubahan yang cukup untuk menjamin komentar? Tolong jelaskan.

2

@ Guru: Karena kontrol versi melindungi kode Anda dari kehilangan, dan bahkan kode yang setengah jadi harus dilindungi.

— Ben Voigt

1

@Ben, komit adalah untuk penyimpanan jangka panjang dan harus secara akurat mencerminkan "potongan" kerja. Perlindungan terhadap kehilangan menurut saya ortogonal untuk kontrol versi, dan harus ditangani oleh sistem cadangan yang sesuai. Saya telah menemukan Time Machine untuk Mac sangat cocok untuk tujuan ini - Saya harap sistem serupa tersedia untuk Windows.

2

+1 Saya penggemar tidak mencemari kontrol sumber saya dengan komitmen yang tidak berarti. Itu membuat pencarian komit tertentu lebih mudah (melalui komentar yang bermanfaat), dan saya tahu bahwa ketika saya memeriksa kode, selalu dalam kondisi kerja. Perangkat lunak pencadangan tradisional adalah opsi yang lebih baik untuk melindungi repositori lokal di antara komitmen saya. Ini berfungsi baik dengan DVCS, tetapi Anda harus ingat bahwa check-in lokal sebenarnya bukan cadangan kode Anda.

— Adam Lear

15

Jika pesan komit tampak bodoh bagi Anda, maka sepertinya Anda menggunakan komit salah.

Komit harus dibuat untuk alasan yang baik - komitmen harus terkait dengan tugas yang telah Anda uraikan untuk fitur yang sedang Anda kerjakan. Apakah tugas itu formal atau hanya dalam pikiran Anda, setiap perubahan yang Anda lakukan harus lebih atau kurang menyelesaikan tugas dan karena itu berfungsi dalam beberapa cara.

Kemudian pesan komit Anda memiliki tujuan yang jauh lebih baik. Jelaskan tugas yang Anda selesaikan dan jika tidak dilacak di tempat lain, mengapa tugas itu diperlukan atau apa tujuannya:

Refactored kelas pengguna untuk enkapsulasi yang lebih baik
Membuat potongan-potongan API sehingga antarmuka dapat digunakan di kelas controller
Mengkonversi kelas database ke kelas abstrak sehingga database tiruan dapat digunakan dalam kasus uji

Kemudian Anda atau pengembang lain dapat menelusuri repositori atau riwayat file dan cukup mudah melihat di mana evolusi tertentu terjadi dan mengapa. Atau, jika revisi tertentu terbukti bersalah karena bug, pesan komit akan memberikan petunjuk tentang mengapa baris itu dimasukkan, sehingga Anda tidak hanya merobeknya dan mungkin mengulangi sesuatu yang dianggap sebagai kesalahan. diperbaiki, dan Anda bisa memperbaikinya dengan cara yang benar.

— NickC
sumber

1

+1, sepertinya dia melakukan terlalu sering atau pada titik berhenti yang buruk. Jika ia hanya menginginkan titik cadangan yang bagus untuk beberapa perubahan eksperimental, ia dapat menggunakan indeks, cabang sementara, mengubah komit sebelumnya alih-alih membuat yang baru, atau bahkan menggunakan buffer undo di editornya.

— Karl Bielefeldt

1

@Karl: Linus IIRC di google talk git-nya mengatakan rata-rata 6 komit dilakukan per hari. Sekarang, saya tidak tahu berapa banyak dianggap banyak, tetapi pada proyek ini sekarang saya berkomitmen ketika saya mendapatkan beberapa refleksi bekerja (saya loop data yang benar, saya tidak melakukan apa-apa dengan itu), setelah saya membuat antarmuka tetapi sebelum serialisasi bekerja. dan saya sekarang bekerja untuk membuat serialisasi berfungsi walaupun saya memiliki antarmuka 2 jam yang lalu. Saya akan melakukan dan mengatakan 'dasar-dasar refleksi' sekali yang berfungsi tetapi pada tiga pertama mengapa saya pernah meninggalkan komentar ketika saya dapat dengan mudah melihat ketika fitur 'bekerja' setiap x melakukan.

Sebenarnya saya dapat menunda sampai saya mendapatkan beberapa tes dasar karena jika tidak, jika saya berkomentar setiap komit bagaimana saya tahu yang mana dari ini memiliki refleksi stabil? 'dasar-dasar refleksi', 'serialisasi refleksi' 'tes serialisasi refleksi' Dengan asumsi serialisasi adalah suatu keharusan itu bisa menjadi yang ke-2 atau ke-3. Tes dapat berarti unit test atau tes dapat berarti pengujian jika bekerja pada kelas dasar yang saya butuhkan. Saya hanya berpikir berkomentar masuk akal ketika saya bisa mengatakan 'dasar-dasar kerja refleksi' daripada menebak mana yang sebenarnya berarti dasar-dasar bekerja. Juga lebih mudah untuk membaca skim / menemukan ketika ada kurang untuk membaca.

@id, seluruh tujuan dari sebuah komit adalah untuk dapat kembali ke sana atau membandingkan perubahan dengannya. Jika Anda perlu melakukan itu dengan komitmen Anda sebelumnya, bagaimana Anda tahu mana yang harus dipilih? Anda tidak perlu menulis novel, di sini. "Antarmuka bekerja," "serialisasi bekerja," dan "bekerja refleksi" baik-baik saja menurut saya. Tidak ada jumlah komit maksimum yang ditetapkan per hari, tetapi jika pesan Anda akan berbunyi seperti "beberapa pekerjaan pada antarmuka" "beberapa pekerjaan lainnya pada antarmuka" "antarmuka hampir selesai", maka Anda melakukan terlalu sering dan sebaiknya hanya menggunakan Indeks.

— Karl Bielefeldt

@ Kararl: Apa indeksnya? saya tahu git memiliki simpanan tetapi saya tidak berpikir Anda berbicara tentang itu. Apa fungsinya?

12

Komentar komitmen tidak menyelesaikan segalanya. Selalu ada kemungkinan mereka menyesatkan sebanyak yang mereka bantu - terutama ketika pengembang marah karena harus memasukkan mereka. Coba ini: anggap mereka seperti jejak remah roti di hutan atau titik jalan pendakian gunung atau pelacak. Jika dilakukan dengan benar, mereka dapat menguraikan jalur yang membingungkan.

Jangan membuat masalah besar dari mereka. Jujur:

"Entitas indeks spasial yang diedit, Daos, dan UI untuk menangani fitur X"
"Tambahan check-in untuk permintaan fitur # 1234 dan bug # 5678"
"Aku merusak bangunan terakhir. Ini adalah file-file yang aku lewatkan."

Tetap pendek dan "gambaran besar". Jika memungkinkan, lihat nomor masalah di sistem fitur / bug Anda. Beberapa UI kontrol versi menyertakan bidang untuk hal semacam ini.

— Hanya sedikit Roger
sumber

2

+1 untuk gagasan menjaganya tetap pendek. Singkat dan sederhana dan cukup baik, sangat bagus.

— cepat

1

IMHO panduan yang lebih baik adalah resep "sesingkat mungkin, selama diperlukan"; karena kadang-kadang memang tidak mungkin untuk tetap singkat tanpa mengorbankan informasi penting

— hvr

11

Ini mengurangi jumlah WTF / menit;)

masukkan deskripsi gambar di sini

yang diterjemahkan menjadi tim yang lebih bahagia (yang tidak membenci Anda), dan hasil tim yang lebih baik berpotensi dengan biaya lebih rendah

— Rook
sumber

4

Saya akan memilih ini jika Anda menjelaskan mengapa ini benar.

— SingleNegationElimination

@TokenMacGuy - Maaf, saya tidak mengikuti.

— Benteng

1

Bagaimana pesan komit ekspresif Mengurangi WTFs / Menit (tentu saja, memang)

— SingleNegationElimination

@TokenMacGuy - Saya pikir itu sudah jelas.

— Benteng

9

Jadi seluruh tim Anda tahu WTF yang Anda lakukan memeriksa perubahan pada pohon proyek.

— Edward Strange
sumber

7

Saya menambahkan pesan komit untuk proyek saya, ketika saya HANYA PENGEMBANG! Karena ketika saya kembali dalam 2 tahun untuk melihat hal-hal ini, saya ingin tahu apa yang saya lakukan saat itu. Saya tahu betul bahwa 99% dari waktu ini tidak akan dilihat. 1% dari waktu itu akan menyelamatkan saya 2 minggu dari penderitaan, dan saya pikir harga memasukkan pesan komit 10 detik bernilai manfaat jangka panjang yang akan saya dapatkan.

— cepat

@quickly_now, bahkan penderitaan ? Apakah kode Anda yang buruk?

1

@quickly_now: Amin untuk itu. Dalam kurun waktu satu atau dua tahun, banyak kode keluar dari saya, apa yang seharusnya dilakukan setiap bulan kemudian, hanya Tuhan yang tahu. Tuhan, dan sejarah revisi saya.

— Orbling

Oh ya. Saya juga setuju. Saya menganggapnya sebagai pengalaman == kerendahan hati.

— Michael Durrant

8

karena jika Anda tidak berlatih memasukkan pesan komit yang layak, Anda akan berakhir seperti rekan saya yang memasukkan pesan seperti

no changes

atau

testing

untuk komit dengan lebih dari seratus file yang diubah (jangan bercanda di sini !!).

Jika Anda menjadi pengembang seperti itu, Anda akan terlihat bodoh di mata seluruh dunia, tidak peduli betapa bodohnya Anda hanya memasukkan pesan.

— stijn
sumber

1

Kedengarannya seperti kandidat sempurna untuk peer review sebelum melakukan, jika saya pernah mendengarnya.

2

oh man, saya sudah bekerja dengan orang-orang semacam ini. Membuatku gila.

— sevenseacat

4

Mengapa Anda berkomitmen jika perubahan tidak berarti?

Cukup lakukan perubahan yang memiliki arti. Misalnya saya melakukan refactoring yang agak besar pada minggu lainnya yang memakan waktu sekitar 3 hari. Saya akan memiliki banyak komitmen selama waktu itu. Beberapa perubahan agak kecil ('berganti nama kelas X ke Y untuk mencerminkan tanggung jawab baru' atau 'pindah metode Z () ke kelas Q') dan yang lain benar-benar besar. Ketika saya selesai dengan fitur / refactoring, saya memeriksa apakah ada komit yang bisa dihancurkan (setidaknya git mendukungnya, tidak tahu tentang alat lain), tetapi biasanya saya membiarkannya apa adanya karena itu membantu nanti.

Saya kira Anda tidak akan melakukan di tengah-tengah mengedit baris, jadi itu harus memiliki arti. Jelaskan apa yang Anda lakukan sejak komit terakhir.

— EricSchaefer
sumber

3

bayangkan suatu kondisi ketika Anda merusak sistem Anda dengan membuat beberapa perubahan dan menyadari hal ini setelah beberapa kali dilakukan oleh tim. Anda tidak ingat apa perubahannya tetapi Anda ingat ada sesuatu yang salah ketika Anda meningkatkan fitur X atau menghapus file dari modul Y.

Namun sayangnya angka revisi tidak memberi tahu Anda ketika Anda mengubah X atau Y. Jadi, pilihan Anda adalah membaca semua kode yang dilakukan selama N hari terakhir atau hanya membaca pesan komit terperinci yang Anda tulis (jauh lebih mudah dibaca daripada kode).

Jadi jika Anda menulis teks yang sama, membosankan, tidak berguna, tidak terkait dalam pesan komit, karena Anda harus, lebih berbahaya daripada memiliki pesan komit. Karena alih-alih menemukan root bug, pesan yang salah akan menyesatkan Anda.

Jadi cobalah untuk menulis pesan komit yang bermakna setiap kali Anda komit yang dapat membantu Anda dan pengelola juga.

— GG01
sumber

Mengapa saya harus melakukan ini selama setiap komit, bukan pada akhir hari, setiap hari atau ketika saya menyelesaikan fitur?

1

mengapa Anda sering melakukan itu, jika itu tidak memiliki alasan "alami"?

Saya komit setiap kali saya membuat beberapa perubahan signifikan, sehingga dapat tercermin dalam repositori dan pengembang lain dapat memeriksa perubahan itu. Tetapi jawaban yang Anda berikan itu membantu untuk mengawasi apa yang dilakukan oleh siapa dan kapan.

— GG01

@ acidzombie24 Nah, jangan melakukan hal-hal setengah jadi kecuali Anda benar-benar harus. Sehingga orang lain dapat melihat apa yang Anda lakukan / kerjakan ketika Anda suatu hari sakit dan tidak ada yang berhasil. Atau agar Anda dapat mengingat di mana Anda tinggalkan ketika Anda harus duduk dalam rapat selama 2 hari. Atau agar Anda lebih mudah menentukan revisi yang rusak membangun dan melihat diff.

— no.

@ Thorbjørn: Mengapa saya tidak ingin melakukan perubahan yang tidak ingin saya ulangi?

3

Jika Anda bekerja dengan orang lain, maka melakukan pesan sangat penting untuk benar-benar melihat apa yang telah dilakukan orang lain: mencari perbedaan untuk masing-masing jauh lebih banyak pekerjaan dan Anda mungkin gagal memahami mengapa seseorang melakukannya. Jika Anda bekerja dengan orang lain dan seseorang (mungkin bukan Anda) harus benar-benar melihat ke belakang, misalnya untuk melacak bagaimana perilaku berubah sejak versi sebelumnya dengan cara yang tidak terduga ... Anda benar-benar membuat hidup lebih sulit dengan tidak menggunakan petunjuk bermanfaat dalam komit pesan.

Jika Anda bekerja sendirian ... pada proyek yang sebagian besar diberi kode 'apa adanya' (misalnya satu situs web atau skrip sederhana) saya dapat lebih atau kurang melihat dari mana Anda berasal. Jika saya mengerjakan sesuatu seperti itu, saya hanya peduli dengan tanggal / waktu atau perubahan terbaru saat melanjutkan mengerjakan sesuatu (Anda memiliki titik untuk dipulihkan, tetapi itu hanya penting selama pengembangan, bukan setelah Anda menerapkannya). Kontrol versi hanyalah cara untuk membuat cadangan dengan beberapa kelebihan - Saya sepenuhnya setuju bahwa tidak menggunakan sistem secara lengkap - tetapi pada beberapa proyek skala kecil, yang mungkin tidak diperlukan.

Pikiran itu muncul di benak saya sebelum Kontrol Versi digunakan dalam dua cara terpisah, satu mendokumentasikan perubahan dalam proyek, dan yang lainnya sebagai uluran tangan bagi pengembang di tempat ... dan keduanya sama sekali berbeda satu sama lain. Pesan komit sangat penting di satu sisi, dan mungkin sebagian besar tidak berguna di sisi lain.

— Inca
sumber

3

Anda melewatkan sesuatu. Ada harus menjadi alasan untuk melakukan komit jika tidak, anda tidak akan melakukannya.

Yang perlu Anda lakukan di komentar adalah memasukkan alasannya ke dalam kata-kata, meskipun hanya itu wip: adding new state objects

— Richard Harrison
sumber

persis. Bahkan jika (seperti yang disebutkan sebelumnya) itu hanya kode Anda 'tidak ingin mengulang' dengan baik itu berarti sesuatu karena itu seharusnya tidak sulit untuk menulis ringkasan yang super cepat.

— sevenseacat

2

Seperti banyak yang lain, saya melakukan sedikit pengkodean di waktu luang dan menggunakan sistem kontrol revisi untuk melacak perkembangan dan perubahan saya. Jumlah waktu luang yang saya miliki sangat bervariasi dari minggu ke minggu dan bulan ke bulan. Banyak kali ketika saya tidak punya waktu untuk kode pada proyek selama berminggu-minggu atau bahkan berbulan-bulan, dan waktu seperti yang saya miliki biasanya berkisar antara 10 menit (hari biasa) hingga 40 menit (hari baik). Kondisi itu tentu saja tidak bagus - terutama untuk masalah debugging.

Sangat penting untuk membuat catatan yang tidak akan hilang, dan mudah diambil. Pada akhir setiap sesi, pekerjaan sesi akan dilakukan dengan pesan rinci. Saya kemudian bisa melalui sejarah komit dan melacak kemajuan dan proses berpikir saya. Ini memungkinkan saya untuk menemukan di mana saya berada minggu lalu, atau bulan lalu dengan paling sedikit waktu berharga yang hilang.

Poin yang saya coba ilustrasikan adalah bahwa pesan komit yang baik membantu Anda (dan siapa pun yang datang setelah Anda) untuk mencari tahu apa yang telah terjadi, apa yang telah terjadi, ke mana segala sesuatu berjalan dan di atas segalanya mengapa.

— Sparky
sumber

2

Pikirkan hal ini secara logis selama satu menit. Ketika Anda melakukan itu berarti sesuatu telah dilakukan. Jika Anda tidak meninggalkan pesan, bagaimana orang lain akan tahu apa yang telah dilakukan?

— Sergio
sumber

Sepintas pada kode saya yang sangat jelas dan mereka akan langsung tahu segala sesuatu yang dilakukannya dan semua tes luar biasa melewati 100%. Maaf, saya sedang dalam suasana humor malam ini [jadi saya MENYEBARKAN];)

— Michael Durrant

1

Jika Anda tidak berkomentar tentang komitmen Anda, Anda mungkin tergoda untuk berkomentar tentang perubahan pada sumbernya. Pada waktunya, itu dapat mengacaukan sumbernya.

— Joris Geer
sumber

2

Saya tidak tergoda untuk melakukan itu

1

Pesan komit adalah cara cepat untuk mengetahui apa yang terjadi pada check-in itu dan akan membantu pengembang lainnya di tim Anda ketika mereka ingin mengetahui aspek kode mana yang diubah di mana revisi (untuk alasan tertentu).

Pada catatan terkait, saya sarankan menentukan nomor kasus pelacak bug (saya harap Anda menggunakan satu) dalam pesan komit, sehingga akan sangat membantu bagi masa depan untuk dengan mudah melacak hal-hal.

— Mahesh Velaga
sumber

1

Sehingga pengelola kode itu 1 tahun kemudian tahu siapa yang harus diburu untuk kode mengerikan itu. :)

— talonx
sumber

Itulah blamegunanya fitur vcs.

— Peter Taylor