การควบคุมเวอร์ชันด้วยการพัฒนาเกม - ฉันควรจะแตกสาขาเมื่อใด

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

ในขณะที่ฉันค้นพบคุณสมบัติและข้อดีของการใช้การควบคุมเวอร์ชันอย่างช้าๆฉันก็ติดแนวคิดเรื่องการแตกแขนง ฉันควรทำเมื่อใด

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

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

ขณะที่ฉันอ่านหนังสือการเข้ารหัสเกมโดย Mike McShaffry (ซึ่งเป็นหนังสือที่ยอดเยี่ยม) ฉันหลงทางโดยสิ้นเชิงเมื่อผู้เขียนแนะนำให้เก็บสามกิ่งซึ่งเป็นไปตาม:

• หลัก : สาขาการพัฒนาหลักที่มีการเปลี่ยนแปลงเป็นประจำ
• ทองคำ : สาขาทองคำที่มีการเก็บบันทึกเหตุการณ์สำคัญครั้งสุดท้าย
• การวิจัย : สาขาสำหรับการทดสอบสิ่งต่าง ๆ ที่อาจส่งผลกระทบอย่างรุนแรงต่อสาขาหลัก (การปรับเปลี่ยนส่วนประกอบที่สำคัญของเอ็นจิ้นเกม ฯลฯ )

นั่นเป็นวิธีที่ควรจะเป็นหรือไม่? มันทำงานอย่างไรในโลกแห่งการพัฒนาเกมกับทีมนักพัฒนาขนาดใหญ่?

โดยทั่วไป: เมื่อใดที่มักจะแยกสาขา (และรวม) ในการพัฒนาเกม

การแตกแขนงขึ้นอยู่กับการรองรับ VCS เล็กน้อยสำหรับคุณสมบัติ (เช่น: VCS ทำให้ง่ายหรือยาก)

แต่อย่างน้อยที่สุดคุณต้องการสาขาสำหรับแต่ละโครงการที่ได้รับการสนับสนุนโดยอิสระ นั่นคือถ้าคุณมี "Game 2" และ "Game 2 + Expansion" ซึ่งเป็นผลิตภัณฑ์แยกต่างหากที่สร้างขึ้นจาก codebase เดียวกันและคุณต้องสามารถแก้ไขและอัปเดตได้คุณต้องมีสิ่งเหล่านี้ มีอยู่ในสาขาของตัวเองออกจากรหัสฐานหลักเพื่อให้การแก้ไขฐานรหัสหลักสามารถผสานเข้ากับแต่ละผลิตภัณฑ์เหล่านี้ได้อย่างอิสระ (โดยทั่วไปแล้วสาขาเหล่านี้จะถูกสร้างขึ้นเมื่อมีการเปิดตัวผลิตภัณฑ์แต่ละตัวหรืออาจจะเป็นสองสามวัน / สัปดาห์ก่อนหน้าถ้าคุณมีคนกำลังทำงานกับสิ่งต่าง ๆ ใน codebase ซึ่งคุณไม่ต้องการออกไปกับรุ่นแรก)

เมื่อทำงานกับ VCS ซึ่งใช้สาขาที่ยุ่งยากหรือเจ็บปวด (SourceSafe, svn, ฯลฯ ) คุณอาจจะมีความสุขที่สุดในการรักษาสาขา "ปล่อย" สำหรับผลิตภัณฑ์ที่วางจำหน่ายแต่ละครั้งและทำการพัฒนาหลักใน "ลำต้น" การรวมการเปลี่ยนแปลงจาก "trunk" ไปยังสาขา "release" หากคุณต้องการเผยแพร่โปรแกรมแก้ไขด่วนสำหรับรุ่นเหล่านั้นและเมื่อใด

หากในอีกทางหนึ่งคุณกำลังทำงานกับหนึ่งในระบบ VCS ที่ใหม่กว่าซึ่งสร้างขึ้นจากการรวมสาขาและการรวมกัน (git, Bazaar, Mercurial ฯลฯ ) คุณอาจจะมีความสุขที่สุดในการพัฒนาระยะสั้น - "ฟีเจอร์" กิ่งก้านสด ตัวอย่างเช่นหากคุณกำลังทำงานกับ AI pathfinding คุณสามารถสร้างสาขา "pathfinding" และใช้รหัสในนั้น เมื่อคุณทำเสร็จแล้วคุณรวมสาขานั้นกลับเข้าไปในลำต้นหลักของการพัฒนาและ (ทางเลือก) ลบสาขาที่คุณกำลังทำงานข้อดีของวิธีนี้คือช่วยให้คุณทำงานหลายอย่างพร้อมกันแทนที่จะต้องทำให้เสร็จสมบูรณ์ งานก่อนที่จะเริ่มในครั้งต่อไป

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

จากประสบการณ์ของฉันในการพัฒนาเกมมืออาชีพที่ยิ่งใหญ่เรายังคงยึดติดกับระบบควบคุมเวอร์ชันเก่า (และสนับสนุนในเชิงพาณิชย์) เป็นส่วนใหญ่ Perforce อาจใช้บ่อยที่สุดตามด้วยการโค่นล้ม ทุกที่ที่ฉันทำงานเรามีสาขา 'ลำตัว' แล้วแยกสาขา 'ปล่อย' สำหรับทุกสิ่งที่สามารถส่งได้ บางครั้งใครบางคนจะสร้างสาขาส่วนบุคคลสำหรับการเปลี่ยนแปลงครั้งใหญ่บางอย่างที่พวกเขากำลังสร้างหรือทดสอบ แต่นี่เป็นของหายากมากและมักจะเป็นสิ่งต่าง ๆ เช่น "การแปลงเกมให้ทำงานกับห้องสมุดฟิสิกส์ที่แตกต่างกัน" ซึ่งอาจไม่ผ่าน ผลิตภัณฑ์ที่วางจำหน่าย

คำตอบที่ยอดเยี่ยมอยู่แล้ว แต่สิ่งหนึ่งที่ควรทราบคือเมื่อคุณต้องการแยกสาขาและเมื่อคุณต้องการแท็ก

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

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

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

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

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

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

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

VCS'es นั้นแตกต่างกัน บางอย่างเช่นคอมไพล์ง่ายต่อการแยกจากการกระทำใด ๆ ในเวลาต่อมาอื่น ๆ เช่น CVS นั้นยุ่งยากในการทำงานในภายหลัง

บางทีคุณต้องการเปิดคำถามเกี่ยวกับ stackoverflow โดยถามวิธีการทำงานที่ดีที่สุดกับระบบควบคุมเวอร์ชันที่คุณเลือก หากคุณไม่ได้จริงๆเริ่มต้นยังมีจำนวนมากของประวัติศาสตร์ที่คุณอาจต้องการที่จะเปิดคำถามอธิบายวิธีการทำงานของคุณและขอคำแนะนำของระบบการควบคุมรุ่นที่ดีที่สุดสำหรับคุณหรือไม่?