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

ในทีมของเราเราใช้ Git เป็นแหล่งควบคุมของเรา เรามีหลายส่วนของรหัสที่เกือบจะเป็นอิสระ แต่มีบางอย่างทับซ้อนกัน เมื่อเร็ว ๆ นี้เราได้พูดคุยเวิร์กโฟลว์และวิธีการใช้การควบคุมแหล่งที่มา การร้องเรียนหนึ่งเรื่องที่เกิดขึ้นเมื่อฉันโปรโมตโดยใช้เวิร์กโฟลว์สาขาคุณลักษณะคือคนมักจะพบกับข้อขัดแย้งที่ซับซ้อนที่พวกเขาแก้ไขไม่ถูกต้อง ตามความซับซ้อนฉันหมายถึง "ไม่ชัดเจนว่าจะแก้ไขอย่างไร" ด้วยเหตุนี้เวิร์กโฟลว์อื่น ๆ จึงถูกใช้อย่างแข็งขันมากขึ้นเช่น "pull rebase" - เวิร์กโฟลว์ที่ใช้

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

ฉันถูกต้องในการคิดสิ่งนี้หรือไม่? การผสานที่ซับซ้อนขัดแย้งกับสัญญาณของอะไรดีหรือไม่ดี?

เป็นไปไม่ได้ที่ปัญหาคือรหัสของคุณ ถ้า codebase ของคุณมีความสัมพันธ์ระหว่างโมดูลจำนวนมากดังนั้นการเปลี่ยนแปลงทุกอย่างจะมีความโน้มเอียงทุกที่และทุก ๆ dev จะโต้ตอบกับโค้ดของคนอื่นมันจะเป็นฝันร้าย

ฉันมักจะคิดว่าคุณจะสังเกตเห็นสิ่งนี้ก่อนอื่น แต่อาจเป็นไปได้ว่าคุณคุ้นเคยกับมันมากจนไม่สามารถมองเห็นมันได้อีก

ฉันคุ้นเคยกับเวิร์กโฟลว์ "fetch-rebase-push" ซึ่งอันที่จริงเป็นเวิร์กโฟลว์ดั้งเดิมลำดับแรกที่สุดที่อธิบายไว้ในบทช่วยสอนของคุณนี่คือข้อดี:

• บูรณาการอย่างต่อเนื่องที่แท้จริง
• การจัดการความขัดแย้งก่อน - หลังจากหนึ่งได้เขียนและทดสอบรหัส
• การตอบสนองอย่างรวดเร็ว - "- เฮ้บ๊อบการแก้ไขลูกบาศก์ที่คุณเขียนจะให้ผลลัพธ์ที่ตลกคุณสามารถดูได้ในขณะที่ฉันทานอาหารกลางวันหรือไม่?"
• ไม่มีการผูกมัด - ทำความสะอาดไทม์ไลน์ราวกับว่านักพัฒนาคนหนึ่งเขียน everithyng

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

โดยส่วนตัวฉันต้องการที่จะจัดการกับความขัดแย้งที่เกิดขึ้นบ่อยครั้งง่าย ๆ (รวมถึงการรีบูท) แทนที่จะเป็นเรื่องสยองขวัญที่หาได้ยาก

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

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

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

โครงการที่ฉันกำลังทำงานอยู่มีปัญหาประเภทนี้เป็นครั้งคราวและดูเหมือนว่าจะเกิดจากปัจจัยสองประการ:

• เรากำลังใช้ Visual Studio และไฟล์อย่าง Visual Studio .sln เป็นเพียงเอกสาร XML (ซึ่งไม่ตอบสนองต่อการผสานที่เป็นข้อความ) ที่เต็มไปด้วย Guids (ซึ่ง Git ไม่สามารถเข้าใจได้ดีกว่าพวกเราที่เหลือ) และสามารถเป็นได้ง่าย ผสานอย่างไม่ดีและทำให้ไฟล์หายไป
• บางคนกำลังทำงานในพื้นที่ที่คล้ายกันของรหัสเพื่อให้การเปลี่ยนแปลงที่ถูกผลักสามารถอยู่ติดกันในชั้นเรียน แม้ว่าจะหลีกเลี่ยงไม่ได้ในสถานการณ์นี้ แต่การกำหนดค่าประเภทนี้จะเป็นงานที่หนักมากสำหรับระบบควบคุมแหล่งใด ๆ แม้ว่าคุณจะมีการสื่อสารที่ดีในทีมของคุณบางครั้งผู้คนก็ไม่ได้ตระหนักว่าพวกเขากำลังชนเข้ากับรหัสและความขัดแย้งที่เกิดขึ้น

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

ยกเว้นว่านักพัฒนากำลังแก้ไขการกระทำในอดีต (แทนที่จะเป็นการผสานอย่างบริสุทธิ์) ความขัดแย้งในรูปแบบคุณลักษณะประเภทเวิร์กโฟลว์ git เป็นสัญญาณของ codebase ที่ต่อเนื่องกันอย่างแน่นหนา (/ codenew ใหม่) หรือการกำหนดคุณลักษณะที่ทับซ้อนกัน

คุณมีสาขาหลัก (หลัก) และทุกคนทำงานในสาขาคุณลักษณะของพวกเขา

การทำงานในสาขาคุณลักษณะอาจใช้เวลาไม่กี่ชั่วโมงจนถึงไม่กี่เดือน

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

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

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