Ada hari kita menukar warna butang, membaiki borang dan mengemas teks halaman dalam satu sesi. Semuanya terasa seperti satu kerja kerana dibuat sebelum makan tengah hari. Tetapi apabila tiga perkara itu masuk ke satu commit bernama update website, kita meninggalkan teka-teki untuk diri sendiri pada minggu depan.
Satu perubahan, satu alasan
Commit yang baik tidak semestinya menyentuh satu fail sahaja. Ia boleh menyentuh lima fail asalkan semuanya menjawab satu tujuan: contohnya “baiki pengesahan borang hubungi”. Kod JavaScript, teks ralat dan gaya mesej boleh bergerak bersama kerana pengguna mengalami semuanya sebagai satu pembetulan. Gambar profil baharu pula patut berada dalam commit lain.
Sebelum commit, jalankan git diff dan tanya: jika perubahan ini perlu dibatalkan, adakah saya mahu membatalkan semuanya serentak? Jika jawapannya tidak, pecahkan kerja itu. git add -p membantu memilih bahagian fail secara kecil apabila dua perubahan bercampur.
Tulis mesej yang menerangkan sebab
Fix contact form validation lebih berguna daripada fix. Jika perkara yang dibaiki tidak jelas, tambahkan ayat ringkas dalam isi mesej commit. Kita tidak perlu menulis novel; cukup untuk membolehkan orang lain faham apa yang berubah tanpa membuka setiap baris. Sebelum push, semak juga git status supaya gambar sementara atau fail rahsia tidak terselit.
Bayangkan rakan perlu revert pembetulan borang tetapi mengekalkan kemas kini footer. Jika dua kerja itu ada dalam commit berasingan, tindakannya jelas. Jika bercampur, dia perlu menyunting semula dalam keadaan tergesa-gesa. Contoh ini membantu menentukan sempadan commit lebih baik daripada peraturan “maksimum sepuluh baris”.
Amalan ini terasa perlahan ketika menulis. Ia menjimatkan masa semasa code review, ketika mencari punca pepijat, dan sewaktu perlu kembali kepada versi yang berfungsi. Panduan GitHub tentang commit dan branch menerangkan aliran asas itu dengan baik.