เรากำลังพยายามนำรูปแบบการแยกส่วน Git ที่ประสบความสำเร็จมาใช้โดย git-flow ตอนนี้เรากำลังดำเนินการอย่างน้อยสองสาขาสำหรับรุ่นที่มีความเสถียรล่าสุดและอีกหนึ่งสาขาสำหรับรุ่นถัดไป ("ดูตัวอย่าง") สิ่งที่ฉันไม่เข้าใจคือทำไมทุกรุ่นดูเหมือนจะ "เป็นเส้นตรง" สำหรับต้นแบบและติดแท็ก ทำไมไม่ติดแท็กการเผยแพร่ในสาขาการเผยแพร่ของตน ทำไมต้องเป็นนายเลย? หรือทำไมสาขาพัฒนาและไม่ใช้หลักสำหรับมัน?
คำตอบ:
ในโมเดล git-flow เวอร์ชัน "ล่าสุดที่เปิดตัว" ของคุณจะจับคู่กับเวอร์ชันจริงในmasterขณะที่ "เวอร์ชันตัวอย่าง" จะจับคู่กับreleaseสาขาgit-flow มันถูกแยกออกจากกันdevelopและรวมเข้าด้วยกันในที่สุดmasterเมื่อการเปิดตัวจริงเกิดขึ้น จากนั้นสิ่งนี้จะกลายเป็น "รุ่นล่าสุด" ของคุณและโดยปกติคุณจะแก้ไขเฉพาะจุดบกพร่องสำหรับรุ่นนั้นโดยใช้hotfixสาขาgit-flow ด้วยวิธีนี้คุณmasterจะแสดงสถานะที่เสถียรที่สุดของเวอร์ชันที่เผยแพร่ล่าสุดของคุณเสมอ
หากคุณต้องการแก้ไขข้อบกพร่องสำหรับรุ่นเก่าหรือทำการพัฒนาอื่น ๆ ที่นั่นคุณจะแยกsupportสาขาจากการคอมมิตที่เหมาะสมmaster(คุณจะมีทุกเวอร์ชันที่เคยสร้างไว้ที่นั่น) supportสาขายังคงอยู่ในระหว่างการทดลอง ( ตามเอกสาร ) และไม่ได้รับการจัดทำเป็นเอกสารอย่างดี แต่อย่างที่คุณเห็นจากวิธีใช้บรรทัดคำสั่ง:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
สาขาเหล่านี้จะเริ่มต้นเพียงและไม่ได้มีเจตนาที่จะผสานกลับไปมิได้master developซึ่งมักจะเป็นปรับการแก้ไขเพื่อเผยแพร่ "โบราณ" หรือคุณสมบัติที่ต้องการโดยลูกค้าจะได้รับการดำเนินการใน "โบราณ" masterรุ่นที่ไม่สามารถหรือไม่ควรกลับไปเป็น หากคุณยังคิดว่าคุณต้องการจัดพอร์ตการแก้ไขไปยังสายการพัฒนาหลักของคุณ (แสดงโดยmasterและdevelop) เพียงแค่เริ่มต้นhotfixเลือกการเปลี่ยนแปลงของคุณและทำไฟล์hotfix.
git flow supportไม่ได้ถูกทำเครื่องหมายว่าทดลอง
ดูเหมือนส่วนใหญ่จะเป็นแบบจำลองทางจิตที่เน้นสาขามากเกินไป ฉันเห็นด้วยคุณสามารถติดแท็กคอมมิตที่คุณปล่อยแทนที่จะรวมกลับเป็นมาสเตอร์
แม้ว่าภาพจะสวย การรวมทุกอย่างกลับเป็นหลักช่วยให้สามารถระบุการเผยแพร่ตามลำดับเวลาได้อย่างชัดเจนแทนที่จะมีแท็กเวอร์ชันเกลื่อนไปทั่วกราฟ
ฉันคิดว่าโมเดลนี้ใช้ไม่ได้กับการแก้ไขข้อบกพร่องในรุ่นเก่า มันทำให้การจัดระเบียบเรียบร้อย
เพื่อตอบคำถามของคุณ: ฉันคิดว่านี่เป็นชุดของกฎที่สร้างขึ้นสำหรับแบบจำลองทางจิตใจที่เรียบง่ายในบางกรณี ไม่ใช่กฎทั้งหมดที่สมเหตุสมผลจากมุมมองทางเทคนิคอย่างเดียว แต่ก็ไม่ได้ทำให้เกิดผลเสีย แบบจำลองทางจิตเป็นสิ่งที่ดีสำหรับพวกเขา
supportสาขาได้รับการออกแบบมาสำหรับการแก้ไขข้อบกพร่องในรุ่นเก่าแม้ว่าจะยังคงระบุว่าเป็น 'การทดลอง'
โดยส่วนตัวฉันคิดว่า git-flow ที่กล่าวถึงนั้นซับซ้อนเกินไป
หากคุณใช้ GitHub ให้ลองใช้GitHub flow(ตามที่อธิบายโดย Scott Chacon)
เป็นประโยชน์อย่างยิ่งสำหรับการทำงานร่วมกันในหลายคุณสมบัติการตรวจสอบโค้ดและคุณสามารถรวมเข้ากับโซลูชันการผสานรวมอย่างต่อเนื่องโดยใช้ไฟล์Commit Status API.
อัปเดต : มีเว็บไซต์ใหม่อย่างเป็นทางการของ The GitHub Flow ™
อัปเดต 2 : มีคู่มือ GitHub ใหม่อย่างเป็นทางการ (และใช้งานง่าย) สำหรับ GitHub Flow ™: https://guides.github.com/introduction/flow/
masterความผิดปกติของลำดับเหตุการณ์ของงาน
supportสาขาที่มีไว้สำหรับ แต่คุณพูดถูกจริงๆแล้วมันเป็นความผิดปกติที่ไม่ได้รวมรุ่นดังกล่าวกลับเข้าไปmasterซึ่งตามความเข้าใจของฉัน - ควรจะถือรุ่นที่ใช้งานจริงทั้งหมด
ในกรณีของฉันฉันมีซอฟต์แวร์เดียวกันสองเวอร์ชันที่พื้นฐานเหมือนกัน แต่แต่ละเวอร์ชันมีคุณสมบัติที่แตกต่างกัน
ดังนั้นฉันจึงสร้างสองอันworktreeนั่นหมายความว่าสร้างสองสาขาที่เกี่ยวข้องกันมานานข้างต้นแบบ
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
จากนั้นฉันมี:
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
มีที่เก็บเดียว แต่ฉันมี 3 โฟลเดอร์แยกกันสำหรับแต่ละสาขาด้านบน และทำการเปลี่ยนแปลงทั่วไปในต้นแบบ จากนั้นรวมเข้ากับเวอร์ชันอื่นทั้งสอง
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
การเปลี่ยนแปลงเฉพาะของแต่ละเวอร์ชันจะไปอยู่ในโฟลเดอร์ที่เกี่ยวข้องเช่นกันและงานในแต่ละโปรเจ็กต์จะถูกแยกออกและ IDE จะไม่สับสน
หวังว่าจะช่วยได้
เห็นด้วยอย่างยิ่งกับ @Mot
ยินดีที่ได้รับฟังคำถามเดียวกันนี้
ทีมงานของเราก็ยังตามล่าหาข้อมูลเพิ่มเติมรูปแบบแตกแขนงสากลกว่าที่ประสบความสำเร็จอย่างใดอย่างหนึ่ง เช่นตามที่ @Mot กล่าวไว้ข้างต้น - แนวคิดหลักคือการหลีกเลี่ยงการแนะนำที่เก็บเพิ่มเติมสำหรับการสนับสนุน release- * branch ใน repo * .git แยกต่างหากเนื่องจากเป็นตัวอย่างที่ทำโดย kernel.org สำหรับรีลีสที่เสถียร แต่ kernel.org ทำเพื่อลดขนาดที่ดาวน์โหลดให้น้อยที่สุดฉันเดา
สำหรับฉันมันดูเหมือนว่ามันสะอาดมากขึ้นที่จะมีต้นแบบเป็นฉีดสำหรับการพัฒนา
นอกจากนี้ยังมีข้อขัดแย้งบางอย่างในโมเดลการรวมรุ่น - *เพื่อควบคุมและติดแท็กในภายหลังด้วยแนวคิด
ใช้สคริปต์ Git hook เพื่อสร้างและเปิดตัวซอฟต์แวร์ของเราไปยังเซิร์ฟเวอร์ที่ใช้งานจริงโดยอัตโนมัติทุกครั้งที่มีข้อผูกมัดกับมาสเตอร์
สาเหตุการตกแต่ง (การรวมและการแท็ก)ไม่ใช่ธุรกรรมปรมาณู:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
และถ้า git hook เริ่มสร้างด้วยการสนับสนุนการกำหนดเวอร์ชันอัตโนมัติ:
$git describe --tags --long >.ver
จากนั้นอาจสร้างเวอร์ชันที่ผิดพลาดสำหรับ:
$ git merge --no-ff release-1.2
ฉันรู้ว่าการกำหนดเวอร์ชันในSuccessfullหนึ่งแนะนำกระบวนการ Bump-Version แต่ไม่ใช่แบบอัตโนมัติ
ดังนั้นเพื่อสรุป - ความแตกต่างที่สำคัญที่เราแนะนำกับโมเดลสาขาสำหรับการเผยแพร่ - * การรวมและการติดแท็กคือ - การติดแท็กรีลีสในการสร้างสาขา - เก็บสาขาของรีลีสไว้เพื่อเปิดใช้งานการบำรุงรักษาในอนาคต
สาขาหลักควรเป็นตัวแทนของฐานรหัสการผลิตของคุณเสมอดังนั้นคุณจึงรวมรหัสกลับไปที่ต้นแบบทันทีหลังจากเผยแพร่เวอร์ชันที่ใช้งานจริง
การแท็กใช้เพื่อ "จดจำ" โค้ดที่ถูกต้องซึ่งเข้าสู่รุ่นที่ใช้งานจริงเพื่อให้คุณสามารถย้อนกลับไปวิเคราะห์โค้ดได้ในภายหลังหากมีสิ่งผิดปกติเกิดขึ้น
ด้วยวิธีนี้ในทางทฤษฎีจึงไม่สำคัญว่าคุณจะติดแท็กโค้ดของคุณในสาขาการเผยแพร่หรือสาขาหลักหลังจากที่คุณรวมกลับเป็นหลัก โดยส่วนตัวแล้วฉันชอบที่จะติดแท็กโค้ดในสาขารีลีสเนื่องจากนี่คือโค้ดที่เข้าสู่บิลด์ / รีลีส (สมมติว่ามีบางอย่างผิดพลาดกับการผสาน)
ปัญหาเกี่ยวกับแนวคิดสาขาการพัฒนาคือมันเป็นเธรดเดียว เบรนแดนในหัวข้อนี้ได้กล่าวถึงกลยุทธ์ที่สามารถใช้ได้กับแนวคิดสาขาการพัฒนา