อะไรคือแนวทางปฏิบัติที่ดีที่สุดและกฎที่ควรปฏิบัติในขณะที่รักษาโค้ด เป็นแนวทางปฏิบัติที่ดีที่จะมีเฉพาะรหัสที่พร้อมใช้งานจริงในสาขาการพัฒนาหรือควรมีรหัสล่าสุดที่ยังไม่ทดสอบในสาขาการพัฒนา
พวกคุณรักษารหัสการพัฒนาและรหัสการผลิตของคุณอย่างไร?
แก้ไข - คำถามเสริม - ทีมพัฒนาของคุณปฏิบัติตาม "กระทำเร็วที่สุดเท่าที่จะเป็นไปได้และบ่อยครั้งแม้ว่าโค้ดจะมี - ข้อบกพร่องเล็กน้อยหรือไม่สมบูรณ์" โปรโตคอลหรือ "กระทำ - ONLY-perfect-code "โปรโตคอลในขณะที่ส่งรหัสไปยังสาขา DEVELOPMENT?
คำตอบ:
อัปเดต 2019:
ทุกวันนี้คำถามจะเห็นได้จากบริบทโดยใช้ Git และ 10 ปีของการใช้เวิร์กโฟลว์การพัฒนาแบบกระจาย (ทำงานร่วมกันผ่าน GitHubเป็นหลัก) แสดงแนวทางปฏิบัติที่ดีที่สุดทั่วไป:
masterเป็นสาขาพร้อมที่จะนำไปใช้ในการผลิตในเวลาใด ๆ : masterรุ่นถัดไปกับชุดที่เลือกของสาขาคุณลักษณะรวมอยู่ในdev(หรือสาขาการรวมหรือ ' next') คือสาขาที่มีการทดสอบสาขาคุณลักษณะที่เลือกสำหรับรุ่นถัดไปร่วมกันmaintenance(หรือhot-fix) branch เป็นสาขาสำหรับวิวัฒนาการของรุ่นปัจจุบัน / การแก้ไขข้อบกพร่องโดยมีการผสานกลับไปที่devและหรือmasterชนิดของเวิร์กโฟลว์ที่ (ที่คุณไม่ได้รวมdevไปmasterแต่ที่คุณผสานเฉพาะสาขาคุณลักษณะdevแล้วถ้าเลือกที่จะmasterในการสั่งซื้อเพื่อให้สามารถลดลงได้อย่างง่ายดายมีสาขาไม่พร้อมสำหรับการเปิดตัวถัดไป) จะดำเนินการใน Git repo ตัวเองด้วยgitworkflow (คำเดียวภาพประกอบที่นี่ )
ดูเพิ่มเติมได้ที่rocketraman/gitworkflow. ประวัติความเป็นมาของการทำเช่นนี้ VS Trunk-based พัฒนาเป็นข้อสังเกตในการแสดงความคิดเห็นและการอภิปรายของบทความนี้โดยอดัม Dymitruk
(ที่มา: Gitworkflow: ไพรเมอร์เชิงงาน )
หมายเหตุ: ในเวิร์กโฟลว์แบบกระจายนั้นคุณสามารถคอมมิตเมื่อใดก็ได้ที่คุณต้องการและส่งไปยังสาขาส่วนบุคคล WIP (งานระหว่างดำเนินการ) โดยไม่มีปัญหา: คุณจะสามารถจัดระเบียบ (git rebase) คอมมิตของคุณใหม่ก่อนที่จะทำให้เป็นส่วนหนึ่งของสาขาฟีเจอร์
คำตอบเดิม (ต.ค. 2551 10+ ปีที่แล้ว)
ทุกอย่างขึ้นอยู่กับลักษณะตามลำดับของการจัดการรุ่นของคุณ
อย่างแรกทุกอย่างในหีบของคุณมีไว้สำหรับรุ่นต่อไปหรือไม่? คุณอาจพบว่าฟังก์ชันบางอย่างที่พัฒนาในปัจจุบัน ได้แก่ :
ในกรณีนี้ trunk ควรมีความพยายามในการพัฒนาในปัจจุบัน แต่สาขาการเผยแพร่ที่กำหนดไว้ก่อนหน้ารุ่นถัดไปสามารถทำหน้าที่เป็นสาขาการรวมซึ่งจะรวมเฉพาะรหัสที่เหมาะสม (ตรวจสอบความถูกต้องสำหรับรุ่นถัดไป) จากนั้นแก้ไขในช่วง homologation และในที่สุดก็ถูกแช่แข็งเมื่อเข้าสู่กระบวนการผลิต
เมื่อพูดถึงรหัสการผลิตคุณต้องจัดการสาขาแพตช์ของคุณด้วยในขณะที่โปรดทราบว่า:
เมื่อพูดถึงสาขา dev คุณสามารถมีลำต้นเดียวได้เว้นแต่คุณจะมีความพยายามในการพัฒนาอื่น ๆ ที่คุณต้องทำควบคู่กันเช่น:
ตอนนี้หากวงจรการพัฒนาของคุณเป็นลำดับมากคุณสามารถทำตามคำตอบอื่น ๆ ที่แนะนำ: ลำต้นเดียวและหลายสาขาที่ปล่อยออกมา ใช้งานได้กับโครงการขนาดเล็กที่การพัฒนาทั้งหมดมั่นใจว่าจะเข้าสู่รุ่นถัดไปและสามารถถูกตรึงและใช้เป็นจุดเริ่มต้นสำหรับสาขาการเผยแพร่ซึ่งสามารถเกิดแพทช์ได้ นั่นคือกระบวนการเล็กน้อย แต่ทันทีที่คุณมีโครงการที่ซับซ้อนมากขึ้น ... มันก็ไม่เพียงพออีกต่อไป
เพื่อตอบความคิดเห็นของ Ville M. :
master(การผลิต) และdev(การรวม) ไม่แตกต่างกัน? โดยเฉพาะกับการแก้ร้อน? คุณรวมmasterกลับเข้าไปเป็นประจำdevเช่นหลังจากปล่อยหรือไม่?
เราใช้:
จนกว่าโปรเจ็กต์ใกล้จะเสร็จสมบูรณ์หรือเรากำลังสร้างเวอร์ชันหลัก (เช่นการสาธิตผลิตภัณฑ์เวอร์ชันการนำเสนอ) จากนั้นเรา (ประจำ) แยกสาขาการพัฒนาปัจจุบันของเราออกเป็น:
ไม่มีฟีเจอร์ใหม่เข้าสู่สาขาการเปิดตัว เฉพาะจุดบกพร่องที่สำคัญเท่านั้นที่ได้รับการแก้ไขในสาขาการเผยแพร่และรหัสสำหรับแก้ไขข้อบกพร่องเหล่านี้จะรวมเข้ากับสาขาการพัฒนาอีกครั้ง
กระบวนการสองส่วนที่มีการพัฒนาและสาขา (การเปิดตัว) ที่มั่นคงทำให้ชีวิตง่ายขึ้นมากสำหรับเราและฉันไม่เชื่อว่าเราจะปรับปรุงส่วนใดส่วนหนึ่งได้โดยการแนะนำสาขาเพิ่มเติม แต่ละสาขายังมีกระบวนการสร้างของตัวเองซึ่งหมายความว่าทุกๆสองสามนาทีจะมีการสร้างกระบวนการสร้างใหม่ดังนั้นหลังจากการเช็คอินโค้ดเราจะมีไฟล์ปฏิบัติการใหม่สำหรับเวอร์ชันบิวด์และสาขาทั้งหมดภายในประมาณครึ่งชั่วโมง
ในบางครั้งเรายังมีสาขาสำหรับนักพัฒนารายเดียวที่ทำงานเกี่ยวกับเทคโนโลยีใหม่และยังไม่ได้รับการพิสูจน์หรือสร้างหลักฐานแนวคิด แต่โดยทั่วไปแล้วจะทำได้ก็ต่อเมื่อการเปลี่ยนแปลงมีผลต่อหลายส่วนของ codebase สิ่งนี้เกิดขึ้นโดยเฉลี่ยทุก ๆ 3-4 เดือนและโดยปกติสาขาดังกล่าวจะรวมเข้าใหม่ (หรือทิ้ง) ภายในหนึ่งหรือสองเดือน
โดยทั่วไปฉันไม่ชอบความคิดของนักพัฒนาทุกคนที่ทำงานในสาขาของตัวเองเพราะคุณ "ข้ามไปและย้ายไปที่นรกการรวม" โดยตรง ฉันขอแนะนำให้ต่อต้านมัน หากคุณมีโค้ดเบสทั่วไปคุณควรทำงานร่วมกันทั้งหมด สิ่งนี้ทำให้นักพัฒนามีความระมัดระวังมากขึ้นเกี่ยวกับการเช็คอินของตนและจากประสบการณ์ของ coder ทุกคนรู้ว่าการเปลี่ยนแปลงใดที่อาจทำลายโครงสร้างและการทดสอบจึงเข้มงวดมากขึ้นในกรณีเช่นนี้
คำถามในการเช็คอินก่อนกำหนด:
หากคุณต้องการเช็คอินPERFECT CODEเท่านั้นจริงๆแล้วไม่ควรเช็คอินอะไรเลยไม่มีรหัสใดที่สมบูรณ์แบบและเพื่อให้ QA ตรวจสอบและทดสอบรหัสนั้นจำเป็นต้องอยู่ในสาขาการพัฒนาจึงจะสามารถสร้างไฟล์ปฏิบัติการใหม่ได้
สำหรับเรานั่นหมายความว่าเมื่อคุณสมบัติเสร็จสมบูรณ์และทดสอบโดยนักพัฒนาแล้วจะมีการเช็คอินมันอาจถูกตรวจสอบได้หากมีข้อบกพร่องที่ทราบ (ไม่ร้ายแรง) แต่ในกรณีนี้ผู้ที่จะได้รับผลกระทบจากข้อบกพร่องคือ มักจะแจ้ง นอกจากนี้ยังสามารถตรวจสอบโค้ดที่ไม่สมบูรณ์และอยู่ระหว่างดำเนินการได้ แต่จะต้องไม่ก่อให้เกิดผลกระทบเชิงลบที่ชัดเจนเช่นข้อขัดข้องหรือฟังก์ชันการทำงานที่มีอยู่เสียหาย
ทุก ๆ ครั้งการตรวจสอบโค้ดและข้อมูลรวมที่หลีกเลี่ยงไม่ได้จะทำให้โปรแกรมไม่สามารถใช้งานได้จนกว่าจะสร้างรหัสใหม่ อย่างน้อยที่สุดที่เราทำคือเพิ่มคำว่า "WAIT FOR BUILD" ในความคิดเห็นในการเช็คอินและ / หรือส่งอีเมล
เพื่อสิ่งที่คุ้มค่านี่คือวิธีที่เราทำ
การพัฒนาส่วนใหญ่ดำเนินการในลำต้นแม้ว่าลักษณะการทดลองหรือสิ่งที่อาจทำลายระบบอย่างมีนัยสำคัญมักจะได้รับสาขาของตัวเอง สิ่งนี้ใช้งานได้ดีเพราะหมายความว่านักพัฒนาทุกคนจะมีเวอร์ชันล่าสุดของทุกอย่างในสำเนาการทำงานของตนเสมอ
หมายความว่าสิ่งสำคัญคือต้องรักษาลำตัวให้ทำงานอย่างคลุมเครือเนื่องจากเป็นไปได้อย่างสมบูรณ์ที่จะทำลายมันอย่างสมบูรณ์ ในทางปฏิบัตินั้นไม่ได้เกิดขึ้นบ่อยนักและไม่ค่อยเป็นปัญหาสำคัญ
สำหรับรุ่นที่ใช้งานจริงเราแตกกิ่งก้านสาขาหยุดเพิ่มคุณสมบัติใหม่และดำเนินการแก้ไขข้อบกพร่องและทดสอบสาขา (รวมกลับเข้าสู่ลำต้นเป็นประจำ) จนกว่าจะพร้อมสำหรับการเผยแพร่ เมื่อถึงจุดนั้นเราจะทำการผสานขั้นสุดท้ายเป็น trunk เพื่อให้แน่ใจว่าทุกอย่างอยู่ในนั้นแล้วจึงปล่อย
จากนั้นสามารถทำการบำรุงรักษาในสาขาการวางจำหน่ายได้ตามความจำเป็นและการแก้ไขเหล่านั้นสามารถรวมกลับเข้าไปในลำตัวได้อย่างง่ายดาย
ฉันไม่ได้อ้างว่านี่เป็นระบบที่สมบูรณ์แบบ (และมันยังมีช่องโหว่อยู่ - ฉันไม่คิดว่าการจัดการรุ่นของเราเป็นกระบวนการที่รัดกุมเพียงพอ) แต่มันก็ใช้ได้ดีพอ
ทำไมยังไม่มีใครพูดถึงเรื่องนี้? ที่ประสบความสำเร็จ Git รูปแบบแตกแขนง
มันเป็นโมเดลการแตกแขนงที่ดีที่สุดสำหรับฉัน!
หากโปรเจ็กต์ของคุณมีขนาดเล็กอย่าใช้ทุกสาขาตลอดเวลา (บางทีคุณอาจข้ามสาขาฟีเจอร์สำหรับฟีเจอร์ขนาดเล็ก) แต่อย่างอื่นมันเป็นวิธีที่จะทำ!
รหัสการพัฒนาบนสาขารหัสสดที่ติดแท็กบน Trunk
ไม่จำเป็นต้องมีกฎ "คอมมิตเฉพาะโค้ดที่สมบูรณ์แบบ" สิ่งใดก็ตามที่นักพัฒนาพลาดควรได้รับจากสี่ตำแหน่ง ได้แก่ การตรวจสอบโค้ดการทดสอบสาขาการทดสอบการถดถอยการทดสอบ QA ขั้นสุดท้าย
นี่คือคำอธิบายโดยละเอียดเพิ่มเติมทีละขั้นตอน:
dev ไปใน trunk (สไตล์ svn) และรีลีส (รหัสการผลิต) รับสาขาของตัวเอง
มันคือ "Branch-by purpose model" (รูปที่ 3 ในThe important of branching models /! \ pdf)
เราแก้ปัญหานี้โดยแยกรหัสการผลิต (ลำตัวหลัก) ออกจากรหัสการพัฒนาโดยสิ้นเชิง (โดยที่นักพัฒนาทุกคนมีสาขาของตัวเอง)
ไม่อนุญาตให้ใช้รหัสในรหัสการผลิตก่อนที่จะได้รับการตรวจสอบอย่างละเอียด (โดย QA และผู้ตรวจสอบโค้ด)
วิธีนี้จะไม่มีความสับสนเกี่ยวกับรหัสที่ใช้งานได้มันเป็นสาขาหลักเสมอ
โอ้ใช่ - อีกอย่างหนึ่ง - เราเก็บโค้ดที่ไม่ใช่การผลิตไว้ (นั่นคือรหัสที่จะไม่ถูกนำออกใช้ - เช่นสคริปต์เครื่องมือการทดสอบยูทิลิตี้) ใน CV HEAD โดยปกติจะต้องมีการทำเครื่องหมายอย่างชัดเจนเพื่อให้ไม่มีใคร "เผลอ" เผยแพร่
เราพัฒนาบนลำต้นโดยจะแยกแขนงทุกๆสองสัปดาห์และนำไปผลิต เฉพาะจุดบกพร่องที่สำคัญเท่านั้นที่ได้รับการแก้ไขในสาขาส่วนที่เหลือสามารถรอได้อีกสองสัปดาห์
กฎข้อเดียวคือการกระทำไม่ควรทำลายสิ่งใด ในการจัดการ wip-code และรหัสที่ยังไม่ทดสอบเราเพียงแค่เพิ่มความเหมาะสมหาก statments เพื่อให้ง่ายต่อการสลับเปิดและปิด
โดยทั่วไปแล้วมันเป็นไปได้ที่จะแตกกิ่งก้านเมื่อใดก็ได้และนำไปผลิต
ฉันใช้ git และฉันมี 2 สาขา: masterและmaint
เมื่อฉันปล่อยรหัสไปยังเวอร์ชันที่ใช้งานจริงฉันแท็กและฉันรวมmasterกับmaint branch ฉันมักจะปรับใช้จากmaintสาขา แพตช์จากสาขาการพัฒนาฉันเลือกพวกมันไปยังสาขาหลักและปรับใช้แพตช์
เรามีสาขา "รุ่น" ซึ่งมีสิ่งที่กำลังผลิตอยู่หรือจะนำไปใช้งานในไม่ช้า (ผ่าน QA ส่วนใหญ่แล้ว)
แต่ละโครงการหรือในบางกรณีหน่วยงานอื่น ๆ จะมีสาขาของตัวเองซึ่งแตกแขนงมาจากการเปิดตัว
การเปลี่ยนแปลงจะได้รับความมุ่งมั่นโดยนักพัฒนาในโครงการในสาขาของโครงการ การเผยแพร่จะรวมกลับเข้าสู่สาขาการพัฒนาเป็นระยะ ๆ
เมื่อแพคเกจงานในสาขาเป็น QA'd ทั้งหมด (การทดสอบหน่วยการทดสอบระบบการตรวจสอบโค้ดการตรวจสอบคุณภาพ ฯลฯ ) สาขาจะรวมเข้ากับสาขาการเผยแพร่ โครงสร้างใหม่สร้างขึ้นจากสาขาการเผยแพร่และการตรวจสอบขั้นสุดท้ายจะเกิดขึ้นกับเวอร์ชันนั้น
โดยทั่วไปกระบวนการนี้ใช้ได้จนกว่าจะพบปัญหาหลังจากการผสานเสร็จสิ้น หาก WP "ค้าง" หลังจากที่รวมเข้าด้วยกันมันจะเก็บทุกอย่างไว้หลังจากนั้นจนกว่าจะได้รับการแก้ไข (เราไม่สามารถปล่อยอีกครั้งได้จนกว่าจะปล่อยที่ติดอยู่)
นอกจากนี้ยังค่อนข้างยืดหยุ่น - การเปลี่ยนแปลงเล็กน้อยอาจเกิดขึ้นได้โดยตรงในสาขาการเผยแพร่หากมีการเผยแพร่ในช่วงเวลาสั้น ๆ (เช่น 1-2 วันหรือมากกว่านั้น)
หากมีการเปลี่ยนแปลงในการผลิตโดยตรงด้วยเหตุผลบางประการ (ปัญหาสำคัญที่ส่งผลกระทบต่อลูกค้าในการผลิตซึ่งจำเป็นต้องมีการเปลี่ยนแปลงรหัสทันทีเพื่อแก้ไข) การเปลี่ยนแปลงเหล่านั้นจะถูกนำกลับไปที่ BRANCH_RELEASE แทบจะไม่เคยเกิดขึ้นเลย
ขึ้นอยู่กับโครงการ รหัสเว็บของเราได้รับการตรวจสอบอย่างสม่ำเสมอในขณะที่รหัสแอปพลิเคชันของเราจะตรวจสอบได้ก็ต่อเมื่อมีการคอมไพล์ ฉันสังเกตว่ามันค่อนข้างคล้ายกับการที่เราปล่อยของ เนื้อหาบนเว็บเพิ่มขึ้นทุกเมื่อที่ทำได้ในขณะที่แอปพลิเคชันถึงกำหนดส่งอย่างหนัก ฉันไม่เห็นการสูญเสียคุณภาพในทั้งสองวิธี