เมื่อทำงานกับระบบ SCM คุณควรแยกสาขาเมื่อใด
เมื่อทำงานกับระบบ SCM คุณควรแยกสาขาเมื่อใด
คำตอบ:
มีประโยชน์หลายประการในการแตกแขนง การใช้งานทั่วไปอย่างหนึ่งคือการแยกโปรเจ็กต์ที่เคยมีฐานรหัสร่วมกัน สิ่งนี้มีประโยชน์มากในการทดสอบกับโค้ดของคุณโดยไม่ส่งผลกระทบต่อลำต้นหลัก
โดยทั่วไปคุณจะเห็นสาขาสองประเภท:
สาขาคุณลักษณะ: หากคุณลักษณะบางอย่างรบกวนมากพอที่คุณไม่ต้องการให้ทีมพัฒนาทั้งหมดได้รับผลกระทบในช่วงแรกคุณสามารถสร้างสาขาที่จะทำงานนี้ได้
สาขาการแก้ไข: ในขณะที่การพัฒนาดำเนินต่อไปบนลำตัวหลักสามารถสร้างสาขาการแก้ไขเพื่อเก็บการแก้ไขของซอฟต์แวร์เวอร์ชันล่าสุด
คุณอาจสนใจที่จะอ่านบทความต่อไปนี้ซึ่งอธิบายหลักการของการแตกแขนงและเมื่อใดควรใช้:
ในระยะทั่วไปวัตถุประสงค์หลักของการแยกทาง (ก VCS - รุ่นระบบควบคุม - คุณลักษณะ) เป็นเพื่อให้ได้รหัสแยก
คุณมีสาขาอย่างน้อยหนึ่งสาขาซึ่งเพียงพอสำหรับการพัฒนาตามลำดับและใช้สำหรับงานจำนวนมากที่กำลังบันทึก (มุ่งมั่น) ในสาขาที่ไม่ซ้ำกันนั้น
แต่โมเดลนั้นแสดงขีด จำกัด อย่างรวดเร็ว:
เมื่อคุณมีความพยายามในการพัฒนา (refactoring, evolution, bug-fixes, ... ) และคุณตระหนักดีว่าคุณไม่สามารถทำการเปลี่ยนแปลงในสาขาเดียวกันได้อย่างปลอดภัยกว่าสาขาการพัฒนาปัจจุบันของคุณ (เพราะคุณจะทำลาย API หรือแนะนำโค้ดที่จะทำลาย ทุกอย่าง) จากนั้นคุณต้องมีสาขาอื่น
(เพื่อแยกรหัสใหม่สำหรับรหัสเดิมแม้ว่าชุดรหัสทั้งสองชุดจะถูกรวมในภายหลัง)
นั่นคือคำตอบของคุณตรงนี้:
คุณควรแยกสาขาเมื่อใดก็ตามที่คุณไม่สามารถติดตามและบันทึกความพยายามในการพัฒนาสองครั้งในสาขาเดียว
(โดยไม่ต้องมีประวัติที่ซับซ้อนอย่างน่ากลัวในการรักษา)
สาขาจะมีประโยชน์แม้ว่าคุณจะเป็นคนเดียวที่ทำงานกับซอร์สโค้ด แต่ถ้าคุณมีหลายคน
แต่คุณไม่ควรสร้าง "หนึ่งสาขาต่อผู้พัฒนา":
จุดประสงค์ "แยก" นั้นทำขึ้นเพื่อแยกความพยายามในการพัฒนา (งานที่อาจกล่าวได้ทั่วไปว่า "มาพัฒนาซอฟต์แวร์เวอร์ชันถัดไปของเรากันเถอะ" หรือเจาะจงเป็น "มาแก้ไขกันเถอะ ข้อผิดพลาด 23" )
ไม่ได้ที่จะแยกเป็น 'ทรัพยากร'
(สาขาที่เรียกว่า "VonC" ไม่มีความหมายสำหรับนักพัฒนารายอื่น: จะเกิดอะไรขึ้นถ้า "VonC" ออกจากโครงการคุณจะทำอย่างไรกับ
สาขานี้สาขาที่เรียกว่า "bugfix_212" สามารถตีความได้ในบริบทของระบบติดตามข้อบกพร่องเช่น และนักพัฒนาทุกคนสามารถใช้มันได้อย่างน้อยก็มีความคิดเกี่ยวกับสิ่งที่เขาควรจะทำกับมัน)
สาขาไม่ใช่แท็ก (SVN เป็นระบบการแก้ไขซึ่งพยายามเสนอคุณลักษณะการกำหนดเวอร์ชันเช่นการแยกสาขาและการแท็กผ่านไดเรกทอรีที่มีสำเนาไฟล์ราคาถูกซึ่งไม่ได้หมายความว่าแท็กเป็นสาขา)
ในการกำหนดสาขาหมายถึงการกำหนดเวิร์กโฟลว์การผสาน : คุณจำเป็นต้องรู้ว่าจะผสานสาขาของคุณที่ใดเมื่อคุณทำเสร็จแล้ว
ด้วยเหตุนี้บทที่ 7 ของ Practical Perforce (Laura WINGERD - O'Reilly) จึงเป็นบทนำที่ดี (VCS ไม่เชื่อเรื่องพระเจ้า) เพื่อผสานเวิร์กโฟลว์ระหว่างสาขาประเภทต่างๆ: "" ซอฟต์แวร์วิวัฒนาการอย่างไร "(pdf)
กำหนดคำว่าcodeline (สาขาที่บันทึกขั้นตอนการวิวัฒนาการที่สำคัญของรหัสไม่ว่าจะผ่านแท็กในบางจุดหรือผ่านการผสานที่สำคัญกลับไปที่สาขา)
แนะนำโมเดลเมนไลน์ (โคไลน์กลางเพื่อบันทึกการเผยแพร่) และอธิบายวัตถุประสงค์ต่างๆสำหรับการแตกแขนง:
แนวคิดที่น่าสนใจอื่น ๆ เกี่ยวกับ VCS: แนวคิดพื้นฐาน
(เกี่ยวกับ ClearCase เดิม แต่ยังใช้ได้กับ VCS ใด ๆ )
SCM ในศตวรรษที่ 21 ทั้งหมดกำลังบอกคุณ:
สาขาสำหรับทุกงานที่คุณต้องทำไม่ว่าจะเป็นฟีเจอร์ใหม่การแก้ไขข้อบกพร่องการทดสอบอะไรก็ตาม เรียกว่าสาขาหัวข้อและเปลี่ยนวิธีการทำงานกับ SCM ของคุณ
คุณได้รับ:
เครื่องมือที่สามารถทำได้:
เครื่องมือที่ไม่สามารถทำได้:
นอกจากนี้ยังขึ้นอยู่กับเครื่องมือ SCM ที่คุณใช้ SCM สมัยใหม่ (คอมไพล์เมอร์คิวเรียล ฯลฯ ) ช่วยให้สร้างและทำลายกิ่งก้านได้ง่ายขึ้นทุกเมื่อที่ต้องการ ตัวอย่างเช่นคุณสามารถสร้างหนึ่งสาขาต่อหนึ่งจุดบกพร่องที่คุณกำลังดำเนินการอยู่ เมื่อคุณรวมผลลัพธ์ลงในลำต้นแล้วคุณจะทิ้งกิ่งก้านนั้น
SCM อื่น ๆ เช่นการโค่นล้มและ CVS มีกระบวนทัศน์ที่แตกแขนง "หนักกว่า" มาก นั่นหมายความว่าสาขาจะถือว่าเหมาะสมสำหรับสิ่งที่ใหญ่กว่าแพทช์ยี่สิบบางอย่างเท่านั้น มีการใช้สาขาแบบคลาสสิกเพื่อติดตามแทร็กการพัฒนาทั้งหมดเช่นเวอร์ชันผลิตภัณฑ์ก่อนหน้าหรือในอนาคต
เมื่อคุณต้องการทำการเปลี่ยนแปลงที่สำคัญและ / หรือทดลองกับ codebase ของคุณโดยเฉพาะอย่างยิ่งหากคุณต้องการทำการเปลี่ยนแปลงระดับกลางโดยไม่ส่งผลกระทบต่อ trunk
ขึ้นอยู่กับประเภทของ SCM ที่คุณใช้
ในเวอร์ชันใหม่ที่มีการแจกจ่าย (เช่น git และ mercurial) คุณกำลังสร้างสาขาตลอดเวลาและสร้างใหม่อยู่แล้ว ฉันมักจะทำงานในสาขาที่แยกจากกันสักพักเพียงเพราะมีใครบางคนทำงานสร้างบนเมนไลน์ไม่ได้หรือเพราะเครือข่ายล่มแล้วรวมการเปลี่ยนแปลงกลับเข้าไปในภายหลังเมื่อได้รับการแก้ไขแล้วและมันก็ง่ายมากที่จะทำโดยที่มันไม่น่ารำคาญเลย .
เอกสาร (สั้นและสามารถอ่านได้) ว่าส่วนใหญ่ช่วยให้ฉันเข้าใจสิ่งที่เกิดขึ้นในระบบการกระจายคือทำความเข้าใจ
ในระบบรุ่นเก่าที่มีที่เก็บส่วนกลาง (เช่น CVS, SVN และ ClearCase) มันเป็นปัญหาที่ร้ายแรงกว่ามากซึ่งจำเป็นต้องได้รับการตัดสินใจในระดับทีมและคำตอบควรเป็นเช่น 'เพื่อรักษารุ่นเก่าในขณะที่อนุญาต การพัฒนาเพื่อดำเนินการต่อในบรรทัดหลัก 'หรือ' เป็นส่วนหนึ่งของการทดลองที่สำคัญ '
ฉันคิดว่าโมเดลแบบกระจายนั้นดีกว่ามากและขาดเพียงเครื่องมือกราฟิกที่ดีเท่านั้นที่จะกลายเป็นกระบวนทัศน์ที่โดดเด่น อย่างไรก็ตามยังไม่เป็นที่เข้าใจกันอย่างแพร่หลายและแนวคิดก็แตกต่างกันดังนั้นจึงอาจทำให้ผู้ใช้ใหม่สับสนได้
ฉันพบว่าคำแนะนำจาก Laura Wingerd & Christopher Seiwald ที่ Perforce นั้นกระชับและมีประโยชน์จริงๆ:
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
โปรดดูที่http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdfสำหรับคำอธิบายโดยละเอียดของแต่ละข้อและแนวทางปฏิบัติที่ดีที่สุดอื่น ๆ
มีวัตถุประสงค์หลายประการในการแตกแขนง:
ความจำเป็นในการแยกสาขาอาจเกิดขึ้น:
เมื่อใดก็ตามที่คุณรู้สึกชอบ
คุณอาจจะไม่บ่อยนักหากคุณทำงานกับ SCM แบบรวมศูนย์เนื่องจากสาขาเป็นส่วนหนึ่งของที่เก็บอย่างเป็นทางการและนั่นไม่ได้เชิญชวนให้มีการทดลองมากนัก แต่ไม่ต้องพูดถึงการผสานนั้นเจ็บมาก
OTOH ไม่มีความแตกต่างทางเทคนิคระหว่างสาขาและการชำระเงินใน SCM แบบกระจายและการรวมจะง่ายกว่ามาก คุณจะรู้สึกเหมือนแตกแขนงบ่อยขึ้น
เมื่อคุณต้องการทำการเปลี่ยนแปลงโดยอิงตามสาขาปัจจุบันของคุณไม่ได้กำหนดไว้สำหรับรุ่นถัดไปจากสาขานั้น (ไม่ใช่ก่อนหน้านี้)
ตัวอย่างเช่นเรามักจะทำงานบนลำต้น ในช่วงเวลาของการเปิดตัวบางคนจะต้องทำการเปลี่ยนแปลงที่เราไม่ต้องการในรุ่นปัจจุบัน (อาจเป็นก่อนการเผยแพร่ในขณะนี้โดยปกติจะเป็นหลังจากการเผยแพร่) นี่คือตอนที่เราแตกกิ่งก้านเพื่อวางการปลดปล่อยบนกิ่งก้านของมันเองและพัฒนาต่อไปสำหรับการเปิดตัวครั้งต่อไปบนลำต้น
ทิ้งเทคนิคกันไปเลย .....
สาขาเมื่อคุณรู้ว่าการรวมกลับง่ายขึ้น!
โปรดทราบว่าการรวมจะมีผลกับวิธีดำเนินงานในโครงการเสมอ
เมื่อสิ่งนี้ประสบความสำเร็จปัญหาในระดับอุดมศึกษาอื่น ๆ ทั้งหมดจะเข้ามาเล่น