เป็นการดีกว่าที่จะรวม“ บ่อยครั้ง” หรือหลังจากรวมฟีเจอร์สาขาใหญ่แล้วเสร็จ?

พูดได้หลายสาขาจะได้รับการพัฒนาAและBเช่นเดียวกับที่เพิ่มขึ้น "แก้ไขข้อผิดพลาด" Cสาขา

ตอนนี้C"เสร็จสิ้น" และถูกรวมเข้ากับต้นแบบแล้ว AและBยังอยู่ในระหว่างการพัฒนาและจะไม่ได้รับการแก้ไขก่อน (อาจ) สาขาการแก้ไขข้อบกพร่องอื่นถูกรวมเข้ากับข้อมูลหลัก

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

จะมีความขัดแย้ง แต่อย่างใดดังนั้นจึงจำเป็นต้องใช้เวลาในการแก้ไขสิ่งเหล่านั้น

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

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

จะมีความขัดแย้ง แต่อย่างใดดังนั้นจึงจำเป็นต้องใช้เวลาในการแก้ไขสิ่งเหล่านั้น

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

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

ฉันจะพิจารณากลยุทธ์ที่คล้ายกันดังต่อไปนี้

1. ใครก็ตามที่รับผิดชอบ A, B ควรจับตาดูนายอย่างใกล้ชิดและผสานในการเปลี่ยนแปลงใด ๆ
2. ยังดีกว่าถ้าคุณมีการสร้างและทดสอบระบบอัตโนมัติตรวจสอบให้แน่ใจว่า A, B ผสานเป็นหลักและผ่านการทดสอบทุกคืน
3. ตามที่คุณแสดงความคิดเห็นกับคำตอบอื่น ๆ ดูเหมือนว่า A, B อาจใช้เวลาสักครู่ในการพัฒนา ในกรณีนี้คุณอาจพิจารณาที่จะมี A, B รวมเข้าด้วยกันเพื่อที่ว่าในท้ายที่สุดคุณจะไม่มีปัญหาที่สำคัญในการผสานทั้งสองกลับเข้าที่หลัก
4. ในระดับที่สูงขึ้นให้คิดว่าเหตุใดคุณจึงต้องการการพัฒนาระยะยาว 2 บรรทัดแยกกัน คุณแบ่งย่อยเป็นการรวมตัวที่เล็กลงได้ไหม? คุณแบ่งเป็นบริการ micro ที่แยกกันได้หรือไม่?

โดยปกติมักจะดีกว่าขนาดใหญ่

คำขอดึงที่เล็กกว่าและบ่อยกว่านั้นจะดีขึ้นเกือบทุกครั้ง

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

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

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

เพื่อนร่วมงานของฉันส่วนใหญ่คร่ำครวญเมื่อมีคนสร้างคำขอให้ดึงจำนวนมากและส่วนใหญ่ก็เป็นเช่นนั้น

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

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

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