กลยุทธ์สาขา Git สำหรับทีม dev ขนาดเล็ก [ปิด]

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

ใครบ้างมีกลยุทธ์สาขา git ที่ชื่นชอบสำหรับทีมขนาดเล็กซึ่งตรงตามข้อกำหนดต่อไปนี้:

1. ทำงานได้ดีสำหรับทีมนักพัฒนา 2 ถึง 3 คน
2. น้ำหนักเบาและไม่มากเกินไป
3. อนุญาตให้ devs แยกทำงานกับการแก้ไขข้อบกพร่องและคุณสมบัติขนาดใหญ่ได้อย่างง่ายดาย
4. ช่วยให้เราสามารถรักษาสาขาที่มั่นคง (สำหรับช่วงเวลา 'โอ้อึ' เมื่อเราต้องทำให้เซิร์ฟเวอร์ที่ใช้งานจริงของเราทำงาน)

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

คุณอาจได้รับประโยชน์จากเวิร์กโฟลว์สกอตต์ Chacon อธิบายในโปร Git ในเวิร์กโฟลว์นี้คุณมีสองสาขาที่มักจะอยู่ต้นแบบและพัฒนา

ต้นแบบแสดงเวอร์ชันที่มีเสถียรภาพที่สุดของโครงการของคุณและคุณจะปรับใช้กับการผลิตจากสาขานี้เท่านั้น

การพัฒนามีการเปลี่ยนแปลงที่กำลังดำเนินการอยู่และอาจไม่พร้อมสำหรับการผลิต

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

สกอตต์อธิบายถึงกิ่งก้านสาขาเหล่านี้ในระยะยาวว่าเป็น "ไซโล" ของรหัสซึ่งรหัสในสาขาที่มีความมั่นคงน้อยกว่าในที่สุดจะ "จบการศึกษา" ให้กับคนที่ถือว่ามีเสถียรภาพมากขึ้นหลังจากการทดสอบและการอนุมัติทั่วไปจากทีมของคุณ

ทีละขั้นตอนเวิร์กโฟลว์ของคุณภายใต้รูปแบบนี้อาจมีลักษณะเช่นนี้:

1. คุณต้องแก้ไขข้อบกพร่อง
2. สร้างสาขาที่เรียกว่าmyfixที่ยึดตามสาขาที่กำลังพัฒนา
3. ทำงานกับข้อบกพร่องในสาขาหัวข้อนี้จนกว่าจะได้รับการแก้ไข
4. ผสานmyfixเข้าไปพัฒนา ทำการทดสอบ
5. คุณค้นพบความขัดแย้งในการแก้ไขปัญหาของคุณอีกด้วยสาขาหัวข้อhisfixว่าเพื่อนร่วมงานของคุณผสานเข้ากับการพัฒนาขณะที่คุณกำลังดำเนินการแก้ไขปัญหาของคุณ
6. ทำการเปลี่ยนแปลงเพิ่มเติมในสาขาmyfixเพื่อจัดการกับข้อขัดแย้งเหล่านี้
7. รวมmyfixเข้ากับการพัฒนาและเรียกใช้การทดสอบอีกครั้ง
8. ทุกอย่างทำงานได้ดี ผสานการพัฒนาออกเป็นหลัก
9. ปรับใช้กับการผลิตจากต้นแบบได้ตลอดเวลาเพราะคุณรู้ว่ามันเสถียร

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับขั้นตอนการทำงานนี้ให้ดูที่บทการทำงานของการแยกสาขาใน Pro Git

หลังจากเข้ามาเป็นสามเณรพยายามหากลยุทธ์ตรงไปข้างหน้าเพื่อสอนให้ผู้พัฒนารายอื่นที่ไม่เคยใช้การควบคุมแหล่งที่มา นี่คืออันที่พอดีกับhttp://nvie.com/posts/a-successful-git-branching-model/ฉันพยายามใช้ GIT workflow มาตรฐานที่อยู่ใน man pages แต่มันทำให้ฉันสับสนเล็กน้อยและผู้ชมของฉันโดยสมบูรณ์

ในช่วง 6 เดือนที่ผ่านมาฉันต้องแก้ไขข้อขัดแย้งสองครั้งเท่านั้น ฉันได้เพิ่มขั้นตอนในการทดสอบหลังการรวมและ 'ดึงและผสาน "หรือ' pull --rebase" เสมอจำนวนมาก (หนึ่งครั้งในตอนเช้าและตอนบ่าย) ในขณะที่พัฒนาคุณลักษณะ นอกจากนี้เรายังใช้ github.com เป็นศูนย์กลางในการดึงรหัสล่าสุด

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

จาก Scott Chacon of Github:

เราจะทำอย่างไร GitHub Flow คืออะไร?

• ทุกสิ่งในสาขาหลักสามารถนำไปใช้ได้
• หากต้องการทำงานกับสิ่งใหม่ ๆ ให้สร้างกิ่งที่มีคำอธิบายโดยละเอียด (เช่น: new-oauth2-scopes)
• มุ่งมั่นที่สาขานั้นในพื้นที่และผลักดันงานของคุณไปยังสาขาที่มีชื่อเดียวกันบนเซิร์ฟเวอร์เป็นประจำ
• เมื่อคุณต้องการข้อเสนอแนะหรือความช่วยเหลือหรือคุณคิดว่าสาขาพร้อมสำหรับการผสานให้เปิด คำขอดึง
• หลังจากที่คนอื่นได้ตรวจสอบและลงชื่อออกจากคุณสมบัติคุณสามารถรวมมันเป็นหลัก
• เมื่อมีการรวมและผลักดันให้เป็น 'ต้นแบบ' คุณสามารถและควรปรับใช้ทันที

ดูบทความทั้งหมดสำหรับรายละเอียดเพิ่มเติม: http://scottchacon.com/2011/08/31/github-flow.html

โปรดทราบว่า "คำขอการดึง" เป็นสิ่งประดิษฐ์ Github และเป็นสิ่งที่ถูกนำเข้าสู่เว็บไซต์ของพวกเขาไม่ใช่ Git เอง: https://help.github.com/articles/using-pull-requests/

ใช้masterสาขาเป็นสาขาการพัฒนาของคุณและสร้างสาขาย่อยเพื่อดำเนินการแก้ไขข้อบกพร่อง

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

เมื่อเวลาผ่านไปผู้ใช้ของคุณจะพบข้อบกพร่องในv1.0ดังนั้นคุณจะต้องสร้างสาขาจากแท็กนั้น (เช่นตั้งชื่อหลังจากปล่อย1.0) และแก้ไขข้อบกพร่องเหล่านั้นในสาขา เมื่อคุณมีข้อบกพร่องมากพอที่แก้ไขแล้วที่คุณคิดว่ามันรับประกันรุ่นใหม่แล้วติดแท็กเป็นv1.0.1และรวมมันกลับเข้าmasterมา

ในขณะเดียวกันการพัฒนาหน้าต่างใหม่ที่สามารถเกิดขึ้นในสาขาที่จะได้รับการติดแท็กเป็นmasterv1.1

ล้างและทำซ้ำ

นี่เป็นไปตามตรรกะการกำหนดหมายเลขความหมาย

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

ใน VCS การมีเพียงสาขา "ต้นแบบ" จะแสดงข้อ จำกัด อย่างรวดเร็วเนื่องจากคุณไม่สามารถดำเนินการพัฒนาทั้งหมดพร้อมกันในสาขาเดียว
นั่นหมายความว่าคุณต้องรู้ว่าจะต้องแตกสาขาเมื่อใด

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

ในบริบทนี้เริ่มต้นด้วยการระบุความพยายามในการพัฒนาพร้อมกันของคุณและตัดสินใจเกี่ยวกับกระบวนการสิ่งพิมพ์ (push / pull) ตัวอย่างเช่น (และนี่ไม่ใช่วิธีเดียว):

• prod เป็นสาขาสาธารณะแบบอ่านอย่างเดียวที่มีรหัสในการผลิต ทุกคนสามารถดึงจากมันเพื่อ:
  • rebase การพัฒนาในปัจจุบันอยู่ด้านบนของมัน (สำหรับการทดสอบในท้องถิ่นหรือสำหรับการรวมในท้องถิ่น dev repo โปรแกรมแก้ไขด่วนที่ทำใน prod repo ในสาขาแยง)
  • Branch เพื่อทำคุณสมบัติใหม่ (จากรหัสเสถียรที่รู้จัก)
  • สาขาที่จะเริ่มสาขาปล่อยถัดไป (ที่จะอยู่ในการผลิต)
    ไม่มีใครควรผลักดันโดยตรงไปยังแยง (ดังนั้นการอ่านอย่างเดียว)
• ปล่อยเป็นสาขารวมอ่าน - เขียนที่มุ่งมั่นที่เกี่ยวข้องจะเลือกเชอร์รี่ที่จะเป็นส่วนหนึ่งของรุ่นต่อไป
  ทุกคนสามารถกดเพื่อปล่อยเพื่ออัปเดตรุ่นถัดไปได้
  ทุกคนสามารถดึงออกมาจากรุ่นที่กล่าวไว้เพื่ออัปเดตกระบวนการรวมบัญชีในพื้นที่ของเขา / เธอ
• featureX เป็นสาขาอ่าน - เขียนส่วนตัว (ซึ่งไม่จำเป็นต้องผลักดันไปยัง repo ส่วนกลาง) และสามารถผลัก / ดึงระหว่าง repos dev มันหมายถึงความพยายามระยะกลางถึงระยะยาวแตกต่างจากการพัฒนารายวัน
• master แสดงถึง dev ปัจจุบันและถูกผลัก / ดึงระหว่าง dev repos

กระบวนการบริหารจัดการการเปิดตัวอื่น ๆ ที่มีอยู่เช่นนี้เป็นปัญหาเพื่อพิสูจน์

อ่านผ่าน Git Workflow ของ ReinH สำหรับทีม Agile ที่นี่: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

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

หมายเหตุ: กลยุทธ์นี้ไม่ค่อยคอมไพล์โดยเฉพาะ แต่คอมไพล์ทำให้การใช้กลยุทธ์นี้เป็นเรื่องง่าย