เพื่อนร่วมงานของฉันบอกฉันว่าเขากำลังคิดที่จะทำให้เซิร์ฟเวอร์ CI ของเรากลับไปใช้สิ่งที่ล้มเหลวในการสร้างดังนั้นHEADin masterจึงมีความเสถียรอยู่เสมอ (เช่นเดียวกับที่ผ่านการสร้างอย่างน้อย)
นี่เป็นวิธีปฏิบัติที่ดีที่สุดหรืออาจเป็นปัญหามากกว่าแค่ปล่อยให้masterแตกจนกว่าผู้พัฒนาจะแก้ไขหรือไม่
ความคิดของฉันคือการคืนค่าการคอมมิชชันจะทำให้งานการอ่านการคอมมิชชันและการแก้ไขซับซ้อนมากขึ้น (นักพัฒนาจะต้องย้อนกลับการแปลงกลับแล้วคอมมิทการแก้ไขซึ่งจะทำให้ยุ่งเหยิงด้วยgit log) และเราควรปล่อยคอมมิต แก้ไข แม้ว่าฉันจะเห็นข้อได้เปรียบบางอย่างในการมีmasterเสถียรภาพ แต่การย้อนกลับมาของความล้มเหลวนี้ไม่ได้ทำให้ฉันมั่นใจ
แก้ไข: ไม่สำคัญว่าจะเป็นmasterหรือสาขาการพัฒนาอื่น ๆ แต่คำถามยังคงเหมือนเดิม: ระบบ CI ควรเปลี่ยนการกระทำที่ล้มเหลวในการสร้างหรือไม่?
การแก้ไขอื่น (ความยาว): ตกลงเรากำลังใช้gitวิธีแปลก ๆ เราเชื่อว่าแนวคิดของสาขาแตกต่างจาก CI จริงเนื่องจากการทำหน้าที่แยกสาขาคุณออกจากนักพัฒนาคนอื่นและการเปลี่ยนแปลงของพวกเขาและเพิ่มเวลาเมื่อคุณต้องรวบรวมสาขาของคุณอีกครั้งและจัดการกับความขัดแย้งที่อาจเกิดขึ้น หากทุกคนยอมรับmasterความขัดแย้งนี้จะลดลงเหลือน้อยที่สุดและทุกการกระทำผ่านการทดสอบทั้งหมด
แน่นอนว่าสิ่งนี้บังคับให้คุณผลักดันเฉพาะความเสถียร (หรือคุณทำลายโครงสร้าง) และตั้งโปรแกรมอย่างระมัดระวังมากขึ้นเพื่อไม่ให้ทำลายความเข้ากันได้ย้อนหลังหรือทำการสลับคุณลักษณะเมื่อแนะนำคุณสมบัติใหม่
มีการแลกเปลี่ยนเมื่อทำ CI ด้วยวิธีนี้ แต่นั่นไม่ได้อยู่ในขอบเขตของคำถาม (ดูคำถามที่เกี่ยวข้องสำหรับเรื่องนี้) หากคุณต้องการฉันอาจตั้งคำถามใหม่: ทีมนักพัฒนาเล็ก ๆ ทำงานร่วมกันในสาขาฟีเจอร์ หากนักพัฒนารายหนึ่งยอมรับสิ่งที่ทำลายการสร้างสำหรับสาขานั้นระบบ CI ควรเปลี่ยนการยอมรับหรือไม่?
masterเริ่มต้นด้วย นั่นคือสิ่งที่สาขาการพัฒนาและฟีเจอร์ใช้สำหรับ การเปลี่ยนแปลงเหล่านั้นจะเกิดขึ้นในสาขาการรวมที่คุณสามารถทดสอบว่าคุณลักษณะใหม่ทั้งหมดของนักพัฒนาหลายคนจะทำงานร่วมกันได้หรือไม่และหากการทดสอบนี้สามารถเข้าสู่ต้นแบบได้ หรืออย่างน้อยนั่นก็เป็นขั้นตอนการทำงานที่เป็นไปได้