เราสามารถใช้ git-flow อย่างมีประสิทธิภาพในโครงการที่มีการรักษามากกว่าหนึ่งเวอร์ชันหลักได้อย่างไร?

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

โดยเฉพาะฉันไม่ได้รักษา "รุ่นฟรี" และ "รุ่นที่จำหน่ายได้แล้ว" หรือรุ่นขนานอื่น ๆ ฉันกำลังพูดถึงโปรเจ็กต์ที่เวอร์ชัน 1 จะวางจำหน่ายและยังคงรองรับเวอร์ชันรอง (1.1, 1.2 และอื่น ๆ ) .) จนกว่าเวอร์ชั่น 3 จะวางจำหน่าย ณ จุดที่ 2 และ 3 จะได้รับการปรับปรุงจนกว่าจะมีการเปิดตัว 4 ... คุณจะได้รับแนวคิด

คุณมีหรือจะดูแลรักษาโครงการที่สนับสนุนสองเวอร์ชันหรือมากกว่าในคราวเดียวในเวิร์กโฟลว์ gitflow

git workflows gitflow

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

ไม่มีตัวอย่างใด ๆ แต่โครงการที่ฉันรู้จักใช้ที่เก็บแยกต่างหากสำหรับเวอร์ชันหลักที่แตกต่างกันและ backport patches จากที่หนึ่งไปยังอีกที่หนึ่ง

— มหัศจรรย์

@ProdigySim: ขอบคุณสำหรับจุดข้อมูล แต่เป็นเพียงฉันหรือว่าจะเพิ่มจำนวนค่าใช้จ่ายในการติดตามและจัดการ?

— HedgeMage

@ProdigySim ฉันสงสัยว่าโครงการเหล่านั้นไม่ได้ใช้เครื่องมือที่มีความสามารถในการแยกและรวมเข้าด้วยกันของ git

— Rein Henrichs

@Rein พวกเขาใช้ Mercurial ฉันไม่คิดว่าการแยกสาขาจะสะอาดมากในแง่ของการติดตามซอฟต์แวร์รุ่นใหญ่ขนาน

— มหัศจรรย์

จากนั้นความสงสัยของฉันก็ถูกต้อง และใช่มันค่อนข้างสะอาดหากเครื่องมือของคุณรองรับอย่างถูกต้อง git และเคอร์เนล Linux ทั้งสองทำแบบนี้

— Rein Henrichs

คำตอบ:

man gitworkflowsพ่อที่ยิ่งใหญ่ของเวิร์กโฟลว์ 'git flow' อธิบายแนวทางเวิร์กโฟลว์ git ทั่วไป การใช้pu, next, masterและmaintสาขา และวิธีการmaintจัดการ หากคุณมีสาขาการบำรุงรักษาหลายรายการคุณสามารถตั้งชื่อพวกเขาตัวอย่างเช่นmaint/1.x, maint/2.xและอื่น ๆ

กุญแจไม่ใช่วิธีการใช้คำสั่ง git มากนัก แต่จะสร้างกระบวนการที่สมเหตุสมผลได้อย่างไร ตัดสินใจว่าอะไรคือสิ่งสำคัญสำหรับคุณ (ความสะดวกในการ backport?) และสร้าง (และเอกสาร) เวิร์กโฟลว์ที่สอดคล้องกับข้อ จำกัด เหล่านั้น

— Rein Henrichs
แหล่งที่มา

แต่นี่ตอบคำถามได้ไหม? คือ git-flow สนับสนุนรูปแบบการเปิดตัวที่ยืดหยุ่นตามที่อธิบายไว้ในคำถามหรือไม่หรือย้อนกลับไปใช้คำสั่ง git ขั้นพื้นฐานหรือไม่ ("gitworkflows" อธิบายการใช้งานเวิร์คโฟลขั้นพื้นฐาน git-pre-git-flow) Git-flow ถูกสร้างขึ้น (อย่างชัดเจน) เพื่อลดความซับซ้อนของกระบวนการผสาน / สาขาของ git ดังนั้นทีม (ที่มีความหลากหลายของ git-fu ฤทธิ์) สามารถมุ่งเน้นการเข้ารหัสและ หลีกเลี่ยงข้อผิดพลาด "การรวมที่ผิดพลาด" ซึ่งใช้เวลานาน เป็นไปได้ที่จะมีการไหลของ git-flow เพื่อรักษาและพัฒนา v1.2 {1,2,3, .. } ในเวลาเดียวกันกับ v2.5 {1,2,3, ... }? บางทีอาจมีการเปิดสาขาในระยะยาว? หรือ master1, master2, ... ?

— ไมเคิล

โดยทั่วไปคุณจะซ้ำกันmaster, releaseและdevelopสาขาทุกรุ่นใหญ่ที่คุณยังคง พวกเขามีปฏิสัมพันธ์กันอย่างไรยังคงเหมือนเดิม สำหรับfeatureสาขาตรวจสอบให้แน่ใจว่าได้แยกสาขาจากสาขาที่เก่าแก่ที่สุดที่คุณตั้งใจจะผสานกลับเข้าไปซึ่งป้องกันการดึงที่ไม่ต้องการ จากนั้นเมื่อคุณรวมfeatureสาขาของคุณกลับเข้ามาคุณเพียงแค่ทำการผสานเพิ่มเติมเข้าไปในแต่ละสาขาที่สำคัญกว่ารุ่นใหม่

— Karl Bielefeldt
แหล่งที่มา

ไม่ใช่จุดรวมของการรวมทุกรุ่นที่วางจำหน่ายใช่หรือไม่

— HedgeMage

@HedgeMage ในรอบการปล่อยเชิงเส้นมากขึ้นเป็นกรณี แต่ที่ไม่สามารถใช้ได้กับรุ่นหลักแบบขนาน

— Karl Bielefeldt

ดูเหมือนว่าจะเป็นวิธีการแก้ปัญหาที่ใช้งานได้จริงที่สุดเว้นแต่จะมีเคล็ดลับที่พยายามและเป็นจริงโดยใช้โปรแกรมแก้ไขด่วนหรือสิ่งที่ฉันไม่ทราบ ฉันค้นหาวิธีที่จะแนะนำ git-flow และยังสามารถ (เป็นสิ่งที่จำเป็นต้องมีโชคร้าย) เพื่อรักษารูปแบบการเปิดตัวที่มีอยู่ของเราซึ่งเราต้องรักษา / พัฒนารุ่นที่เก่ากว่า (ไม่ใช่แค่โปรแกรมแก้ไขด่วน) ดังนั้น v5.1.x จะติดอยู่ (เพิ่มฟีเจอร์ใหม่แก้ไขบั๊ก ฯลฯ ) สองสามปีหลังจาก v6.1.x วางจำหน่าย มีประมาณ 2-3 เวอร์ชันที่สำคัญได้รับการสนับสนุนและพัฒนาตามเวลาที่กำหนด แต่การแก้ไขข้อบกพร่องจะต้องนำไปใช้กับแต่ละรุ่นที่มีข้อผิดพลาดอยู่

— ไมเคิล