ควรสร้างสาขาการพัฒนาเมื่อใด

เรากำลังย้ายทีมงานโครงการของเราจากการใช้สาขาหลัก / ลำต้นเดียวไปยังสาขาการพัฒนา / การทำงานหลายสาขาที่ควรรวมเป็นหลักอย่างสม่ำเสมอ เรากำลังพิจารณากระบวนการใหม่ของเราในบทความนี้และคู่มือการแบ่งสาขาของ TFS (เรากำลังใช้ TFS และ Visual Studio 2010)

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

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

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

ใครบ้างมีคำแนะนำเกี่ยวกับเรื่องนี้?

ฉันไม่ชอบกิ่งไม้ตามอำเภอใจเช่น Fred's bugfixes หรือ bugfixes ของ Harry ฉันรู้สึกสบายใจกับฟีเจอร์หนึ่ง (อิสระ) หนึ่งสาขาที่อนุญาตให้นักพัฒนาหลายคนทำงานบนฟีเจอร์เดียว แต่สำหรับคุณลักษณะที่จะผสานเมื่อเสร็จสมบูรณ์เท่านั้น

ดังนั้นตอนนี้คุณเพียงต้องการสาขา "แก้ไขข้อบกพร่อง" แต่เมื่อคุณเริ่มพัฒนาคุณควรสร้างสาขาสำหรับทุกฟีเจอร์ที่สำคัญ ด้วยวิธีดังกล่าวเมื่อดำเนินการเสร็จแล้วพวกเขาสามารถรวมเข้าและออกโดยไม่ต้องอาศัยฟังก์ชั่นบั๊กเกอร์อื่น ๆ

ไม่แน่ใจว่า TFS นั้นมีการผสานที่ดีเพียงใด แต่ฉันแน่ใจว่าคุณจะรู้ในไม่กี่เดือนนี้ :)

เราไม่สามารถผ่านสาขาการพัฒนาเดียวเพราะเราต้องการที่จะผสานกับหลักในขณะที่งานอื่นเสร็จสมบูรณ์

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

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

ทำงานสาขาโดยนัยกับ DVCS

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

เราแทบจะไม่เคยสร้างกิ่งก้านที่ชัดเจน แต่จากนั้นการวิ่งอีกครั้งของเราจะไม่เกิน 1 สัปดาห์และบัตรใช้เวลาไม่เกิน 1-2 วันในการดำเนินการ

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

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

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