ในบรรทัดแรกของข้อความคอมมิทคอมมิตฉันมีนิสัยพูดถึงไฟล์ที่แก้ไขหากการเปลี่ยนแปลงไม่ครอบคลุมหลายไฟล์ตัวอย่างเช่น:
Add [somefunc] to [somefile]
นี่เป็นสิ่งที่ดีที่จะทำหรือไม่จำเป็น?
ในบรรทัดแรกของข้อความคอมมิทคอมมิตฉันมีนิสัยพูดถึงไฟล์ที่แก้ไขหากการเปลี่ยนแปลงไม่ครอบคลุมหลายไฟล์ตัวอย่างเช่น:
Add [somefunc] to [somefile]
นี่เป็นสิ่งที่ดีที่จะทำหรือไม่จำเป็น?
คำตอบ:
เครื่องมือควบคุมเวอร์ชันมีประสิทธิภาพเพียงพอที่จะให้บุคคลนั้นเห็นว่าไฟล์ใดถูกแก้ไขและวิธีการใดที่ถูกเพิ่มเข้ามา หมายความว่าโดยทั่วไปแล้วข้อความบันทึกซึ่งทำซ้ำอย่างชัดเจนว่ามีอยู่แล้วกำลังก่อให้เกิดมลพิษ
คุณได้เพิ่มsomefuncวิธีการเพื่อตอบสนองความต้องการเช่น:
ซึ่งหมายความว่าข้อความบันทึกการทำงานของคุณต้องอธิบายว่าคุณสมบัติ / ข้อบกพร่องใดบ้างที่ได้รับผลกระทบหรือจุดประสงค์ของการปรับโครงสร้างใหม่
ไม่ได้มีวิธีมากมายในการตรวจสอบเนื้อหาของการกระทำ ความคิดเห็นควรอธิบายถึงวัตถุประสงค์ของการกระทำ
อย่าลืมที่จะเพิ่มTICKET / ฉบับที่
หากคุณมีคุณสมบัติหรือระบบติดตามปัญหาที่มีตั๋ว # หรือปัญหา #ให้แน่ใจว่าได้ใส่ ID # นั้นในการส่งมอบ ซึ่งจะช่วยให้ทุกคนที่ต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับคุณสมบัติหรือปัญหาที่คุณกำลังทำอยู่
ในโครงการสุดท้ายของฉันมีแมโครที่พัฒนาขึ้นเพื่อให้แน่ใจว่า 7 หลักแรกของความคิดเห็นคือหมายเลขปัญหาที่ถูกต้องจากภารกิจที่ชัดเจน (ระบบติดตามปัญหา / คุณสมบัติของเรา)
ฉันทำสิ่งนั้นเมื่อฉันกระทำเช่นการแก้ไขข้อบกพร่องที่จำเป็นต้องมีการเปลี่ยนแปลงหลายไฟล์ สิ่งนี้ทำให้ง่ายขึ้นเล็กน้อยที่จะบอกสิ่งที่เปลี่ยนแปลงจริงโดยไม่ดูไฟล์แต่ละไฟล์ในเซ็ตการแก้ไข
สำหรับเซ็ตการแก้ไขไฟล์เดียวสิ่งนี้ไม่จำเป็น
บรรทัดแรกเป็นคำอธิบายระดับสูงของเซ็ตการแก้ไขเสมอเช่นลิงก์ไปยังข้อบกพร่องหรือเรื่องราวของผู้ใช้
หากเป็นข้อมูลที่เกี่ยวข้องในการเล่าเรื่องของการส่งข้อความยอมรับใช่รวมไว้ด้วย หากข้อมูลเพียงเล็กน้อยเท่านั้นคือชื่อไฟล์เองดังนั้นจะไม่มี
ตัวอย่างเช่นสิ่งนี้สมเหตุสมผล: "ย้ายฟังก์ชัน build_foo () จาก fooutil.c ไปยัง foobase.c เนื่องจากโปรแกรมส่วนใหญ่ที่ต้องการใช้ build_foo () มีอยู่แล้วรวมถึง foobase.c"
อันนี้ไม่ได้: "อัปเดต build_foo () ใน fooutil.c เพื่อรับพารามิเตอร์บาร์"
ฉันต้องการเพิ่มมุมมองที่แตกต่างที่นี่
คำตอบของฉันคือใช่หรือไม่ใช่ แต่โดยทั่วไปฉันจะบอกว่าใช่
การควบคุมเวอร์ชันนั้นมีประสิทธิภาพเพียงพอที่จะรับรู้ว่าไฟล์ใดที่กำลังถูกอัพเดต แต่เมื่อเราทำ
$ git log
เราเห็นข้อความกระทำการเท่านั้น ว่าสิ่งที่คนส่วนใหญ่ทำ
โดยดูที่บันทึกนั่นเอง มันเพิ่มบริบทเพิ่มเติมให้กับมัน ตัวอย่างเช่น:
readme.md: Fix typo detected by language tool
ดีกว่า
Fix typo detected by language tool
อย่างไรก็ตามหากการเปลี่ยนแปลงเกิดขึ้นหลายไฟล์อย่างน้อยก็พูดถึงองค์ประกอบที่กำลังแก้ไข
API: Fix reset password not sent email to user
จากการอ่านเรารู้ว่าข้อผิดพลาดที่ถูกแก้ไขอยู่ที่ส่วนประกอบ API และอาจอยู่ภายใต้ไดเรกทอรี API ที่รหัสฐาน
อย่างไรก็ตามเราสามารถทำได้
$ git show COMMIT_ID --name-only
แต่มันเพิ่มขั้นตอนเพิ่มเติมเพื่อให้ได้ไฟล์
ครั้งเดียวที่ฉันเห็นว่าสิ่งนี้มีประโยชน์สำหรับการเช็คอินไฟล์เดียวคือถ้าคุณได้ทำการเปลี่ยนแปลงฟังก์ชั่นที่ใช้ในหลาย ๆ ที่ภายในไฟล์พร้อมกับผลลัพธ์ที่ต่างกันกระจัดกระจาย แม้ว่าฉันจะใส่ตัวติดตามการเปลี่ยนแปลง # และคำอธิบายข้อความธรรมดาของการเปลี่ยนแปลงก่อน
ฉันคิดว่าคำถามจริงที่นี่มีขอบเขต จำกัด อยู่แค่ไหน หากคุณรอที่จะคอมมิชชันการเปลี่ยนแปลงที่ไม่เกี่ยวข้องหลายอย่างด้วยกันในการคอมมิตครั้งเดียวคุณอาจรู้สึกว่าจำเป็นต้องระบุว่าไฟล์ใดที่ถูกเปลี่ยนเพื่อจุดประสงค์อะไร
อย่างไรก็ตามหากคุณทำการคอมมิทให้แคบลงบ่อยครั้งการคอมมิทชั่นเดียวจะอธิบายว่าไฟล์ใดที่ถูกแก้ไขและคุณสามารถอธิบายได้ว่าจุดประสงค์ในข้อความนั้นคืออะไร
กระทำมากขึ้นบ่อยขึ้น นั่นคือวิธีที่คุณสามารถหลีกเลี่ยงการใช้ข้อความของคุณอย่างละเอียด
มันไม่ควร
ทุกคนที่สนใจสามารถเห็นการเปลี่ยนแปลงในประวัติศาสตร์
นอกจากนี้ยังเป็นไปไม่ได้ในระบบที่มีขนาดใหญ่เนื่องจากไฟล์จำนวนมากอาจถูกสร้างขึ้นโดยอัตโนมัติ