เป็นวิธีปฏิบัติที่ดีหรือไม่ที่จะใช้กิ่งไม้ในการบำรุงรักษาซอฟต์แวร์รุ่นต่าง ๆ กัน?

เรามีผลิตภัณฑ์ที่มีรุ่นที่แตกต่างกันเล็กน้อย ความแตกต่างอยู่เล็กน้อย: สตริงที่แตกต่างกันตรงนี้และที่นั่น, ตรรกะเพิ่มเติมเล็กน้อยในหนึ่ง, ความแตกต่างของตรรกะในอีกเล็กน้อย เมื่อมีการพัฒนาซอฟต์แวร์การเปลี่ยนแปลงส่วนใหญ่จำเป็นต้องเพิ่มในแต่ละรุ่น อย่างไรก็ตามมีบางอย่างที่ทำไม่ได้และมีบางอย่างที่ต้องแตกต่างกัน มันเป็นการใช้สาขาที่ถูกต้องหรือไม่ถ้าฉันมี release-editionA และ release-editionB (..etc) มี gotchas บ้างไหม? แนวทางปฏิบัติที่ดี?

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

ขึ้นอยู่กับขนาดของการเปลี่ยนแปลง แต่ฉันไม่คิดว่าเป็นการปฏิบัติที่ดีสำหรับความแตกต่างที่คุณอธิบาย

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

หากคุณมีการเปลี่ยนแปลงเล็กน้อยความพยายามในการรวมและการรักษาสาขาดูเหมือนจะเกินความจริงเมื่อเปรียบเทียบกับปัญหา ใช้ preprocessor ของคุณหรือสร้างระบบเพื่อแยกความแตกต่างระหว่างรุ่น #ifdefเคล็ดลับง่าย ๆหรือไม่? จากนั้นอย่าแก้ปัญหาด้วยคอมไพล์มันเกินความจริง

มันไม่ได้เป็นอย่างนั้นจริงๆ สาขาควรจะเป็นเส้นทางด้านข้างระยะสั้นและระยะกลางไปยังสายการพัฒนาของคุณไม่ใช่รหัสรุ่นขนานในระยะยาว

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

ท้ายที่สุดคุณต้องการรักษา "แหล่งแห่งความจริงเดียว"; ด้วยสาขาคุณจะทำซ้ำรหัสบางส่วน แต่ไม่ใช่ทั้งหมดและการรวมบางอย่างจะทำให้การตั้งค่าของคุณเสียจริง

ทางออกหนึ่ง - ตามที่ผู้คนได้ชี้ให้เห็น - คือการกำหนดค่าระบบการสร้างเพื่อสนับสนุนรุ่นต่าง ๆ

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

ดูที่เว็บไซต์นี้

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

สิ่งนี้ฟังดูเหมือนเป็นงานสำหรับการกำหนดค่าการสร้างที่แตกต่างกัน คำตอบของ thitonไปในทิศทางนี้ แต่ฉันจะเอามันไปไกลกว่า#ifdef:

ใช้เป้าหมายการสร้างที่แตกต่างกันเพื่อสร้างซอฟต์แวร์รุ่นต่าง ๆ เป้าหมายอาจแตกต่างกันไป

• การกำหนดค่าที่พวกเขารวมถึง
• วัตถุหรือไฟล์ต้นฉบับที่พวกเขารวมหรือ
• การประมวลผลล่วงหน้าของซอร์สโค้ด

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

ด้วยวิธีนี้คุณหลีกเลี่ยงไม่ต้องผลักดันการเปลี่ยนแปลงทุก ๆ ครั้งไปยังหลายสาขาซึ่งละเมิด DRY (แน่นอนว่ามันอาจเป็นแบบอัตโนมัติ แต่ฉันไม่เห็นประโยชน์)

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

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

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

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