Git branching รุ่นอะไรที่เหมาะกับคุณ?

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

1. เวิร์กโฟลว์ / โมเดลการแยกสาขา

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

   • gitworkflows (7) หน้าคู่มือ
   • (nvie) โมเดลการแยกสาขาของ Git ที่ประสบความสำเร็จ
   • (reinh) เวิร์กโฟลว์ Git สำหรับทีม Agile

2. การรวม vs การรีบูต (ประวัติเรียงตามกันพันกัน)

   ควรpull --rebaseหรือรอด้วยการรวมกลับไปที่การฉีดยาจนกว่างานของคุณจะเสร็จสิ้น? โดยส่วนตัวแล้วฉันโน้มตัวไปสู่การรวมตัวกันเพราะนี่เป็นการรักษาภาพประกอบที่แสดงให้เห็นว่างานเริ่มต้นและสิ้นสุดที่ใดและฉันก็ชอบmerge --no-ffจุดประสงค์นี้ด้วย มันมีข้อเสียอื่น ๆ อย่างไรก็ตาม หลายคนยังไม่ได้ตระหนักถึงคุณสมบัติที่มีประโยชน์ของการรวม - นั่นไม่ใช่การสับเปลี่ยน (การรวมสาขาหัวข้อเข้ากับต้นแบบไม่ได้หมายถึงการผสานต้นแบบเข้ากับหัวข้อหัวข้อ)

3. ฉันกำลังมองหากระบวนการทำงานที่เป็นธรรมชาติ

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

4. วิธีหลีกเลี่ยงการสร้างความขัดแย้งผสาน (เนื่องจากการเลือกโดยเชอร์รี่)

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

5. จะย่อยสลายเป็นกิ่งเฉพาะได้อย่างไร

   เราตระหนักดีว่าการรวบรวมการรวมเข้าด้วยกันจากหัวข้อต่างๆเป็นเรื่องที่ยอดเยี่ยม แต่บ่อยครั้งที่การทำงานของนักพัฒนาของเราไม่ได้ถูกกำหนดไว้อย่างชัดเจน (บางครั้งก็ง่ายเหมือนกับ มันไม่สามารถนำออกมาจากที่นั่นอีกครั้งตามคำถามข้างต้น? คุณทำงานกับการกำหนด / การอนุมัติ / การสำเร็จการศึกษา / การเปิดสาขาหัวข้อของคุณได้อย่างไร

6. ขั้นตอนที่เหมาะสมเช่นการตรวจสอบรหัสและการจบการศึกษาจะเป็นที่น่ารัก

   แต่เราไม่สามารถเก็บสิ่งที่ไม่พันกันได้มากพอที่จะจัดการสิ่งนี้ - คำแนะนำใด ๆ สาขาบูรณาการภาพประกอบ?

ด้านล่างเป็นรายการคำถามที่เกี่ยวข้อง:

• กลยุทธ์ที่ดีในการอนุญาตให้แอปพลิเคชันที่ปรับใช้นั้นสามารถแก้ไขได้มีอะไรบ้าง
• คำอธิบายเวิร์กโฟลว์สำหรับการใช้ Git เพื่อการพัฒนาภายใน บริษัท
• Git เวิร์กโฟลว์สำหรับการพัฒนาเคอร์เนลขององค์กร
• คุณรักษารหัสการพัฒนาและรหัสการผลิตได้อย่างไร (ขอบคุณสำหรับPDF นี้ !)
• git ออกการจัดการ
• Git Cherry-pick และ Merge Workflow
• วิธีการเลือกหลายเชอร์รี่
• คุณจะรวมไฟล์ที่เลือกด้วย git-merge ได้อย่างไร
• วิธีการเชอร์รี่เลือกช่วงของการกระทำและรวมเข้าไปในสาขาอื่น
• ReinH Git Workflow
• git เวิร์กโฟลว์สำหรับการแก้ไขคุณจะไม่ย้อนกลับไปที่จุดเริ่มต้น
• เชอร์รี่เลือกผสาน
• เวิร์กโฟลว์ Git ที่เหมาะสมสำหรับระบบปฏิบัติการรวมและรหัสส่วนตัว?
• การดูแลรักษาโครงการด้วย Git
• เหตุใดจึงไม่สามารถรวมไฟล์ Git กับผู้ปกครอง / ต้นแบบที่แก้ไข
• Git branching / rebasing แนวปฏิบัติที่ดี
• เมื่อใด "git pull --rebase" จะพาฉันไปพบปัญหา?
• DVCS มีการใช้งานอย่างไรในทีมขนาดใหญ่

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

ส่วนใหญ่หนักใจคุณลักษณะนักพัฒนาใหม่เพื่อ DVCS ต้องตระหนักเป็นเรื่องเกี่ยวกับการเผยแพร่ :

• คุณสามารถนำเข้า (ดึง / ดึง) สิ่งที่ repo ระยะไกลที่คุณต้องการ
• คุณสามารถเผยแพร่ (push) ไปยัง repo ใด ๆ (เปลือย) ที่คุณต้องการ

จากนั้นคุณสามารถเคารพกฎสองสามข้อเพื่อทำให้คำถามของคุณง่ายขึ้น:

• รีบูทสาขาเท่านั้นหากยังไม่ได้ถูกผลัก (ไม่ถูกผลักตั้งแต่รีบูตครั้งล่าสุด)
• ผลักดันไปยัง repo เปล่า (บังคับตั้งแต่ Git1.7)
• ปฏิบัติตามคำแนะนำของ Linus เกี่ยวกับการคืนเงินและการรวม

ขณะนี้:

เวิร์กโฟลว์ / โมเดลการแยกสาขา :

แต่ละเวิร์กโฟลว์อยู่ที่นั่นเพื่อสนับสนุนกระบวนการจัดการการปล่อยและที่เหมาะสำหรับแต่ละโครงการ
สิ่งที่ฉันสามารถเพิ่มในเวิร์กโฟลว์ที่คุณกล่าวถึงคือนักพัฒนาแต่ละคนไม่ควรสร้างสาขาฟีเจอร์เฉพาะสาขา "ผู้พัฒนาปัจจุบัน" เพราะความจริงก็คือ: นักพัฒนามักไม่รู้ว่าสาขาของเขา / เธอจะผลิตอะไร: หนึ่ง คุณลักษณะหลายอย่าง (เพราะท้ายที่สุดแล้วมันซับซ้อนเกินไป), ไม่มี (เพราะยังไม่พร้อมสำหรับการเปิดตัว), คุณสมบัติอื่น (เพราะต้นฉบับมี "morphed"), ...

มีเพียง "ผู้รวมระบบ" เท่านั้นที่ควรจัดตั้งสาขาคุณลักษณะอย่างเป็นทางการใน "ส่วนกลาง" repo ซึ่งนักพัฒนาซอฟต์แวร์สามารถเรียกคืนเพื่อรวม / รวมส่วนของงานที่เข้ากับคุณลักษณะนั้นได้

การรวม vs การรีบูต (ประวัติที่มีการพันกันตามลำดับ) :

ฉันชอบคำตอบที่คุณพูดถึง (" คำอธิบายเวิร์กโฟลว์สำหรับการใช้คอมไพล์เพื่อการพัฒนาภายในองค์กร ")

ฉันกำลังมองหากระบวนการทำงานตามธรรมชาติ :

สำหรับการแก้ไขมันสามารถช่วยเชื่อมโยงการแก้ไขแต่ละอย่างกับตั๋วจากการติดตามบั๊กซึ่งช่วยให้นักพัฒนาจำได้ว่า (เช่นสาขาใดคือสาขาเฉพาะสำหรับ "การแก้ไข") เขา / เธอควรกระทำการแก้ไขดังกล่าว
จากนั้น hooks สามารถช่วยป้องกัน repo ส่วนกลางจากการกดจากการแก้ไขข้อบกพร่องที่ไม่ผ่านการตรวจสอบหรือจากกิ่งที่ไม่ควรกด (ไม่มีวิธีแก้ปัญหาเฉพาะที่นี่ทั้งหมดนี้ต้องปรับให้เข้ากับสภาพแวดล้อมของคุณ)

วิธีหลีกเลี่ยงการสร้างความขัดแย้งผสาน (เนื่องจากการเลือกโดยเชอร์รี่)

ตามที่ระบุไว้โดยJakub Narębskiในคำตอบของเขาเชอร์รี่เก็บควรจะสงวนไว้สำหรับสถานการณ์ที่หายากที่จำเป็น
หากการตั้งค่าของคุณเกี่ยวข้องกับการเก็บเชอร์รี่จำนวนมาก (เช่น "มันไม่ได้หายาก") แสดงว่ามีบางอย่างปิดอยู่

จะใช้ความมุ่งมั่นเดียวกันในการย้อนกลับ (จะทำเช่นนี้ได้อย่างไร)

git revert ควรดูแลสิ่งนั้น แต่นั่นไม่เหมาะ

จะย่อยสลายเป็นกิ่งเฉพาะได้อย่างไร

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

• ถ้าจำเป็นหลายสาขา (หนึ่งโดยคุณสมบัติที่ระบุชัดเจน)
• ชุดของการกระทำที่เชื่อมโยงกันภายในหนึ่งสาขา (ดูการตัด Git Checkins )

ขั้นตอนที่เหมาะสมเช่นการตรวจสอบรหัสและจบการศึกษา?

การรวมสาขา (ในการรวมระบบโดยเฉพาะ) repo สามารถช่วยนักพัฒนาในการ:

• รีบูตการพัฒนาของเขา / เธอด้านบนของสาขาการรวมระยะไกลที่ (pull --rebase)
• แก้ปัญหาในท้องถิ่น
• ผลักดันการพัฒนาไปสู่ ​​repo นั้น
• ตรวจสอบกับผู้รวมที่ไม่ส่งผลให้เกิดความวุ่นวาย;)

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

ถ้าฉันมีความเข้าใจในการพัฒนาเคอร์เนล (ฉันจะมุ่งเน้นที่) ทุกคนมีพื้นที่เก็บข้อมูลคอมไพล์ของตัวเองสำหรับการพัฒนาเคอร์เนล มีที่เก็บหนึ่ง linux-2.6.git ซึ่งดูแลโดย Torvalds ซึ่งทำหน้าที่เป็นที่เก็บของรุ่น ผู้คนลอกแบบมาจากที่นี่หากพวกเขาต้องการเริ่มพัฒนาฟีเจอร์กับสาขา "ปล่อย"

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

ตอนนี้ที่นี่คือที่ที่มันได้รับความสับสน ชื่อสาขาไม่จำเป็นต้องสอดคล้องกันในที่เก็บข้อมูลเลย ดังนั้นผมจึงสามารถgit pull origin master:vanilla-codeและได้รับสาขาจากorigin's vanilla-codeโทสาขาในพื้นที่เก็บข้อมูลของฉันเรียกว่า ให้ฉันรู้ว่าสิ่งที่เกิดขึ้นมันไม่สำคัญ - มันมีการกระจายในแง่ที่ว่าที่เก็บข้อมูลทั้งหมดเป็นเพื่อนกันและไม่เพียงแค่แบ่งปันในคอมพิวเตอร์หลายเครื่องเช่น SVN

ดังนั้นด้วยทั้งหมดนี้ในใจ:

1. ฉันคิดว่ามันขึ้นอยู่กับโปรแกรมเมอร์แต่ละคนว่าพวกเขาทำงานแตกแขนงอย่างไร สิ่งที่คุณต้องมีคือที่เก็บส่วนกลางสำหรับจัดการการเผยแพร่ ฯลฯ Trunk อาจเป็นheadได้ รุ่นอาจเป็นแท็กหรือสาขาและโปรแกรมแก้ไขด่วนอาจเป็นสาขาในตัวเอง ในความเป็นจริงฉันอาจจะเผยแพร่เป็นสาขาเพื่อให้คุณสามารถแก้ไขได้
2. ฉันจะรวมและไม่ได้ลดราคา ตัวอย่างเช่นถ้าคุณใช้พื้นที่เก็บข้อมูลโคลนมันสาขาและการทำ dev บางแล้วดึงจากคุณoriginคุณควรในพื้นที่เก็บข้อมูลของคุณอาจทำให้สาขาอื่นและผสานล่าสุดmasterเข้ามาyourbranchเพื่อให้คนที่อื่นสามารถดึงการเปลี่ยนแปลงของคุณมีความพยายามน้อยที่สุดเท่าที่ เป็นไปได้ ในประสบการณ์ของฉันไม่ค่อยมีความจำเป็นที่จะต้องรีบูทจริง ๆ
3. ฉันคิดว่ามันเป็นกรณีของการเข้าใจวิธีการทำงานของ Git และสิ่งที่สามารถทำได้ ต้องใช้เวลาสักครู่และมีการสื่อสารที่ดี - ฉันเริ่มเข้าใจสิ่งที่เกิดขึ้นเมื่อฉันเริ่มใช้คอมไพล์กับผู้พัฒนารายอื่นและแม้กระทั่งตอนนี้บางสิ่งที่ฉันไม่แน่ใจ
4. การรวมความขัดแย้งมีประโยชน์ ฉันรู้ว่าฉันรู้ว่าคุณต้องการให้ทุกอย่างทำงาน แต่ความจริงก็คือการเปลี่ยนแปลงรหัสและคุณจำเป็นต้องรวมผลลัพธ์เป็นสิ่งที่ใช้งานได้ การรวมความขัดแย้งในความเป็นจริงเป็นเพียงการเขียนโปรแกรมเพิ่มเติม ฉันไม่เคยพบว่ามีคำอธิบายที่ง่ายสำหรับสิ่งที่ต้องทำเกี่ยวกับพวกเขาดังนั้นนี่คือ: บันทึกไฟล์ที่มีความขัดแย้งผสานไปและเปลี่ยนพวกเขาสิ่งที่พวกเขาควรจะเป็นแล้วgit add .git commit
5. อย่างไรก็ตามมันเหมาะกับ ขณะที่ผมได้กล่าวว่าผู้ใช้แต่ละ git พื้นที่เก็บข้อมูลเป็นของตัวเองที่จะเล่นกับและชื่อสาขาไม่จำเป็นต้องเป็นแบบเดียวกัน ตัวอย่างเช่นหากคุณมีที่เก็บการแสดงละครคุณสามารถบังคับใช้การตั้งชื่อสคีมา แต่คุณไม่จำเป็นต้องใช้สำหรับนักพัฒนาแต่ละรายเฉพาะใน repo release
6. นี่คือขั้นตอนการผสาน คุณรวมเข้ากับสาขาที่วางจำหน่าย ฯลฯ เท่านั้นเมื่อคุณพิจารณาว่าโค้ดจะได้รับการตรวจสอบ / ผ่านการทดสอบคุณภาพ

ฉันหวังว่าจะช่วย ฉันรู้ว่า VonC เพิ่งโพสต์คำอธิบายที่คล้ายกันมาก ... ฉันพิมพ์เร็วพอ!

แก้ไขความคิดเพิ่มเติมเกี่ยวกับวิธีการใช้ git ในเชิงพาณิชย์เนื่องจากดูเหมือนว่าเกี่ยวข้องกับ OP จากความคิดเห็น:

• ที่เก็บข้อมูลรีลีสเราจะเรียกมันว่าproduct.gitสามารถเข้าถึงได้โดยโปรแกรมเมอร์อาวุโส / เจ้าหน้าที่ด้านเทคนิคที่รับผิดชอบดูแลผลิตภัณฑ์ของตัวเอง มีความคล้ายคลึงกับบทบาทของผู้ดูแลใน OSS
• โปรแกรมเมอร์เหล่านี้อาจเป็นส่วนหนึ่งในการพัฒนาเวอร์ชันใหม่ดังนั้นพวกเขาจึงอาจเขียนโค้ดเองและดูแลที่เก็บชุดข้อมูลหลากหลาย พวกเขาอาจจัดการที่เก็บแสดงละครสำหรับคุณลักษณะใหม่จริง ๆ และพวกเขาอาจมีที่เก็บของตนเอง
• ด้านล่างพวกเขาเป็นโปรแกรมเมอร์ที่รับผิดชอบในการพัฒนาแต่ละบิต ตัวอย่างเช่นบางคนอาจรับผิดชอบงาน UI พวกเขาจึงจัดการที่เก็บ UI.git
• ด้านล่างพวกเขาเป็นโปรแกรมเมอร์จริงที่พัฒนาคุณสมบัติเป็นงานประจำวัน

แล้วจะเกิดอะไรขึ้น ทุกคนดึงตอนเริ่มต้นของแต่ละวันจากแหล่ง "อัปสตรีม" เช่นที่เก็บข้อมูลรีลีส (ซึ่งอาจมีเนื้อหาล่าสุดจากการพัฒนาวันก่อนหน้า) ทุกคนทำสิ่งนี้โดยตรง สิ่งนี้จะไปที่สาขาในพื้นที่เก็บข้อมูลของพวกเขาอาจเรียกว่า "ต้นแบบ" หรือบางทีถ้าคุณเป็นฉันว่า "ล่าสุด" โปรแกรมเมอร์จะทำงานบางอย่าง งานนี้อาจเป็นสิ่งที่พวกเขาไม่แน่ใจดังนั้นพวกเขาจึงสร้างสาขาทำผลงาน ถ้ามันไม่ทำงานพวกเขาสามารถลบสาขาและกลับไป ถ้าเป็นเช่นนั้นพวกเขาจะต้องรวมเข้ากับสาขาหลักที่พวกเขากำลังทำงานอยู่ เราจะบอกว่านี่เป็นโปรแกรมเมอร์ UI ที่ทำงานlatest-uiเพื่อให้เขาทำgit checkout latest-uiตามgit merge abc-ui-mywhizzynewfeature. จากนั้นเขาก็บอกหัวหน้าฝ่ายเทคนิคของเขา (ผู้นำ UI) เฮ้ฉันทำภารกิจเสร็จแล้วดึงออกมาจากตัวฉัน ดังนั้นโอกาสในการขาย UI จึงเป็นเช่นgit pull user-repo lastest-ui:lastest-ui-suchafeature-abcนั้น จากนั้นโอกาสในการขายของ UI จะดูที่สาขานั้นและบอกว่าจริง ๆ แล้วมันดีมากฉันจะรวมมันเข้าui-latestด้วยกัน จากนั้นเขาอาจบอกทุกคนที่อยู่เบื้องล่างให้ดึงเขาจากui-latestกิ่งหรือชื่ออะไรก็ตามที่พวกเขาตั้งไว้ หากทีมมีความสุขลีดเดอร์ UI อาจขอให้รอการทดสอบดึงออกจากเขาและรวมการเปลี่ยนแปลง สิ่งนี้แพร่กระจายออกไปสู่ทุกคน (ดาวน์สตรีมของการเปลี่ยนแปลง) ซึ่งทำการทดสอบและส่งรายงานข้อผิดพลาด ฯลฯ ในที่สุดหากคุณลักษณะผ่านการทดสอบ ฯลฯ หนึ่งในโอกาสในการขายด้านเทคนิครายใดรายหนึ่งอาจรวมเข้าไปในสำเนาการทำงานปัจจุบันของโปรแกรม การเปลี่ยนแปลงทั้งหมดจะแพร่กระจายกลับลงมา และอื่น ๆ

มันไม่ใช่วิธีการทำงานแบบ "ดั้งเดิม" และได้รับการออกแบบให้เป็น "ตัวขับเคลื่อนแบบเพียร์" แทนที่จะเป็นแบบ "ลำดับชั้น" เช่น SVN / CVS ในสาระสำคัญทุกคนมีการเข้าถึง แต่เฉพาะในพื้นที่ มันคือการเข้าถึงพื้นที่เก็บข้อมูลและพื้นที่เก็บข้อมูลที่คุณกำหนดเป็น repo ปล่อยที่ช่วยให้คุณใช้ลำดับชั้น

แบบจำลองที่ฉันใช้กับผลลัพธ์ที่ดีมีดังต่อไปนี้:

repo "จำเริญ" ทุกคนผลักดันและดึงไปยัง / จากพื้นทอพอโลยีลูกค้าเซิร์ฟเวอร์

ไม่มีสาขาหลักดังนั้นผู้พัฒนาจึงไม่สามารถส่งรหัสใด ๆ ลงใน "การฉีด"

การพัฒนาทั้งหมดเกิดขึ้นในสาขาหัวข้อ เรากำหนดชื่อเพื่อให้สามารถตรวจสอบได้ง่ายว่าใครเป็นผู้รับผิดชอบ: jn / newFeature หรือ jn / issue-1234

นอกจากนี้ยังมีการแมป 1 ต่อ 1 ใกล้ระหว่างสาขาและการ์ด Kanban / scrum บนไวท์บอร์ด

ในการปล่อยสาขาจะถูกส่งไปยัง repo ที่มีความสุขและย้ายการ์ด Kanban ไปให้พร้อมสำหรับการตรวจสอบ

จากนั้นหากสาขาได้รับการยอมรับจากการตรวจสอบมันเป็นผู้สมัครสำหรับการเปิดตัว

การเปิดตัวเกิดขึ้นเมื่อมีการรวมสาขาที่ยอมรับเข้าด้วยกันและติดแท็กด้วยหมายเลขเวอร์ชัน

ด้วยการผลักดันแท็กใหม่ไปสู่ ​​repo ที่มีความสุขจะมีฐานใหม่ที่เป็นไปได้สำหรับคุณสมบัติใหม่

เพื่อหลีกเลี่ยงการรวมความขัดแย้งนักพัฒนากรุณาขอให้ปรับปรุง (ผสาน) สาขาที่ยังไม่เผยแพร่ไปยังแท็กรุ่นล่าสุด

โดยส่วนตัวแล้วฉันพยายามเก็บเฉพาะรหัสรีลีสในสาขาหลัก

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

ฉันลองและใช้ข้อตกลงการตั้งชื่อสาขาทั่วไปเช่นกัน:

• bugfix / recursive_loop
• bugfix / sql_timeout
• คุณลักษณะ / new_layout
• คุณลักษณะ / enhanced_search