ประวัติรุ่นเป็นสิ่งที่ศักดิ์สิทธิ์จริง ๆ หรือดีกว่าที่จะรีบูต?

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

OTOH ฉันเห็นจุดของการพยายามทำแพ็คเกจ 5 ที่กระทำในอันเดียวเพื่อทำให้มันดู niftier (โดยเฉพาะในสาขาการผลิต) อย่างไรก็ตามโดยส่วนตัวฉันคิดว่าจะดีกว่าถ้าได้เห็นบางส่วนที่ทำหน้าที่บางอย่าง การทดลองเสร็จสิ้นแม้ว่าจะไม่ได้ดี แต่การเห็นบางสิ่งเช่น "พยายามทำวิธีที่ X แต่ไม่เหมาะสมเท่ากับ Y หลังจากทั้งหมดการทำ Z ที่ใช้ Y เป็นฐาน" IMHO มีคุณค่าต่อผู้เรียน codebase และติดตามการพัฒนาความคิด

ทัศนะของฉัน (ในแง่โง่, เกี่ยวกับอวัยวะภายใน, เอนเอียง) คือโปรแกรมเมอร์ที่ชอบลดการซ่อนข้อผิดพลาด ... และฉันไม่คิดว่ามันดีสำหรับโครงการเลย

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

¹ต่อการวิเคราะห์ของ Google DVCSใน Mercurial "History is Sacred"

ประวัติศาสตร์เป็นสิ่งศักดิ์สิทธิ์ที่ปัจจุบันไม่ได้ คุณสามารถแยก "ต้นไม้" DVCS ของคุณเป็นสองส่วน:

• ที่ผ่านมา / ประวัติศาสตร์ที่มีมุมมองที่ถูกต้องของวิธีการที่คุณได้มาถึงสถานะปัจจุบันของรหัส ประวัติศาสตร์ส่วนนี้เติบโตไปตามกาลเวลา

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

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

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

ใช่โปรดรีบูทหากปรับปรุงประวัติของคุณ Mercurial จะป้องกันไม่ให้คุณยิงตัวเองด้วยการเดินเท้าถ้าคุณกำลังรีบูทสิ่งที่คุณไม่ควรทำ

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

การตรวจสอบโค้ดนั้นง่ายกว่ามากเมื่อมีการเปลี่ยนแปลงครั้งใหญ่ที่ไม่เหมือนกัน

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

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

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

ฉันไม่คิดว่าเวิร์กโฟลว์ออร์แกนิกจะทำสิ่งนี้ได้ดีแม้แต่ของฉันเอง คุณภาพฉันให้ความสำคัญกับ DVCS เมื่อฉันกำลังเขียนโค้ด - สาขาราคาถูกการยอมรับอย่างรวดเร็วบันทึกไปยังระยะไกลก่อนหน้าและบ่อยครั้ง - ไม่ใช่สิ่งที่ฉันให้ความสำคัญในฐานะผู้จัดการการรวมบริษัท ของฉัน ฉันปัญหาgit rebase, git merge, git diffและgit applyไกลมากขึ้นมักจะอยู่ในบทบาทที่มากกว่าหรือgit add git commitเครื่องมือเช่นrebaseอนุญาตให้ฉันเปลี่ยนรหัสที่ฉันได้รับจากสิ่งที่ทำงานเป็นสิ่งที่สามารถรักษาได้

การกระทำที่ผิดกฎหมายหรือคลุมเครือนั้นไม่มีประโยชน์ แต่เป็นเรื่องง่ายที่จะเขียนอย่างเป็นธรรมชาติเมื่อความกังวลหลักคือการทำให้โค้ดทำงานไม่ได้แจกจ่ายให้ผู้อื่น กระทำเช่นCase 15: Fixed a problemนั้นหรือRefactored <cranky legacy feature>ทำให้การดูแลตนเองเป็นไปอย่างราบรื่นแม้ว่าฉันจะเขียนก็ตาม อย่างไรก็ตามไม่มีการชักนำให้เกิดความโกรธแค้นอย่างเช่น "เพิ่มขึ้น" พิจารณาสาขาหัวข้อนี้นักพัฒนามอบวันให้ฉัน:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

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

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

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

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

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