มีข้อบกพร่องใด ๆ กับรูปแบบการแยกทาง Git หรือไม่

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

(คุณไม่จำเป็นต้องตอบทุกคำถามสิ่งที่คุณสามารถทำได้มีประโยชน์)

1. คุณใช้เวิร์กโฟลว์การแยกสาขาแบบนี้หรือคล้ายกันหรือไม่

2. คุณคิดว่านี่เป็นแนวทางการผลิตหรือไม่?

3. คุณเห็นข้อบกพร่องด้วยวิธีนี้หรือไม่? ข้อเสียใด ๆ ที่อาจเกิดขึ้น?

4. หากคุณมีวิธีที่ดีกว่าคุณจะแบ่งปันหรือเสนอลิงก์ไปยังบทความหรือการสนทนาเกี่ยวกับเรื่องนี้หรือไม่?

ส่วนใหญ่เป็นเวิร์กโฟลว์ปกติที่ใช้กับ VCS ใด ๆ ที่เราใช้มาจนถึงตอนนี้ ด้วยบางอย่าง (CVS, SVN) มันยากที่จะทำด้วย GIT มันเป็นเรื่องเล็กน้อย ที่กล่าวว่าฉันมีข้อสังเกตสอง:

อย่างแรกมีโรงเรียนแห่งความคิดสองแห่งเมื่อพูดถึงสาขาย่อย:

1. รวมพวกเขา
2. Rebase พวกเขา

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

(2) หลีกเลี่ยงปัญหานี้โดยพยายามรักษาประวัติเชิงเส้นให้มากที่สุด การรีบาวน์ที่เป็นปฏิปักษ์เหล่านั้นอ้างว่ามันทำให้การทดสอบใด ๆ ที่คุณอาจทำไว้ก่อนการรีเบทนั้นใช้ไม่ได้

โดยส่วนตัวแล้วฉันอยู่ในค่าย (2) เพราะฉันเห็นคุณค่าความถูกต้องของgit bisectผลลัพธ์มากกว่าการสูญเสียความครอบคลุมการทดสอบซึ่งอาจชดเชยได้ง่ายโดยใช้ระบบ CI ที่เหมาะสม

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

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

ขณะนี้ฉันกำลังอยู่ระหว่างการทำ refactorings ขนาดใหญ่และเป็นเวลานาน (การแปลงแอปพลิเคชันจากชุดเครื่องมือหนึ่งไปเป็นชุดเครื่องมือ GUI อื่น) และดำเนินการเวิร์กโฟลว์เป็นศูนย์กลางในการลดความสำเร็จเนื่องจากสมาชิกในทีมคนอื่น ๆ

ส่วนใหญ่มีสองสาขาหลักmasterที่ซึ่งคุณสมบัติใหม่ได้รับการพัฒนาและtoolkit-conversionสาขา กฎที่สำคัญที่สุดคือง่าย ๆ : ทำสิ่งต่าง ๆ ในtoolkit-conversionสาขาที่เกี่ยวข้องกับการแปลงเท่านั้น เมื่อใดก็ตามที่มีบางสิ่งที่สามารถทำได้ในmaster(ชุดเครื่องมือ GUI เก่า) ฉันจะทำที่นั่นและรีบูตtoolkit-conversionการเปลี่ยนแปลงของฉันในmasterหัวใหม่ กฎอีกข้อคือให้toolkit-conversionกิ่งค่อนข้างสั้น ดังนั้นฉันมักจะใช้การรีเซ็ต, การเลือกเชอร์รี่และการแก้ไขการกระทำและการลดลงของกาวที่มีขนาดเล็กลงให้กับวัตถุที่มีขนาดใหญ่กว่า (ซึ่งในตอนท้ายมีจุดประสงค์เดียวกัน) สิ่งนี้ยังใช้งานได้ดีเมื่อฉันลองทำบางสิ่งที่ใช้ไม่ได้กับ "เลิกทำ" การเปลี่ยนแปลงหรือหลังจากฉันปรับโครงสร้างโค้ดด้วยรหัสผู้ช่วยชั่วคราว

ฉันได้ตัดสินใจที่จะไม่รวมการเปลี่ยนแปลงจากmasterเป็นtoolkit-conversionสาขาเพราะจะทำให้การรีบูทก่อนหน้านี้ยากยิ่งขึ้นเพื่อให้สาขาสะอาดและง่ายต่อการตรวจสอบ นอกจากนี้การผสานอาจทำให้เกิดข้อขัดแย้งซึ่งการแก้ปัญหานั้นไม่ชัดเจนเหมือนเมื่อเก็บประวัติที่สะอาด

แน่นอนกระบวนการทำงานนี้ยังมีข้อเสีย สิ่งที่สำคัญที่สุดคือมันใช้งานได้ดีสำหรับคนคนเดียว เมื่อฉันบังคับให้ดันtoolkit-conversionสาขาหลังจากรีบาวด์ไปที่ส่วนหัวการmasterดึงมันในที่เก็บอื่นกลายเป็นเรื่องยาก (การรีบูทไปยังสาขาการติดตามโดยอัตโนมัติมักล้มเหลวด้วยความขัดแย้ง)

ในตอนท้ายtoolkit-conversionสาขาของฉันยังคงสั้นสะอาดและง่ายต่อการตรวจสอบ ฉันไม่สามารถจินตนาการได้ว่าได้ทำสิ่งที่ทรงพลังเช่นนี้ด้วยเช่น SVN

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

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

นอกจากนั้นสิ่งนี้ได้พิสูจน์แล้วว่าน่าเชื่อถือ :)

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

ข้อเสียเล็ก ๆ น้อย ๆ เพียงอย่างเดียวก็คือว่ามันต้องใช้วินัยบางอย่างในการถือเวิร์กโฟลว์นี้และไม่พยายามที่จะใช้ทางลัด

นักพัฒนาของkohanaยังใช้เวิร์กโฟลว์นี้และพวกเขาดูเหมือนจะชอบมันมาก

คุณใช้เวิร์กโฟลว์การแยกสาขาแบบนี้หรือคล้ายกันหรือไม่

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

คุณคิดว่านี่เป็นแนวทางการผลิตหรือไม่?

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

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

ทันทีที่คุณทดสอบคุณสมบัติใหม่และการแก้ไขข้อบกพร่องคุณสามารถถ่ายโอนได้จากซ้ายไปขวาและทำให้โค้ดมีคุณภาพสูงเมื่อคุณทราบว่ารหัสตรงตามข้อกำหนดคุณภาพที่คุณต้องการของรหัส อย่างน้อยก็ในทางทฤษฎีแล้วคุณไม่สามารถทดสอบทุกอย่างได้ 100% และรู้ว่ารหัสนั้นไม่มีข้อบกพร่องใด ๆ เพราะมันจะมีข้อบกพร่องอยู่เสมอ แต่มันช่วยให้คุณมีความมั่นใจสูง

ไม่มีอะไรดูดมากขึ้นในฐานะโปรแกรมเมอร์มากกว่าที่จะทำงานในระบบที่ไม่มีใครมีความมั่นใจในรหัสเพราะพวกเขารู้ว่ามันแย่มากและมีข้อบกพร่องมากมายในตัวมัน

คุณเห็นข้อบกพร่องด้วยวิธีนี้หรือไม่? ข้อเสียใด ๆ ที่อาจเกิดขึ้น?

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

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

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

หากคุณมีวิธีที่ดีกว่าคุณจะแบ่งปันหรือเสนอลิงก์ไปยังบทความหรือการสนทนาเกี่ยวกับเรื่องนี้หรือไม่?

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

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

ไชโย