Şirkette uygulamak için iyi bir taahhüt mesajı şablonu / kuralları önerebilir misiniz? [kapalı]

Git'te iyi bir taahhüt şablonu ayarlamak ve uygulamak mümkündür.

Şirkette uygulamak için iyi bir taahhüt şablonu / kuralları önerebilir misiniz (tercihen tartışmalı olarak)?

kullanırım

[Abc]: Message.

Add, Mod (ify), Ref (aktör), Fix, Rem (ove) ve Rea (dability) ile logfile ayıklamak kolaydır.

Örnek :

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.  

Eğer bir çizgiden fazlası varsa, ilk önce onları en önemlisi ile sıralarım.

Aşağıdakileri kullanıyoruz:

[JIRA'da Bilet Kimliği]: [Mesaj: Ne yapıldı] Mesela - ABC-123: Sunumu bölge başına yapılandırma yeteneği eklendi.

Bu durumda, uygun entegrasyon ile sorun izleyicinizde değiştirilmiş / silinmiş / eklenmiş dosyaları elde edebileceksiniz. Ancak, ABC-123: Done veya ABC-123: Mümkünse filtrelerle düzeltilmiş gibi bir şeyi engellemeniz gerektiğini unutmayın .

Çok sayıda (tümü olmasa da) SCM'lerin ve SCM'lerle çalışan çoğu aracın izlediği bir kural olan basit bir kural vardır:

İleti mesajının ilk satırı kısa bir özet, iletinin geri kalanı ayrıntıları içerir.

Bu nedenle, çoğu araç yalnızca ilk satırı görüntüler ve talep üzerine tüm mesajı görüntüler.

Taahhüt mesajının tipik olarak kötüye kullanılması, değişikliklerin madde işareti listesidir (yalnızca ilk madde işareti gösterilecektir). Başka bir yanlış kullanım, tek bir satıra loooong ayrıntılı bir mesaj yazmaktır.

Bu yüzden, uygulanacak bir şey varsa, ilk satırın maksimum uzunluğu olduğunu söyleyebilirim.

Şahsen, kullanmaya değer bir genel taahhüt şablonu görmedim. Yorum, söz konusu komisyonların neyle ilgili olduğunu açıkça belirtmelidir; örneğin, hangi özellik / hata düzeltme veya değişikliklerin neden yapıldığına dair kısa bir açıklama.

Neyin işlendiğine dair bilgi dahil edilmemelidir, bu scm sistemi tarafından belirlenebilir. Daha fazla hata / özellik bilgisi, bugların ve özelliklerin takip edildiği yere aittir.

Bir taahhütten sonra bir hata raporunu güncellerken, hata raporundaki yorumların yanı sıra taahhüt revizyonunu da belirtmek iyi olur. Bu yolla, yorumdan hata raporuna kadar yolunuzu bulabilir ve hata raporundaki her yorum için neyin işlendiğini bulabilirsiniz ancak bilgileri hem hata raporunda hem de onay mesajında ​​bulundurarak çoğaltamazsınız.

Ardından, bir dosyanın revizyon geçmişini görüntülerken, geçmişi açıklayan kısa mesajlarınız var ancak daha fazla ayrıntı için hata raporlarını veya görev tanımlarını nerede arayacağınızı da biliyorsunuz.

Git'te Git kancalarıyla neredeyse her şeyi uygulamak mümkündür . Fikir için .git / hooks'daki örnekleri inceleyin.

Mesaj gelince, çok genel bir durumda, çözdüğünüz problem ve daha sonra bu taahhüdü bulup tanımlayabilmek için çözümün kendisi hakkında yeterli bilgi eklemek istersiniz. Çoğu durumda, sorun bir hata numarasına atıfta bulunacaktır (hata izleme sisteminizle doğru entegrasyon ile). İşleminizle bütünleştirilen başka sistemleriniz varsa (kod inceleme izleme sistemi gibi), uygun bitleri de ekleyin:

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

AMA basit tutmak istiyorsun. Aksi takdirde, insanlar sistemi aldatmanın ve işe yaramaz mesajlar üretmenin bir yolunu bulacaktır.

İçeren bir şablon kullanıyoruz

• Hata / özellik / düzeltmenin kimlik numarası
• Kodun test edilip edilmediğini açıklayan bir evet / hayır
• Ve taahhüdün amacının kısa bir açıklaması için bir detay bölümü

İlk iki, ancak çoğu zaman (üçü bazen) çıkarıldı, bu yüzden bu gerçekten büyük bir anlaşma değil.

Genelde, kullandığım bilet izleme sisteminde veya ilk satırda yüksek düzeyde bir genel bakışta bulunan tanımlayıcıya sahibim. Sonra taahhütte belirli bir değişimin "madde işareti" noktaları var. Böylece şöyle bir şey olabilir:

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

Bu, sevdiğim en temiz taahhüt formatı. Bu doğrudan ve konuya. Bunu yapmamın bir diğer nedeni de değişiklik günlüğü oluşturmak istersem, tüm taahhüt mesajlarını alıp kolayca değişiklik günlüğüne ayrıştırmamdır.

[ticketId] [ABC] [topicId] [WIP] Mesaj, nerede:

• ticketId - görev havuzundaki bir öğenin kimliği
• ABC - add (özellik), düzeltme (bugfix), str (yapı), dep (bağımlılık) rem (geriye dönük uyumsuzluk / kaldırma), rea (okunabilirlik), ref (yeniden düzenleme)
• topicId - jenkins ve / veya şube adı ve / veya gerrit için konu adı için bir iş seçicisi olabilir
• WIP - devam eden / devam etmeyen işler (yani Sürekli Entegrasyon bunu gerektirebilir)
• mesaj - değişikliğin detayı

Örnekler:
[# 452567] [add] [menu_item] yeni ürün - ziyaretçi defteri
[# 452363] [fix] [banner_top] [WIP] 1024x300 şimdi kullanılabilir
[# 452363] [fix] [banner_top] 500x200 şimdi kullanılabilir
[ # 452713] [rem] [sayfa] orta reklam bıraktı