รอบการเปิดตัวของ บริษัท แปลก: ไปควบคุมแหล่งที่มากระจาย

ขออภัยเกี่ยวกับโพสต์ที่ยาวนานนี้ แต่ฉันคิดว่ามันคุ้มค่า

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

ทีมเมื่อปีที่แล้วย้ายจาก Visual Source Safe ไปยัง Team Foundation Server ปัญหาคือพวกเขายังคงใช้ TFS ราวกับว่ามันเป็น VSS และบังคับใช้ Checkout ล็อคในสาขารหัสเดียว เมื่อใดก็ตามที่การแก้ไขข้อผิดพลาดถูกนำออกสู่สนาม (แม้กระทั่งสำหรับลูกค้าเดี่ยว) พวกเขาเพียงแค่สร้างสิ่งที่อยู่ใน TFS ทดสอบข้อผิดพลาดได้รับการแก้ไขและปรับใช้ให้กับลูกค้า! (ตัวเองมาจากพื้นหลังของซอฟต์แวร์ยาและอุปกรณ์การแพทย์ซึ่งไม่น่าเชื่อเลย!) ผลที่ได้คือรหัส dev ที่อบออกมาครึ่งหนึ่งถูกนำไปผลิตโดยไม่ต้องมีการทดสอบ บั๊กมักจะลื่นไถลไปสู่รุ่นวางจำหน่าย แต่บ่อยครั้งที่ลูกค้าที่เพิ่งได้รับบิลด์จะไม่เห็นบั๊กเหล่านี้หากพวกเขาไม่ได้ใช้คุณสมบัติที่บั๊กนั้นอยู่ผู้อำนวยการรู้ว่านี่เป็นปัญหาเพราะ บริษัท เริ่มเติบโต ทันใดนั้นมีลูกค้ารายใหญ่บางรายเข้ามาและมีลูกค้าจำนวนน้อยกว่า

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

ก่อนหน้านี้ทีมส่วนใหญ่ที่ฉันทำงานด้วยใช้โซลูชันสองหรือสามสาขาของ Dev-Test-Prod ซึ่งเป็นเวลาหนึ่งเดือนที่นักพัฒนาทำงานโดยตรงใน Dev แล้วการเปลี่ยนแปลงจะถูกรวมเข้ากับ Test แล้ว Prod หรือเลื่อนขั้นเมื่อทำเสร็จแทนที่จะเป็น รอบคงที่ มีการใช้งานบิลด์อัตโนมัติโดยใช้ Cruise Control หรือ Team Build ในงานก่อนหน้านี้ Bazaar ของฉันเคยนั่งอยู่ด้านบนของ SVN: devs ทำงานในฟีเจอร์ย่อย ๆ ของพวกเขาเองจากนั้นก็ผลักดันการเปลี่ยนแปลงไปสู่ ​​SVN (ซึ่งผูกติดกับ TeamCity) นี่เป็นเรื่องดีที่มันแยกการเปลี่ยนแปลงได้ง่ายและแบ่งปันกับสาขาอื่น ๆ ของประชาชน

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

ด้วยข้อกำหนดนี้วิธีการ "บูรณาการอย่างต่อเนื่อง" ตามที่ฉันเห็นมันล้มเหลว ในการรับฟีเจอร์ใหม่ด้วยการผนวกรวมอย่างต่อเนื่องจะต้องผลักดันผ่าน dev-test-prod และจะจับงานที่ยังไม่เสร็จใน dev

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

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

ประชาชนคิดอะไรเกี่ยวกับเรื่องนี้?

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

DVCS คืออะไร

กระจายใน DVCS หมายความว่าโคลนของพื้นที่เก็บข้อมูลทุกคนมีข้อมูลทั้งหมดที่จำเป็นในการกระทำการปรับปรุงสาขาผสานหรือค้นหาการแก้ไขใด ๆ ในพื้นที่เก็บข้อมูลที่ไม่เคยสัมผัสเซิร์ฟเวอร์ สิ่งเดียวที่คุณสามารถทำได้ในแบบออฟไลน์svnคือแก้ไขไฟล์ - คุณจำเป็นต้องเข้าถึงเซิร์ฟเวอร์สำหรับsvnคำสั่งเกือบทั้งหมดรวมถึงการทำอะไรที่เรียบง่ายเหมือน grepping svn logและมันใกล้กว่า 0% ถึง 90%!

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

รูปแบบการแยกสาขาแบบใดที่เหมาะสม

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

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

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

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกเหล่านี้ดูคำตอบของฉันเกี่ยวกับกลยุทธ์ในการใช้การควบคุมเวอร์ชันในระบบโมดูลาร์ , วิธีใช้ที่เก็บข้อมูลการโค่นล้มภายใน Git Repository? และการควบคุมแหล่งที่มา / เวอร์ชันสำหรับการประยุกต์ใช้โดยหลาย บริษัท

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

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

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

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

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

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

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

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

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

คำถามที่สองนั้นง่ายกว่าและสั้นกว่าดังนั้นฉันจะพยายามเริ่มจากมัน

DVCS เป็นระบบที่ไม่มีใคร "รหัส" แหล่งที่มาของรหัส (ยกเว้น "ในข้อตกลง" เมื่อใช้) และการแลกเปลี่ยนข้อมูลเป็นไปได้โดยไม่ต้อง P2P - ชั้นเพิ่มเติม (ส่วนบุคคลไม่ใช่บัญญัติ - บัญญัติ)

ในหัวข้อคำถามแรก

ฉันกลัวว่า บริษัท จะต้องสร้างเวิร์กโฟลว์และคิดใหม่เกี่ยวกับสไตล์เพื่อรับ "รหัสที่จัดการและคาดเดาได้" ฉันไม่สามารถพูดเกี่ยวกับ TFS (ยกเว้นความเห็นส่วนตัวและความรู้สึกว่ามันเป็นระบบที่อ่อนแอในส่วนการควบคุมเวอร์ชัน / การผสานที่ไร้เหตุผลเป็นความชั่วร้าย /) แต่สำหรับ VCS ใด ๆ ในสถานการณ์ของคุณ ("ผลิตภัณฑ์" เป็นชุด "โมดูล" อิสระ "ลูกค้า" แต่ละคนจะได้รับ "ผลิตภัณฑ์" ที่แตกต่างกัน - นี่เป็นข้อสันนิษฐานที่ถูกต้องหรือไม่) ฉันต้องการแยกการพัฒนาโมดูลออกเป็นสาขาแยกกันให้มีผลิตภัณฑ์เป็น "Supermodule" (เช่นสาขา) ด้วยแต่ละโมดูลเชื่อมโยงกับการแก้ไขเฉพาะโมดูล branch, module-development ใช้กระบวนทัศน์ branch-per-task (และ module-branch ประกอบด้วยจากการผสานเท่านั้น)

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

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

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

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

ในคอมไพล์สาขาคุณลักษณะกว่าเงินไปnext, masterหรือmaintขึ้นอยู่กับที่ปล่อยมันมีการกำหนดเป้าหมายที่ (maint สำหรับ bugfixing รุ่นปัจจุบันต้นแบบสำหรับปัจจุบันเป็นอิสระในการเตรียมความพร้อมและต่อไปเป็นเวลาหนึ่งหลังจากนั้น) แต่คุณจะไม่ได้ว่าหลาย ๆ

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

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

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

น่าเสียดายที่ไม่มีวิธีการแก้ไขข้อบกพร่องในรหัส :)

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

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

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

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

DVCS:

โดยพื้นฐานแล้ว DVCS เป็นที่ที่ทุกคนมีสำเนา repo ของตนเอง มันมีข้อดีบางอย่าง (โดยเฉพาะในทีมที่มีการแจกจ่าย จำกัด ) แต่ก็มีข้อเสียเช่นกันดังนั้นลองดูพวกเขาก่อนที่คุณจะเปลี่ยนเป็น DVCS หากคุณเป็นร้านค้า Windows คุณอาจพบว่า Mercurial เป็น DVCS ที่ดีที่สุดสำหรับคุณ