คุณสามารถแนะนำเทมเพลต / แนวทางการส่งข้อความที่ดีเพื่อบังคับใช้ใน บริษัท ได้หรือไม่? [ปิด]

ใน Git เป็นไปได้ที่จะตั้งค่าและบังคับใช้เทมเพลตการคอมมิท

คุณสามารถแนะนำเทมเพลต / แนวทางปฏิบัติที่ดีเพื่อบังคับใช้ใน บริษัท ได้หรือไม่?

ฉันใช้

[Abc]: Message.

ด้วย Add, Mod (ify), Ref (actoring), Fix, Rem (ove) และ Rea (dability) ดังนั้นจึงเป็นเรื่องง่ายที่จะแยก logfile

ตัวอย่าง:

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.  

หากฉันมีมากกว่าหนึ่งบรรทัดฉันจะเรียงลำดับพวกเขาด้วยสิ่งที่สำคัญที่สุดก่อน

เราใช้สิ่งต่อไปนี้:

[ID ตั๋วใน JIRA]: [ข้อความ: สิ่งที่ได้กระทำ] ตัวอย่างเช่น - ABC-123: เพิ่มความสามารถในการนำเสนอการกำหนดค่าต่อภูมิภาค

ในกรณีนี้ด้วยการรวมที่เหมาะสมคุณจะสามารถได้รับการเปลี่ยนแปลง / ลบ / เพิ่มไฟล์ในตัวติดตามปัญหาของคุณ อย่างไรก็ตามโปรดทราบว่าคุณควรป้องกันบางสิ่งเช่นABC-123: DoneหรือABC-123: แก้ไขด้วยตัวกรองถ้าเป็นไปได้

มีกฎง่าย ๆ ข้อเดียวซึ่งเป็นแบบแผนตามด้วย SCM จำนวนมาก (ถ้าไม่ใช่ทั้งหมด) และโดยเครื่องมือส่วนใหญ่ที่ทำงานกับ SCM:

บรรทัดแรกของข้อความคอมมิทเป็นการสรุปสั้น ๆ ในขณะที่ข้อความที่เหลือนั้นมีรายละเอียด

ดังนั้นเครื่องมือส่วนใหญ่จะแสดงบรรทัดแรกเท่านั้นและแสดงข้อความทั้งหมดตามต้องการ

การใช้ข้อความโดยทั่วไปในทางที่ผิดนั้นเป็นรายการหัวข้อย่อยของการเปลี่ยนแปลง (แสดงหัวข้อย่อยแรกเท่านั้นที่จะแสดง) การใช้ในทางที่ผิดก็คือการเขียนข้อความแบบละเอียด loooong ในบรรทัดเดียว

ดังนั้นหากมีสิ่งหนึ่งที่จะบังคับใช้ฉันจะบอกว่ามันเป็นความยาวสูงสุดของบรรทัดแรก

โดยส่วนตัวฉันไม่เคยเห็นเทมเพลตทั่วไปที่ควรค่าแก่การใช้ ความคิดเห็นควรสรุปให้ชัดเจนว่าคำมั่นสัญญานั้นเกี่ยวข้องกับอะไรเช่นฟีเจอร์ / แก้ไขข้อผิดพลาดหรือแถลงสั้น ๆ ว่าเหตุใดการเปลี่ยนแปลงจึงเกิดขึ้น

ไม่ควรรวมข้อมูลเกี่ยวกับสิ่งที่ถูกคอมมิตซึ่งสามารถกำหนดได้โดยระบบ SCM ข้อมูลข้อบกพร่อง / คุณสมบัติเพิ่มเติมอยู่ในที่ที่เคยมีการติดตามข้อบกพร่องและคุณสมบัติ

เมื่ออัปเดตรายงานข้อผิดพลาดหลังจากการส่งข้อมูลฉันพบว่าเป็นการดีที่จะระบุการมอบหมายการแก้ไขพร้อมกับความคิดเห็นในรายงานข้อผิดพลาด วิธีนี้คุณสามารถค้นหาวิธีของคุณจากการคอมเม้นท์คอมเม้นท์ไปจนถึงรายงานบั๊กและสำหรับแต่ละคอมเม้นท์ในรายงานบั๊กคุณสามารถค้นหาสิ่งที่ได้ทำไปแล้ว แต่คุณไม่ต้องทำซ้ำข้อมูล

จากนั้นเมื่อดูประวัติการแก้ไขสำหรับไฟล์คุณมีข้อความสั้น ๆ ที่อธิบายประวัติ แต่ยังรู้ว่าจะหารายงานข้อผิดพลาดรายละเอียดเพิ่มเติมหรือคำอธิบายงานสำหรับรายละเอียดเพิ่มเติมได้ที่ไหน

ใน Git มันเป็นไปได้ที่จะบังคับใช้อะไรเกือบกับGit ตะขอ ตรวจสอบตัวอย่างใน. git / hooks เพื่อหาแนวคิด

สำหรับข้อความในกรณีทั่วไปคุณต้องการรวมข้อมูลที่เพียงพอเกี่ยวกับปัญหาที่คุณแก้ไขและวิธีการแก้ปัญหาเพื่อให้สามารถค้นหาและระบุการกระทำนี้ในภายหลัง ในกรณีส่วนใหญ่ปัญหาจะได้รับการอ้างอิงหมายเลขข้อบกพร่อง (ด้วยการรวมที่เหมาะสมกับระบบติดตามบั๊กของคุณ) หากคุณมีระบบอื่นที่กระบวนการของคุณผสานรวมกับ (เช่นระบบติดตามตรวจสอบรหัส) ให้รวมบิตที่เหมาะสมด้วย:

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

แต่คุณต้องการให้มันง่าย มิฉะนั้นคนจะหาวิธีที่จะโกงระบบและสร้างข้อความกระทำที่ไร้ประโยชน์

เราใช้เทมเพลตที่มี

• หมายเลข id ของข้อบกพร่อง / คุณสมบัติ / แก้ไข
• ตอบใช่ / ไม่ใช่อธิบายว่ามีการทดสอบรหัสหรือไม่
• และส่วนรายละเอียดสำหรับคำอธิบายสั้น ๆ ของความตั้งใจของการกระทำ

สองคนแรกจะถูกละไว้โดยส่วนใหญ่อย่างไรก็ตาม (บางครั้งทั้งสาม) ดังนั้นมันจึงไม่ใช่เรื่องใหญ่

โดยทั่วไปฉันมีตัวระบุที่อยู่ในระบบติดตามตั๋วที่ฉันใช้หรือภาพรวมระดับสูงเป็นบรรทัดแรก จากนั้นฉันมีรายการ "กระสุน" ของรายการการเปลี่ยนแปลงเฉพาะในการส่งมอบ ดังนั้นฉันสามารถทำสิ่งที่ชอบ:

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

นี่คือรูปแบบการส่งข้อมูลที่สะอาดที่สุดที่ฉันชอบ มันตรงและตรงประเด็น อีกเหตุผลหนึ่งที่ฉันทำเช่นนี้คือถ้าฉันต้องการสร้างบันทึกการเปลี่ยนแปลงฉันสามารถนำข้อความการส่งทั้งหมดและแยกวิเคราะห์ลงในบันทึกการเปลี่ยนแปลงได้อย่างง่ายดายมาก

[ticketId] [ABC] [topicId] [WIP] ข้อความที่:

• ticketId - id ของไอเท็มในที่เก็บภารกิจ
• ABC - เพิ่ม (คุณสมบัติ), แก้ไข (แก้ไขข้อผิดพลาด), str (โครงสร้าง), dep (อ้างอิง) rem (ความเข้ากันไม่ได้ / ลบย้อนหลัง), rea (อ่านได้), ref (refactoring)
• topicId - สามารถเป็นตัวเลือกงานสำหรับเจนกินส์และ / หรือชื่อสาขาและ / หรือชื่อหัวข้อสำหรับ gerrit
• WIP - กำลังดำเนินการอยู่หรือไม่ (เช่นอาจต้องรวมสิ่งนี้อย่างต่อเนื่อง)
• ข้อความ - รายละเอียดของการแก้ไข

ตัวอย่าง:
[# 452567] [เพิ่ม] [เมนู_item] รายการใหม่ - สมุดเยี่ยม
[# 452363] [แก้ไข] [banner_top] [WIP] 1024x300 สามารถใช้งานได้ในขณะนี้
[# 452363] [แก้ไข] [banner_top] 500x200 สามารถใช้งานได้ในขณะนี้
[ # 452713] [rem] [หน้า] เหลือโฆษณาตอนกลาง