Jawaban:
Alat kontrol versi cukup kuat untuk membuat orang tersebut melihat file apa yang dimodifikasi, dan metode apa yang ditambahkan. Ini berarti bahwa secara umum, pesan log yang secara sederhana menduplikasi apa yang sudah ada telah mencemari log.
Anda menambahkan somefuncmetode untuk memenuhi persyaratan, yaitu:
Ini berarti bahwa pesan log Anda harus menjelaskan fitur / bug apa yang terpengaruh atau apa tujuan refactoring.
Jangan lupa untuk menambahkan TIKET / MASALAH NOMOR .
Jika Anda memiliki fitur atau sistem pelacakan masalah dengan # tiket atau # masalah , pastikan untuk memasukkan ID itu # di komit. Itu akan membantu siapa saja yang ingin tahu lebih banyak tentang fitur atau masalah yang sedang Anda kerjakan.
Dalam proyek terakhir saya, ada makro yang dikembangkan untuk memastikan bahwa 7 digit pertama dari komentar adalah nomor masalah yang valid dari pencarian yang jelas (sistem pelacakan masalah / fitur kami).
Saya melakukan hal semacam itu ketika saya melakukan mis perbaikan untuk cacat yang diperlukan perubahan ke beberapa file. Ini membuatnya sedikit lebih mudah untuk mengetahui apa yang sebenarnya berubah tanpa melihat file individual di changeset.
Untuk perubahan file tunggal, ini tidak perlu.
Baris pertama selalu merupakan deskripsi tingkat tinggi dari perubahan, seperti tautan ke cerita pengguna atau cacat.
Jika itu informasi yang relevan dalam narasi pesan komit, maka ya, sertakan. Jika satu-satunya informasi adalah nama file itu sendiri, maka tidak.
Misalnya, ini masuk akal: "Memindahkan fungsi build_foo () dari fooutil.c ke foobase.c, karena sebagian besar program yang ingin menggunakan build_foo () sudah termasuk foobase.c"
Yang ini tidak: "Memperbarui build_foo () di fooutil.c untuk mengambil parameter bar."
Saya ingin menambahkan perspektif yang berbeda di sini.
Jawaban saya Ya atau Tidak. Tetapi secara umum saya akan mengatakan Ya.
Kontrol versi memang cukup kuat untuk mengetahui file mana yang sedang diperbarui. Tapi, ketika kita melakukannya
$ git log
Kami hanya melihat pesan komit. Itulah yang dilakukan kebanyakan orang.
Dengan melihat ke dalam log itu sendiri. Itu menambah konteks tambahan untuk itu. Sebagai contoh:
readme.md: Fix typo detected by language tool
Lebih baik dari
Fix typo detected by language tool
Namun, jika perubahan menelurkan banyak file, maka setidaknya sebutkan komponen yang sedang diedit.
API: Fix reset password not sent email to user
Dengan membacanya, kita tahu bahwa kesalahan yang diperbaiki adalah pada komponen API, dan mungkin di bawah direktori API di basis kode.
Namun kita bisa melakukannya
$ git show COMMIT_ID --name-only
tetapi menambahkan lebih banyak langkah hanya untuk mendapatkan file.
Satu-satunya waktu saya bisa melihat ini menjadi berguna untuk checkin file tunggal adalah jika Anda telah membuat perubahan pada fungsi yang digunakan di banyak tempat dalam file dengan hasil bahwa diff berantakan. Bahkan kemudian saya akan menempatkan pelacak perubahan # dan deskripsi teks perubahan sederhana terlebih dahulu.
Saya pikir pertanyaan sebenarnya di sini adalah seberapa terbatasnya lingkup komitmen Anda? Jika Anda menunggu untuk melakukan berbagai perubahan yang tidak terkait bersama dalam satu komit, maka Anda mungkin merasa perlu menentukan file apa yang diubah untuk tujuan apa.
Namun, jika Anda hanya membuat komit yang lebih sempit lebih sering, maka satu komit akan menjelaskan file mana yang dimodifikasi dan Anda bisa dengan mudah menggambarkan apa tujuan pesan itu.
Lebih banyak komitmen, lebih sering. Itulah cara Anda dapat menghindari begitu bertele-tele dalam pesan Anda.