Jawaban:
saya menggunakan
[Abc]: Message.
Dengan Add, Mod (ify), Ref (actoring), Fix, Rem (ove) dan Rea (dability) maka mudah untuk mengekstrak logfile.
Contoh:
Add: New function to rule the world.
Mod: Add women factor in Domination.ruleTheWorld().
Ref: Extract empathy stuff to an abstract class.
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.
Rem: freeSpeech is not used anymore.
Rea: Removed old TODO and extra space in header.
Jika saya memiliki lebih dari satu baris, saya mengurutkannya dengan yang paling penting terlebih dahulu.
Mod
dan Ref
? Terkadang saya hanya melakukan perbaikan kecil yang merupakan semacam refactoring.
Mod
adalah tentang menambahkan sesuatu atau mengubah perilaku, Ref
adalah tentang mengubah hal-hal internal yang tidak menambah fonksionalitas, menambahkan API, dll. Contoh: jika saya memiliki add(Object)
fungsi dan saya mengimplementasikan suatu add(List<Object>)
fungsi, saya akan berkomentar Mod
. Nanti saya menghapus duplikasi dan menggunakan langsung add(Object)
di add(List<Object>)
kemudian saya akan gunakan Ref
.
Kami menggunakan yang berikut ini:
[ID Tiket di JIRA]: [Pesan: Apa yang dilakukan] Misalnya - ABC-123: Menambahkan kemampuan untuk mengonfigurasi presentasi per wilayah.
Dalam hal ini dengan integrasi yang tepat Anda akan bisa mendapatkan file yang diubah / dihapus / ditambahkan di pelacak masalah Anda. Namun, perlu diketahui bahwa Anda harus mencegah sesuatu seperti ABC-123: Selesai atau ABC-123: Diperbaiki dengan filter jika memungkinkan.
Ada satu aturan sederhana, yang merupakan konvensi yang diikuti oleh banyak (jika tidak semua) SCM dan oleh sebagian besar alat yang bekerja dengan SCM:
Baris pertama dari pesan komit adalah ringkasan pendek, sedangkan sisanya dari pesan berisi detail.
Jadi, sebagian besar alat hanya menampilkan baris pertama, dan menampilkan seluruh pesan sesuai permintaan.
Penyalahgunaan khas pesan komit adalah daftar perubahan peluru (hanya peluru pertama yang akan ditampilkan). Penyalahgunaan lain adalah menulis pesan terperinci loooong pada satu baris.
Jadi, jika ada satu hal yang harus ditegakkan, saya akan mengatakan itu adalah panjang maksimum dari baris pertama.
Secara pribadi saya belum pernah melihat template komit umum layak digunakan. Komentar harus secara singkat mengatakan apa yang terkait dengan komit misalnya fitur apa / perbaikan bug atau pernyataan singkat tentang mengapa perubahan dilakukan.
Informasi tentang apa yang dilakukan tidak boleh dimasukkan, ini dapat ditentukan oleh sistem SCM. Lebih banyak informasi bug / fitur termasuk di mana bug dan fitur dilacak.
Saat memperbarui laporan bug setelah komit, saya merasa baik juga menyatakan revisi komit bersama dengan komentar dalam laporan bug. Dengan cara ini Anda dapat menemukan jalan Anda dari komit komentar ke laporan bug, dan untuk setiap komentar pada laporan bug Anda dapat menemukan apa yang dilakukan, tetapi Anda tidak menduplikasi informasi dengan memilikinya pada laporan bug dan komit pesan.
Kemudian ketika melihat riwayat revisi untuk suatu file, Anda memiliki pesan singkat yang bagus yang menggambarkan riwayat tetapi juga tahu di mana mencari lebih banyak laporan bug atau deskripsi tugas untuk lebih jelasnya.
Di Git adalah mungkin untuk menegakkan hampir semua hal dengan kait Git . Lihat contoh di .git / hooks untuk ide.
Adapun pesan, dalam kasus yang sangat umum, Anda ingin memasukkan informasi yang cukup tentang masalah yang Anda pecahkan DAN solusinya sendiri untuk dapat menemukan dan mengidentifikasi komit ini nanti. Dalam kebanyakan kasus, masalah akan dirujuk ke nomor bug (dengan integrasi yang tepat dengan sistem pelacakan bug Anda). Jika Anda memiliki sistem lain yang terintegrasi dengan proses Anda (seperti sistem pelacakan tinjauan kode), sertakan juga bit yang sesuai:
Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.
BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none
TAPI Anda ingin tetap sederhana. Jika tidak, orang akan menemukan cara untuk menipu sistem dan menghasilkan pesan komit yang tidak berguna.
Kami menggunakan templat yang berisi
Dua yang pertama dihilangkan sebagian besar waktu namun (kadang-kadang ketiganya) jadi itu bukan masalah besar.
Saya biasanya memiliki pengenal yang ada dalam sistem pelacakan tiket yang saya gunakan atau gambaran umum tingkat tinggi sebagai baris pertama. Lalu saya memiliki poin "peluru" item baris dari perubahan spesifik pada komit. Jadi saya dapat sesuatu seperti:
MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity
Ini adalah format komit terbersih yang saya suka. Langsung dan to the point. Alasan lain saya melakukannya dengan cara ini adalah bahwa jika saya ingin membuat log perubahan, saya bisa mengambil semua pesan komit dan menguraikannya ke dalam log perubahan dengan sangat mudah.
[ticketId] [ABC] [topicId] [WIP] Pesan, di mana:
Contoh:
[# 452567] [tambahkan] [menu_item] item baru - buku tamu
[# 452363] [fix] [banner_top] [WIP] 1024x300 dapat digunakan sekarang
[# 452363] [fix] [banner_top] 500x200 dapat digunakan sekarang
[ # 452713] [rem] [halaman] iklan tengah kiri