Bisakah Anda merekomendasikan templat pesan / panduan pesan yang baik untuk ditegakkan di perusahaan? [Tutup]


38

Di Git dimungkinkan untuk mengatur dan menerapkan templat komit yang baik.

Bisakah Anda merekomendasikan (lebih baik dengan argumentasi) templat / pedoman komit yang baik untuk ditegakkan di perusahaan?

Jawaban:


42

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.


1
+1 Itu adalah cara yang bagus untuk menghadapinya dan Anda dapat dengan mudah menerima perubahan.
Sardathrion

12
EK! Anda menghilangkan kebebasan berbicara!
CaffGeek

1
Bisakah Anda jelaskan beberapa perbedaan antara Moddan Ref? Terkadang saya hanya melakukan perbaikan kecil yang merupakan semacam refactoring.
yegle

2
@Yegle Modadalah tentang menambahkan sesuatu atau mengubah perilaku, Refadalah 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.
rangzen

14

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.


+1 untuk perbaikan bug tetapi bagaimana dengan fitur baru? Kecuali jika semua fitur baru juga dibuat di
JIRA

3
@Sathathrion - Secara pribadi saya akan membuat pelacak untuk fungsi baru di JIRA. Kami melakukan ini dengan Bugzilla dan memberi tim uji (dan semua orang) visibilitas yang baik dari segala sesuatu yang dimasukkan ke dalam rilis dan meminimalkan hal-hal yang keluar ketika mereka belum diuji / kode ditinjau / apa pun.
Jon Hopkins

@JonHopkins: Meskipun pelacak bug dapat digunakan untuk fitur baru, itu mungkin bukan alat yang ideal. Tentu saja, jarak tempuh Anda akan bervariasi ^ _ ~
Sardathrion - Reinstate Monica

3
Saya mulai menyukai memiliki tiket yang ditugaskan untuk setiap komit (beberapa tiket dengan mudah dapat memiliki beberapa komit, tentu saja): ini adalah cara yang sangat sederhana untuk mendapatkan lebih banyak informasi latar belakang ketika memeriksa kode nanti. "Mengapa mereka melakukan itu?" jauh lebih mudah untuk dijawab ketika Anda memiliki komentar komit dan entri pelacakan masalah.
Joachim Sauer

Bukankah lebih baik melakukan tiket di cabang terpisah?
Tamás Szelei

11

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.


Saya belum pernah melihat alasan untuk menulis pesan komit yang panjang dan terperinci di Git sama sekali. Info terperinci ada di pelacak masalah, dan pesan komit saya hanyalah deskripsi satu kalimat dari perubahan (kecil) yang saya buat pada komit itu.
Marnen Laibow-Koser

9

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.


4
Banyak alat bug akan memungkinkan Anda menautkan langsung ke revisi di alat SCM Anda jika Anda memasukkan detail dalam format yang benar. Demikian pula, banyak alat SCM akan terhubung langsung ke database bug jika Anda memasukkan detail bug dalam format yang benar. IMO, selama kamu melakukan ini, maka kamu emas.
Dean Harding

4

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.


0

Kami menggunakan templat yang berisi

  • Nomor id bug / fitur / perbaikan
  • A ya / tidak menggambarkan apakah kode diuji atau tidak
  • Dan bagian detail untuk deskripsi singkat tentang niat komit

Dua yang pertama dihilangkan sebagian besar waktu namun (kadang-kadang ketiganya) jadi itu bukan masalah besar.


0

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.


0

[ticketId] [ABC] [topicId] [WIP] Pesan, di mana:

  • ticketId - id suatu item dalam repositori tugas
  • ABC - tambah (fitur), perbaiki (perbaikan bug), str (struktur), dep (ketergantungan) rem (mundur tidak kompatibel / hapus), rea (keterbacaan), ref (refactoring)
  • topicId - bisa menjadi pemilih pekerjaan untuk jenkins dan / atau nama cabang dan / atau nama topik untuk gerrit
  • WIP - bekerja dalam proses / atau tidak (yaitu Integrasi Berkelanjutan mungkin memerlukan ini)
  • pesan - detail modifikasi

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


Jawaban Anda akan lebih kuat jika Anda menjelaskan mengapa Anda merasa ini adalah format yang baik. Meskipun nilai format ini mungkin jelas bagi Anda, nilainya tidak terlalu jelas bagi orang lain.

terima kasih atas komentarnya - ya saya akan jelaskan lebih terinci segera - Saya hanya ingin memulai dengan fakta - akan menjadi fitur tumpukan yang baik bahwa Anda dapat menandatangani jawaban dengan WIP :)
laplasz

Untuk 'Work In Progress' - apakah ini catatan untuk Anda sendiri bahwa Anda akan kembali dan mengubah, atau apakah Anda berkomitmen untuk menguasainya? Jika demikian, mengapa?
JBRWilkinson

CI workflow mungkin memerlukannya - jadi Anda mendorong untuk menguasai perubahan yang belum selesai hanya untuk mengintegrasikannya sesegera mungkin
laplasz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.