เวิร์กโฟลว์ Git ที่เหมาะสมสำหรับการเปิดใช้งานหลายครั้งในขณะที่จัดการโปรแกรมแก้ไขด่วน


30

ฉันกำลังพยายามเลือกเวิร์กโฟลว์ Git ที่เหมาะสมที่สุดสำหรับผลิตภัณฑ์ของเรา นี่คือพารามิเตอร์:

  • เรามีการเปิดตัวรุ่นใหญ่สองสามครั้งต่อปีสมมติว่ามากที่สุด 10 รายการ
  • เรามีผลิตภัณฑ์หลายเวอร์ชันที่ใช้งานอยู่ในเวลาเดียวกัน (บางคนอยู่ใน v10.1, บางคนใน v11.2 ฯลฯ )
  • เราต้องสามารถทำงานกับหลาย ๆ รุ่นได้ในเวลาเดียวกัน (ดังนั้นเราจึงสามารถทำงานกับ v12.1 ได้ แต่เมื่อเราถึงจุดสิ้นสุดของการวางจำหน่ายเราจะเริ่มทำงานกับ v12.2 ในเวลาเดียวกัน)
  • เราจำเป็นต้องสามารถเผยแพร่โปรแกรมแก้ไขด่วนเมื่อพบข้อบกพร่องที่สำคัญ

จนถึงตอนนี้เป็นวิธีที่ฉันคิดว่าสามารถใช้งานได้:

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

ฉันมีข้อกังวลเล็กน้อย:

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

ความคิดเห็นเป็นที่ชื่นชมในสิ่งที่ฉันอาจมองข้ามหรือทำสิ่งที่ดีกว่าให้สำเร็จตามข้อกำหนดที่ฉันได้ระบุไว้



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

หากคุณต้องการ hot fix หลายรีลีสด้วยการแก้ไขเดียวกันคุณควรแก้ไขเวอร์ชันที่เก่าที่สุดก่อนและรวมถึงใหม่กว่าปรับให้เหมาะสำหรับแต่ละรีลีส หากคุณทำงานตั้งแต่ใหม่จนถึงเก่าคุณอาจเสี่ยงต่อการพึ่งพาจากการเผยแพร่ในภายหลังซึ่งจะทำให้สิ่งต่าง ๆ ซับซ้อนขึ้น
axl

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

คำตอบ:


9

ดูเหมือนว่าคุณจะแตกแขนงออกในทุกรุ่นที่สำคัญ (12.0.0) จากนั้นมีการปรับปรุงเล็กน้อยที่เป็นไปได้สำหรับแต่ละ (12.1.0) และฮอตฟิกซ์ (12.2.1) แก้ไข?

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

ฉันจะติดกับ GitFlow และทำการแก้ไขเล็กน้อย;

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

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

หากคุณต้องทำงานควบคู่ไปกับคุณสมบัติสำหรับรุ่นใหญ่หลายรุ่นในอนาคตในเวลาเดียวกันบางทีคุณอาจต้องพัฒนารุ่นต่อไป (13) และสิ่งอื่น ๆ สำหรับรุ่นต่อมา (14, 15) สำหรับสาขา "Develop-N" เพิ่มเติม . ดูเหมือนจะยากมากที่จะรักษาโดยทั่วไป แต่จะเป็นไปได้


3

ดูเหมือนว่าทางออกที่เป็นไปได้สำหรับปัญหาหลักของคุณ ( «เราต้องสามารถทำงานกับหลาย ๆ รุ่นได้ในเวลาเดียวกัน [... ] » ) กำลังทำgit worktree add <path> [<branch>]

ที่เก็บ git สามารถรองรับต้นไม้ทำงานหลาย ๆ ต้นช่วยให้คุณสามารถตรวจสอบมากกว่าหนึ่งสาขาในเวลาเดียวกัน
ด้วยแผนผังgit worktree addการทำงานใหม่จะเชื่อมโยงกับที่เก็บ

ต้นไม้ต้นนี้การทำงานใหม่ที่เรียกว่า "การเชื่อมโยงต้นไม้ทำงาน" เมื่อเทียบกับ "ต้นการทำงานหลัก" จัดทำโดย " git init" หรือ "git clone "
ที่เก็บมีต้นไม้การทำงานหลักหนึ่งต้น (ถ้าไม่ใช่ที่เก็บเปลือย) และมีต้นไม้การทำงานเชื่อมโยงเป็นศูนย์หรือมากกว่า

ดูคำตอบดังนั้นนี้git worktreeสำหรับการแนะนำรายละเอียดเกี่ยวกับ


1

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

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

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


แต่อย่างที่ฉันพูดถึงในกรณีของ git-flow ดูเหมือนว่าพวกเขาจะใช้กิ่งก้านสาขาออกมาไม่มาก ดูเหมือนว่าจะไม่มีการพัฒนาที่สำคัญเกิดขึ้นที่นั่น ดูเหมือนว่าสาขาการพัฒนานั้นไร้ประโยชน์หากเราส่วนใหญ่ทำงานในสาขาการวางจำหน่ายและอาจจะกำจัดมันส่วนสาขาย่อยแต่ละสาขานั้นเป็นสาขาการพัฒนาในช่วงระยะเวลาหนึ่ง หรือว่าฉันขาดอะไรไป?
Rocket04
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.