วิธีที่แนะนำในการแยกการพัฒนาในปัจจุบันออกจากการพัฒนาการบำรุงรักษาในซอฟต์แวร์ควบคุมเวอร์ชันคืออะไร

ฉันมีแอปพลิเคชั่นซอฟต์แวร์บางตัวที่จัดการโดยใช้ Git ฉันเพิ่งเปิดตัวรุ่นใหม่ 2.x ซึ่งฉันวางแผนที่จะรักษาในระยะยาว (แก้ไขข้อผิดพลาดส่วนใหญ่) ในระหว่างนี้ฉันอยากเริ่มทำงานกับเวอร์ชัน 3.x วิธีที่แนะนำในการจัดการสิ่งนี้คืออะไร? ฉันควรสร้างสาขาสำหรับเวอร์ชัน 2.x และมีการพัฒนา 3.x บนต้นแบบหรือไม่? หรือวิธีอื่น ๆ ?

version-control git

— Laurent
แหล่งที่มา

มีสาขาต่าง ๆ สำหรับการพัฒนาและมีเสถียรภาพ

— Oded

ดังนั้นสิ่งที่มักจะเข้าสู่สาขาหลัก? (จนถึงขณะนี้ฉันมักจะทำทุกอย่างที่นั่น)

— Laurent

คุณต้องตัดสินใจว่าคุณต้องการmasterหมายถึงอะไร มันเป็นเพียงฉลาก

— Oded

คำตอบ:

อธิบายวิธีที่น่าสนใจมากในการทำสิ่งต่าง ๆ ที่นี่: แบบจำลองการแยกสาขาของ Git ที่ประสบความสำเร็จ

ฉันพบว่ามันน่าสนใจมาก แต่ยังไม่ได้ใช้จริง

ดีมากตามที่ขอสรุปสั้น ๆ (มาก) ของสิ่งที่บทความพูดว่า:

สาขาหลักจะแสดงทุกเหตุการณ์สำคัญที่เสร็จสิ้นแล้ว (เช่นเวอร์ชัน 1.0, 1.1, 1.2 และอื่น ๆ )
การพัฒนาทำในสาขาของตัวเอง (ชื่อสะดวก "พัฒนา" ใครจะมีความคิด?) สาขาการพัฒนาจะถูกรวมกลับเข้าไปในสาขาหลักเมื่อใดก็ตามที่มีการทำเวอร์ชั่นเสร็จสมบูรณ์
การแตกแขนงออกจากการพัฒนาคือกิ่งคุณลักษณะ คุณสมบัติเหล่านี้เป็นคุณสมบัติเดียวสำหรับการเปิดตัวครั้งต่อไป (หรืออนาคต) พวกเขารวมกลับกับสาขาพัฒนา
อีกสาขาที่มาจากการพัฒนาคือสาขา "ปล่อย" นี่เป็นสาขาที่แสดงถึงเวอร์ชั่นที่วางจำหน่ายเกือบจะสมบูรณ์ซึ่งต้องทำความสะอาดรายละเอียดเล็กน้อย มันผสานกับสาขาการพัฒนาและท้ายที่สุดกับสาขาต้นแบบ
"Hotfix" แยกสาขาจากสาขาหลักหากคุณพบข้อบกพร่องที่รุนแรงในการเผยแพร่ของคุณ (เช่น "หากการใช้งานป้อนรหัส konami โปรแกรมของเราจะจัดรูปแบบฮาร์ดไดรฟ์หลัก ... ") เป็นสาขาของจากการเปิดตัวรถและเมื่อการแก้ไขเสร็จสิ้นจะถูกรวมกลับเข้าไปในสาขาหลักและสาขา devlopment

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

— Sorcy
แหล่งที่มา

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

— yannis

+1 สวยมากที่เราใช้ในที่ทำงานและมันใช้งานได้จริง

— Ed James

ฉันเชื่อว่านี่เป็นเรื่องปกติที่เรียกว่าโมเดล "trunk trunk" หรือ "ฟีเจอร์ Branch"

— sleske

"สาขาหลักจะแสดงเฉพาะเหตุการณ์สำคัญที่เสร็จสิ้นแล้ว (เช่นเวอร์ชัน 1.0, 1.1, 1.2 และอื่น ๆ )" ฉันไม่ต้องการสาขาหลักที่มีเวอร์ชัน 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 ใน คำสั่งนั้นจะทำให้สับสนจริงๆ ฉันเดาว่ามีข้อสันนิษฐานโดยนัยว่ามีอย่างน้อยหนึ่งสตรีมที่เผยแพร่เสร็จแล้วนั่นไม่ใช่กรณีในการปฏิบัติของฉัน มีผู้ใช้ในช่วงต้นและผู้คนต้องการบางสิ่งที่มีเสถียรภาพ

— AProgrammer

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

— Sorcy

หลักการของฉันคือยิ่งระยะสั้นสาขายิ่งลึกควรอยู่ในโครงสร้างสาขาและยิ่งชื่อจะยิ่งเฉพาะ ในระยะยาวสาขาคือตื้นกว่ามันจะอยู่ในโครงสร้างสาขาและชื่อทั่วไปจะมากกว่า

ดังนั้นคุณจะต้องรักษาต้นแบบของคุณสำหรับเวอร์ชันที่ยาวขึ้น (3.X) และคุณจะตั้งชื่อสาขานี้ด้วยชื่อสามัญ (master, trunk, devel, ... ) และไม่ใช่ชื่อเฉพาะ (ชื่อรหัสการปล่อย ซึ่งขึ้นอยู่กับการตัดสินใจในการทำการตลาดล่าช้ามากเกินไป)

มันไม่สำคัญมากในระบบเช่นคอมไพล์ที่มีพื้นที่ชื่อแบนสำหรับสาขาและสาขาที่เทียบเท่า มันมีความสำคัญมากขึ้นกับระบบเช่น clearcase ซึ่งมีเนมสเปซลำดับชั้นสำหรับสาขา (ชื่อเต็มของสาขา V4 จบลงด้วยการทำให้ bee / main / v1 / v2 / v3 / v4 ... )

— AProgrammer
แหล่งที่มา

+1 ยกเว้นฉันไม่ทราบว่าลึกและตื้นจริงๆหมายถึงอะไรในบริบทนี้บางทีคุณอาจขยายในแง่เหล่านั้นเล็กน้อย?

— Michael Durrant

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

— AProgrammer