ฉันควรใช้อดีตกาลหรือปัจจุบันในการคอมไพล์ข้อความ? [ปิด]

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

นี่คือ John Resig ล่าสุดที่กระทำการแสดงทั้งสองในหนึ่งข้อความ

ปรับแต่ง jQuery เพิ่มเติมบางผลลัพธ์ในการทดสอบการจัดการ แก้ไขลำดับของผลการทดสอบที่คาดไว้

มันสำคัญไหม ฉันควรใช้แบบไหน

การตั้งค่าสำหรับข้อความการผูกมัดในปัจจุบันที่มีความจำเป็นและมีสไตล์นั้นมาจาก Git เอง จากDocumentation / SubmittingPatchesใน repo Git:

อธิบายการเปลี่ยนแปลงของคุณในอารมณ์ที่จำเป็นเช่น "make xyzzy do frotz" แทน "[แพทช์นี้] ทำให้ xyzzy do frotz" หรือ "[I] เปลี่ยน xyzzy เป็น frotz" ราวกับว่าคุณกำลังสั่งให้ codebase เปลี่ยน พฤติกรรม.

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

โครงการของคุณควรมักจะใช้อดีตกาล ไม่ว่าในกรณีใดโครงการควรใช้รูปแบบเดียวกันเสมอเพื่อความมั่นคงและชัดเจน

ฉันเข้าใจข้อโต้แย้งอื่น ๆ ที่โต้แย้งว่าใช้กาลปัจจุบัน แต่มักจะไม่ใช้ หัวข้อย่อยต่อไปนี้เป็นข้อโต้แย้งทั่วไปสำหรับการเขียนในปัจจุบันและการตอบสนองของฉัน

• การเขียนในกาลปัจจุบันบอกบางคนว่าการใช้ความมุ่งมั่นจะทำอะไรมากกว่าสิ่งที่คุณทำ

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

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

ที่ถูกกล่าวว่าโครงการส่วนใหญ่ในการควบคุมแหล่งที่มาไม่ทำงานเช่นนี้ มักจะไม่ถูกต้องสำหรับที่เก็บข้อมูลส่วนใหญ่ เป็นวิธีคิดสมัยใหม่เกี่ยวกับคอมมิท: การโค่นล้ม (SVN) และที่เก็บ CVS แทบจะไม่รองรับการเช็คอินที่เก็บแบบนี้ โดยทั่วไปแล้วสาขาการรวมจะจัดการการกรองเช็คอินที่ไม่ดี แต่โดยทั่วไปจะไม่ถือว่าเป็น "ตัวเลือก" หรือ "ฟีเจอร์ที่น่าอยู่"

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

ในที่สุดสำหรับโครงการที่ไม่เผยแพร่เช่น 99.99% ของเวลาที่บุคคลจะอ่านข้อความยืนยันสำหรับการอ่านประวัติ - ประวัติถูกอ่านในกาลที่ผ่านมา 0.01% ของเวลาที่จะตัดสินใจว่าควรใช้การคอมมิชชันนี้หรือรวมเข้ากับสาขา / พื้นที่เก็บข้อมูลของพวกเขาหรือไม่

• ความมั่นคง นั่นเป็นวิธีในหลาย ๆ โครงการ (รวมถึงคอมไพล์เอง) นอกจากนี้เครื่องมือคอมไพล์ที่สร้างคอมมิท (เช่นการรวมคอมไพล์หรือย้อนกลับคอมไพล์) ก็ทำได้เช่นกัน

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

• ผู้คนไม่เพียง แต่อ่านประวัติศาสตร์รู้ว่า "เกิดอะไรขึ้นกับ codebase นี้" แต่ยังต้องตอบคำถามเช่น "เกิดอะไรขึ้นเมื่อฉันเลือกการกระทำนี้" หรือ "สิ่งใหม่ ๆ จะเกิดขึ้นกับฐานรหัสของฉันเพราะสิ่งเหล่านี้ ฉันอาจจะหรืออาจจะไม่รวมในอนาคต "

ดูจุดแรก 99.99% ของเวลาที่บุคคลจะอ่านข้อความยืนยันสำหรับการอ่านประวัติ - ประวัติถูกอ่านในอดีตกาล 0.01% ของเวลาที่จะตัดสินใจว่าควรใช้การคอมมิชชันนี้หรือรวมเข้ากับสาขา / พื้นที่เก็บข้อมูลของพวกเขาหรือไม่ 99.99% เต้น 0.01%

• มักจะสั้นกว่า

ฉันไม่เคยเห็นข้อโต้แย้งที่ดีที่บอกว่าใช้กาล / ไวยากรณ์ที่ไม่เหมาะสมเพราะมันสั้นกว่า คุณอาจบันทึกโดยเฉลี่ย 3 ตัวอักษรสำหรับข้อความมาตรฐาน 50 ตัว ที่ถูกกล่าวว่ากาลปัจจุบันโดยเฉลี่ยอาจจะสั้นกว่าไม่กี่ตัวอักษร

• คุณสามารถตั้งชื่อให้คำมั่นสัญญากับชื่อตั๋วในตัวติดตามปัญหา / ฟีเจอร์ของคุณได้อย่างต่อเนื่อง (ซึ่งไม่ได้ใช้อดีตกาลแม้ว่าบางครั้งในอนาคต)

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

ประวัติ (เช่นกระทำข้อความ) เขียนเป็นสิ่งที่ทำในอดีต (เช่นปัญหาได้รับการแก้ไข)

ผมเขียนคำอธิบายฟูลเลอร์ใน365git

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

Renamed the iVars and removed the common prefix.

มีแบบนี้:

Rename the iVars to remove the common prefix

ซึ่งบอกใครบางคนว่าการใช้ความมุ่งมั่นจะทำอะไรมากกว่าสิ่งที่คุณทำ นอกจากนี้หากคุณดูประวัติที่เก็บของคุณคุณจะเห็นว่าข้อความที่สร้าง Git นั้นเขียนไว้ในกาลนี้เช่นกัน -“ ผสาน” ไม่ใช่“ ผสาน”,“ Rebase” ไม่ใช่“ Rebased” ดังนั้นการเขียนในกาลเดียวกันจะทำให้สิ่งต่าง ๆ สอดคล้องกัน ในตอนแรกมันรู้สึกแปลก ๆ แต่มันก็สมเหตุสมผล (รับรองเมื่อมีการสมัคร) และในที่สุดก็กลายเป็นธรรมชาติ

ต้องบอกว่าทั้งหมด - รหัสของคุณที่เก็บของคุณ: ดังนั้นตั้งค่าแนวทางของคุณเองและยึดมั่นกับพวกเขา

อย่างไรก็ตามหากคุณตัดสินใจที่จะไปทางนี้git rebase -iด้วยตัวเลือก reword จะเป็นสิ่งที่ดีที่จะตรวจสอบ

ติดกับความตึงเครียดในปัจจุบันเพราะความจำเป็น

• มันดีที่มีมาตรฐาน
• มันจับคู่ตั๋วในตัวติดตามบั๊กซึ่งโดยธรรมชาติมีรูปแบบ "ใช้บางอย่าง", "แก้ไขบางอย่าง" หรือ "ทดสอบบางอย่าง"

คุณเขียนข้อความเพื่อใคร และผู้อ่านนั้นมักจะอ่านข้อความก่อนหรือโพสต์ความเป็นเจ้าของกระทำตัวเอง?

ฉันคิดว่าได้รับคำตอบที่ดีจากทั้งสองมุมมองบางทีฉันอาจจะขาดคำแนะนำว่ามีคำตอบที่ดีที่สุดสำหรับทุกโครงการ คะแนนแยกอาจแนะนำมาก

คือการสรุป:

• เป็นข้อความที่คนส่วนใหญ่มักจะอ่านในบางจุดก่อนที่พวกเขาจะสันนิษฐานการเปลี่ยนแปลง: ข้อเสนอของสิ่งที่การเปลี่ยนแปลงจะทำกับรหัสที่มีอยู่ของพวกเขา

• ข้อความส่วนใหญ่เป็นวารสาร / บันทึกถึงคุณ (หรือทีมของคุณ) แต่โดยทั่วไปแล้วการอ่านจากมุมมองของการสันนิษฐานการเปลี่ยนแปลงและค้นหากลับไปค้นพบสิ่งที่เกิดขึ้น

บางทีสิ่งนี้จะนำไปสู่แรงจูงใจสำหรับทีม / โครงการของคุณไม่ว่าจะด้วยวิธีใด

มันสำคัญไหม คนทั่วไปฉลาดพอที่จะตีความข้อความได้อย่างถูกต้องหากพวกเขาไม่ใช่คุณอาจไม่ควรให้พวกเขาเข้าถึงที่เก็บของคุณต่อไป!

มันขึ้นอยู่กับคุณ. เพียงใช้ข้อความยืนยันตามที่คุณต้องการ แต่จะง่ายกว่าถ้าคุณไม่สลับระหว่างเวลาและภาษา

และถ้าคุณพัฒนาในทีม - มันควรจะพูดคุยและตั้งค่าคงที่