เหตุใดฉันจึงควรเขียนข้อความยืนยัน?

เหตุใดฉันจึงควรเขียนข้อความยืนยัน? ฉันไม่ต้องการและฉันคิดว่ามันโง่ทุกครั้ง

ส่วนหน้า GUI ฉันใช้ซึ่งจะบังคับให้คุณทำมัน ฉันได้ยินคนอื่นทำทุกครั้งแม้ว่าพวกเขาจะใช้ VCS ในบรรทัดคำสั่ง

หากฉันส่งมอบวันละหลายครั้ง แต่ยังไม่เสร็จฉันจะเขียนเกี่ยวกับคุณสมบัติอะไร? ฉันเคยเขียนข้อความหลังจากหลายคนยอมรับและฉันรู้สึกว่าถึงเวลาสำหรับมินิแท็กหรือเมื่อฉันทำแท็กจริง

ฉันถูกหรือว่าฉันทำอะไรหายไป? ฉันยังใช้ระบบกระจาย

สำหรับทุกคนที่พูดว่า "กระทำเมื่อคุณมีข้อความที่มีประโยชน์และมีความคิดที่ดีที่จะเขียนและเมื่อคุณสมบัติของคุณเสร็จสมบูรณ์ 100% และคุณมีการทดสอบหน่วยสำหรับมัน" ฉันพูดว่า: คุณยังอยู่ในความคิด SVN .

หากคุณกำลังใช้ คอมไพล์นี่คือสิ่งที่ฉันจะเรียกว่าเวิร์กโฟลว์อัจฉริยะ:

1. กระทำได้บ่อยเท่าที่คุณต้องการ เขียนข้อความด่วนเก่า ๆ ไม่มีใครเห็นมันเลย
2. หลังจากพูดไปแล้ว 10 คำตอบคุณได้ทำฟีเจอร์นั้นเสร็จแล้ว ตอนนี้เขียนแบบทดสอบและทำแบบทดสอบเหล่านั้น หรืออะไรก็ได้ที่คุณต้องการ ถ้าคุณชอบ TDD เขียนการทดสอบก่อนฉันไม่สนใจและไม่คอมไพล์
3. git rebase -i จาก 'ยุ่ง' ครั้งแรกที่มอบหมายให้คุณเพิ่มและแก้ไขประวัติท้องถิ่นของคุณโดยการแบนการแก้ไขการละเว้นและการล้างประวัติล่าสุดของคุณเป็น ตรรกะกระทำทำความสะอาดด้วยข้อความที่ดี
4. หลังจากล้างข้อมูลให้ขอให้คนอื่นดึงคุณ
5. ล้างและทำซ้ำ

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

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

เพราะเมื่อผู้ดูแลที่ยากจนบางคนกำลังตามล่าหาบั๊กและพบว่ามันถูกเพิ่มเข้ามาในรอบ xyz เขาจะต้องการรู้ว่า rev xyz ควรจะทำ

คุณแสดงความคิดเห็นซอร์สโค้ดใช่ไหม

คุณเขียนแสดงความคิดเห็นที่ดีที่สุดของผู้ที่บอกว่าทำไมเป็นรหัสเพียงพูดว่า ?

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

สำหรับซอฟต์แวร์ที่มีการใช้งานใด ๆ ความคิดเห็นเฉพาะนี้จะปรากฏขึ้นในลักษณะดังนี้

(ดูได้ที่http://longair.net/blog/2009/04/25/a-few-git-tips/ ) สิ่งนี้จะช่วยให้สามารถมองเห็นมุมมองนกของผู้ที่ทำงานกับซอฟต์แวร์เมื่อใดและสิ่งที่พวกเขาทำ

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

หากข้อความการส่งข้อความดูเหมือนโง่สำหรับคุณดูเหมือนว่าคุณกำลังทำผิด

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

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

• refactored คลาสผู้ใช้สำหรับการห่อหุ้มที่ดีขึ้น
• API stubs ที่สร้างขึ้นเพื่อให้สามารถใช้อินเตอร์เฟสในคลาสคอนโทรลเลอร์ได้
• แปลงคลาสฐานข้อมูลเป็นคลาส abstract เพื่อให้สามารถใช้ฐานข้อมูลจำลองในกรณีทดสอบ

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

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

อย่าทำเรื่องใหญ่ออกมาจากพวกเขา ซื่อสัตย์:

• "เอนทิตีดัชนีพิเศษแก้ไข Daos และ UIs เพื่อจัดการฟีเจอร์ X"
• "การเช็คอินที่เพิ่มขึ้นสำหรับคำขอคุณสมบัติ # 1234 และข้อผิดพลาด # 5678"
• "ฉันทำลายงานสร้างครั้งล่าสุดนี่คือไฟล์ที่ฉันพลาด"

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

จะลดจำนวน WTF / นาที;)

ซึ่งแปลเป็นทีมที่มีความสุขมากขึ้น (ซึ่งไม่ได้เกลียดคุณ) และผลผลิตของทีมที่ดีกว่าอาจมีราคาต่ำกว่า

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

เพราะถ้าคุณไม่ฝึกป้อนข้อความยืนยันที่เหมาะสมคุณจะจบลงเหมือนเพื่อนร่วมงานของฉันที่ป้อนข้อความเช่น

no changes

หรือ

testing

สำหรับคอมมิทที่มีไฟล์มากกว่าร้อยไฟล์ที่ถูกเปลี่ยน (ไม่มีการล้อเล่นที่นี่ !!)

หากคุณเป็นนักพัฒนาซอฟต์แวร์คุณจะดูโง่ในสายตาของคนทั่วโลกไม่ว่าคุณจะคิดว่าโง่แค่ไหนก็แค่ใส่ข้อความ

ทำไมคุณถึงต้องกระทำหากการเปลี่ยนแปลงนั้นไม่มีความหมาย?

เพียงแค่ทำการเปลี่ยนแปลงที่มีความหมาย เช่นฉันทำการรีเฟรชครั้งใหญ่ในสัปดาห์ก่อนซึ่งใช้เวลาประมาณ 3 วัน ฉันจะมีภาระผูกพันมากมายในช่วงเวลานั้น บางคนมีการเปลี่ยนแปลงเล็กน้อย ('เปลี่ยนชื่อคลาส X เป็น Y เพื่อสะท้อนความรับผิดชอบใหม่' หรือ 'ย้ายวิธีการ Z () เป็นคลาส Q') และอื่น ๆ มีขนาดใหญ่มาก เมื่อฉันทำฟีเจอร์ / การรีแฟคเตอร์เสร็จฉันจะตรวจสอบว่าคอมมิชชันบางอย่างนั้นถูกแบนหรือไม่ (อย่างน้อยคอมไพล์จะสนับสนุนสิ่งนั้นไม่ทราบเกี่ยวกับเครื่องมืออื่น ๆ ) แต่โดยปกติฉันจะทิ้งมันไว้

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

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

แต่น่าเสียดายที่หมายเลขการแก้ไขไม่ได้บอกคุณเมื่อคุณเปลี่ยน X หรือ Y ดังนั้นตัวเลือกของคุณอาจอ่านรหัสทั้งหมดที่กระทำในช่วง N วันที่ผ่านมาหรือเพียงแค่อ่านข้อความการส่งโดยละเอียดที่คุณเขียน (อ่านได้ง่ายกว่ารหัส)

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

ดังนั้นพยายามเขียนข้อความการส่งข้อความที่มีความหมายทุกครั้งที่คุณส่งซึ่งสามารถช่วยคุณและผู้ดูแลได้เช่นกัน

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

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

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

คุณกำลังพลาดอะไรอยู่ ต้องมีมีเหตุผลสำหรับการดำเนินการกระทำมิฉะนั้นคุณจะไม่ได้ทำมัน

สิ่งที่คุณต้องทำในการแสดงความคิดเห็นคือการใส่เหตุผลลงในคำแม้ว่ามันจะเป็นเพียง wip: adding new state objects

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

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

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

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

หากคุณไม่แสดงความคิดเห็นคุณอาจถูกล่อลวงให้แสดงความคิดเห็นการเปลี่ยนแปลงในแหล่งที่มา ในเวลาที่สามารถถ่วงแหล่ง

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

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

เพื่อให้ผู้ดูแลรหัสนั้นในอีกหนึ่งปีต่อมารู้ว่าใครจะตามล่าหารหัสที่ชั่วร้ายนั้น :)