มันเป็นการดีที่จะทำลายความมุ่งมั่นระดับกลางตราบใดที่ความมุ่งมั่นขั้นสุดท้ายในงานผลักดันใด ๆ ?

ที่เกี่ยวข้อง: คอมไพล์ทุกคนควรออกจากโครงการในสถานะการทำงานหรือไม่

สมมติว่าฉันทำสิ่งต่อไปนี้ในพื้นที่:

• ปรับเปลี่ยนสกีมาฐานข้อมูลทำให้แอปพลิเคชันหยุดทำงาน

• อัปเดตแอปพลิเคชันเพื่อให้เข้ากันได้กับสคีมาฐานข้อมูลอีกครั้ง

ตราบใดที่ฉันผลักทั้งสองกระทำmasterยังคงอยู่ในสภาพการทำงาน อย่างไรก็ตามเวอร์ชันทางประวัติศาสตร์เสีย

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

คำถามของฉันคือ:

• มีใครประสบปัญหาบ้างหรือไม่เนื่องจากความผูกพันทางประวัติศาสตร์ที่แตกสลายในเจ้านาย?

• ถ้าเป็นเช่นนั้นมีวิธีง่ายๆในการหลีกเลี่ยงปัญหาดังกล่าวหรือไม่โดยไม่ละทิ้งบุคคลที่ส่งข้อความและเปลี่ยนแปลง?

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

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

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

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

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

ไม่มันไม่เป็นไร

หากคุณเคยทำgit bisect(และผู้ที่ไม่รักคุณสมบัตินักฆ่านั้น) คุณจะรู้คุณค่าของประวัติศาสตร์ที่ทุกคนสร้างขึ้น

หากคุณมีข้อผูกพันมากมายระหว่างbisectที่ไม่ได้สร้างคุณจะมีหลายอย่างgit bisect skipที่ทำให้ยากต่อการค้นหาความมุ่งมั่นสุดท้าย

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

มีใครประสบปัญหาบ้างหรือเปล่าเนื่องจากความมุ่งมั่นทางประวัติศาสตร์ที่แตกสลายในอาจารย์?

ใช่. Backport, revert และ bisects นั้นยากขึ้น ดังนั้นการอ่านประวัติ (ดูด้านล่าง)

ถ้าเป็นเช่นนั้นมีวิธีง่ายๆในการหลีกเลี่ยงปัญหาดังกล่าวหรือไม่โดยไม่ละทิ้งบุคคลที่ส่งข้อความและเปลี่ยนแปลง?

ไม่ใช่ที่ฉันรู้ว่าแม้ว่าสาขาจะเป็นทางออกที่ดี

อย่างไรก็ตามฉันคิดว่าการละทิ้ง (หรือบีบตัวเอง) บุคคลที่กระทำนั้นเป็นสิ่งที่ถูกต้อง

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

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

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

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

คำตอบสั้น ๆ : ใช่

การทดสอบ:

การพัฒนาที่ขับเคลื่อนการทดสอบหมายถึงคุณเขียนการทดสอบที่ผิดพลาด (เช่นการแสดงที่ล้มเหลว)
จากนั้นคุณเขียนรหัสเพื่อให้การทดสอบใช้งานได้

การพัฒนา:

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

ข้อแม้:

นี่ไม่ได้หมายความว่า

1) คุณตรวจสอบรหัสที่ชำรุดเป็นหลัก
2) คุณต้องผลักดันการกระทำทุกอย่างเพื่อให้ทุกคนทบทวน

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

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