คำถามติดแท็ก branching

การแยกในการควบคุมการแก้ไขคือการทำซ้ำของวัตถุภายใต้การควบคุมการแก้ไขเพื่อให้การแก้ไขสามารถเกิดขึ้นในแบบคู่ขนานไปตามกิ่งไม้ทั้งสอง

3
การแตกกิ่งแยกการบูรณาการอย่างต่อเนื่อง?
ฉันคิดว่าบทความนี้เป็นโมเดลการแยกสาขาที่ประสบความสำเร็จเป็นที่รู้จักกันดีในหมู่ผู้ใช้ DVCS ที่มีประสบการณ์ ฉันใช้hgเป็นส่วนใหญ่ แต่ฉันจะโต้แย้งการอภิปรายนี้เป็นสิ่งที่ดีสำหรับ DVCS ใด ๆ เวิร์กโฟลว์ปัจจุบันของเราคือผู้พัฒนาแต่ละคนลอกแบบต้นแบบธุรกรรมซื้อคืน เราเขียนโค้ดลงบน repo ในพื้นที่ของเราเองทำการทดสอบและถ้าทุกอย่างเข้ากันได้ดีกับมาสเตอร์ ดังนั้นเราจึงต้องการติดตั้งเซิร์ฟเวอร์ CI เช่น Jenkins และปรับปรุงขั้นตอนการทำงานของเราด้วยระบบการจัดเตรียมในอนาคต ส่วนจริง แบบจำลองดังกล่าวข้างต้นใช้งานได้ดี แต่กิ่งสามารถทำลาย CI ได้ สาขาฟีเจอร์ควรซิงค์กับจุดเริ่มต้น (ตามบทความมันจะเป็นdevelopmentสาขา) เพื่อทำให้ CI และการผสานราบรื่นใช่ไหม? Say Alice และ Bob กำลังทำงานกับคุณสมบัติสองอย่าง แต่อลิซเสร็จในวันรุ่งขึ้น คุณสมบัติของ Bob ใช้เวลาหนึ่งสัปดาห์ เมื่อถึงเวลาที่บ๊อบเสร็จสิ้นการเปลี่ยนแปลงของเขาล้าสมัย (อาจจะมีการปรับโครงสร้างใหม่ / เปลี่ยนชื่อคลาสบางส่วน) ทางออกหนึ่งคือนักพัฒนาทุกเช้าต้องดึงmaster/originเพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่ หากอลิซส่งมอบบ๊อบควรดึงและรวมเข้าไปในพื้นที่ทำงานของเขาเพื่อให้ฟีเจอร์สาขาของเขาทันสมัย นี่เป็นวิธีที่ดีหรือไม่? ควรสาขาเหล่านี้มีอยู่ใน repo หลัก (ไม่ใช่โคลนแบบโลคอลหรือไม่) ความหมายของนักพัฒนาทุกคนควรให้สิทธิพิเศษแก่ repo หลักใน …

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

4
นักพัฒนาถูกบล็อกโดยรอรหัสเพื่อรวมจากสาขาอื่นโดยใช้ GitFlow
ทีมของเราเพิ่งเปลี่ยนจาก FogBugz & Kiln / Mercurial เป็น Jira & Stash / Git เรากำลังใช้โมเดล Git Flow สำหรับการแยกสาขาเพิ่มสาขาย่อยย่อยออกจากสาขาคุณลักษณะ (เกี่ยวข้องกับงานย่อย Jira ของคุณสมบัติ Jira) เรากำลังใช้ Stash เพื่อกำหนดผู้ตรวจสอบเมื่อเราสร้างคำขอดึงเพื่อรวมกลับเข้าไปในสาขาหลัก (โดยปกติจะพัฒนา แต่สำหรับงานย่อยกลับเข้าไปในสาขาคุณลักษณะ) ปัญหาที่เราพบคือแม้ว่าจะมีการวางแผนที่ดีที่สุดและพังทลายของกรณีคุณสมบัติเมื่อนักพัฒนาหลายคนทำงานร่วมกันในคุณสมบัติเดียวกันพูดบน front-end และ back-end หากพวกเขากำลังทำงานบนรหัสพึ่งพาซึ่งกันและกัน ในสาขาแยกต่างหากผู้พัฒนารายหนึ่งจะปิดกั้นอีกฝ่าย เราพยายามดึงระหว่างสาขาของกันและกันขณะที่เราพัฒนา นอกจากนี้เรายังพยายามสร้างการรวมสาขาในพื้นที่นักพัฒนาซอฟต์แวร์แต่ละคนสามารถดึงจากหลาย ๆ สาขาเพื่อทดสอบการรวมระบบที่พัฒนาขึ้น ในที่สุดและสิ่งนี้ดูเหมือนว่าจะทำงานได้ดีที่สุดสำหรับเราถึงแม้ว่าจะมีค่าใช้จ่ายเพิ่มขึ้นอีกเล็กน้อยเราได้ลองสร้างสาขาการรวมออกจากสาขาคุณลักษณะทันทีที่ค้างคาว เมื่อสาขาย่อยของภารกิจย่อย (ไม่อยู่ในสาขาฟีเจอร์) พร้อมสำหรับการร้องขอการดึงและการตรวจสอบโค้ดเรายังรวมการเปลี่ยนแปลงที่กำหนดไว้ในสาขาการรวมคุณลักษณะนี้ด้วยตนเอง จากนั้นผู้พัฒนาที่สนใจทุกคนสามารถดึงจากสาขาการรวมเข้ากับสาขาย่อยย่อยอื่น ๆ นี่เป็นการป้องกันไม่ให้ใครก็ตามที่รอสาขาที่พวกเขาต้องพึ่งพาเพื่อตรวจสอบรหัส ฉันรู้ว่านี่ไม่จำเป็นต้องเป็นปัญหา Git - มันเกี่ยวกับการทำงานกับการพึ่งพาซึ่งกันและกันของรหัสในหลายสาขาผสมผสานกับกระบวนการทำงานและวัฒนธรรมของเราเอง หากเราไม่มีนโยบายการตรวจสอบรหัสที่เข้มงวดสำหรับการพัฒนา (สาขาการรวมที่แท้จริง) นักพัฒนา 1 …

3
Git: สาขาหรือทางแยก?
ฉันมีโครงการเกมที่จะมีสองเวอร์ชัน: เกมเวอร์ชั่นหลักที่เรียบง่าย เกมขั้นสูง ฉันมีรุ่นที่ 1 ในที่เก็บสาธารณะของฉันและฉันเท่านั้นที่จะทำงานกับมัน สำหรับรุ่นที่ 2 เพื่อนของฉันสองคนและฉันจะทำงานกับมัน ส่วนที่สำคัญคือฉันต้องการให้ทั้งสองเวอร์ชันอยู่ในที่เก็บของฉัน ฉันคิดว่าฉันอาจใช้กิ่งไม้เพื่อทำสิ่งนี้ แต่เมื่อพิจารณาคำถามและคำตอบของคำถามนี้มันไม่ใช่วิธีปฏิบัติที่ดีในการทำเวอร์ชัน เท่าที่ฉันได้พบการฟอร์กพื้นที่เก็บข้อมูลของคุณเองเป็นไปไม่ได้ ตัวเลือกของฉันที่นี่มีอะไรบ้าง ฉันจะเก็บทั้งสองเวอร์ชันไว้ในที่เก็บของฉันได้อย่างไร

3
Git: การแก้ไขข้อบกพร่องที่มีผลกระทบต่อสองสาขา
ฉันใช้ repo Git ของฉันในแบบจำลอง Git branching ที่ประสบความสำเร็จและสงสัยว่าจะเกิดอะไรขึ้นถ้าคุณมีสถานการณ์นี้: สมมติว่าฉันกำลังพัฒนาบนฟีเจอร์สองสาขา A และ B และ B ต้องใช้รหัสจาก A. โหนด X แนะนำข้อผิดพลาดในฟีเจอร์ A ซึ่งส่งผลกระทบต่อสาขา B แต่ไม่พบที่โหนด Y ที่ผสานคุณสมบัติ A และ B และ ทำการทดสอบก่อนที่จะแตกแขนงออกไปอีกครั้งและทำงานในการทำซ้ำครั้งถัดไป เป็นผลให้ข้อผิดพลาดที่พบในโหนด Z โดยคนที่ทำงานเกี่ยวกับคุณสมบัติ B ในขั้นตอนนี้ก็ตัดสินใจว่าจำเป็นต้องมีการแก้ไขข้อบกพร่อง การแก้ไขนี้ควรนำไปใช้กับฟีเจอร์ทั้งสองเนื่องจากผู้ที่ทำงานในฟีเจอร์ A ต้องมีการแก้ไขบั๊กเนื่องจากเป็นส่วนหนึ่งของฟีเจอร์ ควรจะสร้างสาขา bugfix จากคุณสมบัติ A ล่าสุดหรือไม่ (รวมเป็นหนึ่งจากโหนด Y) จากนั้นผสานกับคุณสมบัติ A หลังจากนั้นฟีเจอร์ทั้งสองจะถูกรวมเข้ากับการพัฒนาอีกครั้งและทดสอบก่อนที่จะแตกแขนงออก? ปัญหานี้คือมันต้องการให้ทั้งสองสาขารวมเพื่อแก้ไขปัญหา เนื่องจากฟีเจอร์ B …
16 git  bug  branching 

3
กลยุทธ์การแยก Git สำหรับโค้ดที่ยังไม่เผยแพร่ซึ่งใช้งานมานาน
ที่ทีมของเรานอกเหนือจากงานแต่ละหน่วย (เรื่อง) เรามีธีมการทำงานที่ยาวนานขึ้น (Epics) เรื่องราวหลากหลายทำให้มหากาพย์ ตามเนื้อผ้าเรามีฟีเจอร์กิ่งไม้สำหรับแต่ละเรื่องและรวมเหล่านั้นเข้ากับมาสเตอร์เมื่อพวกเขาผ่าน QA อย่างไรก็ตามเราต้องการเริ่มระงับการเผยแพร่เรื่องราวที่เสร็จสมบูรณ์ใน Epic จนกว่า Epic จะถือเป็น "คุณลักษณะเสร็จสมบูรณ์" เราจะปล่อยฟีเจอร์เหล่านี้เป็นการผลิตเมื่อปิด Epic ทั้งหมดแล้วเท่านั้น นอกจากนี้เรามีเซิร์ฟเวอร์ที่สร้างขึ้นทุกคืน - เราต้องการให้เรื่องราวทั้งหมดที่ปิด (รวมถึงส่วนที่เป็นส่วนหนึ่งของ Epics ที่ไม่สมบูรณ์) ถูกนำไปใช้กับเซิร์ฟเวอร์รายคืนนี้โดยอัตโนมัติ มีคำแนะนำใด ๆ เกี่ยวกับวิธีจัดการ repo ของเราเพื่อให้บรรลุเป้าหมายนี้หรือไม่? ฉันคิดว่าจะแนะนำ "สาขาที่ยิ่งใหญ่" ซึ่งเราจะรวมเรื่องที่ปิดไปยังสาขาที่เกี่ยวข้องแทนการเป็นอาจารย์โดยตรง แต่ข้อกังวลของฉันคือ: ฉันกังวลเกี่ยวกับความขัดแย้งที่อาจเกิดขึ้นหากสาขามหากาพย์เปิดให้บริการเป็นเวลานาน งานสร้างยามค่ำคืนจะต้องรวมสาขาของมหากาพย์ทั้งหมดไว้ในสาขา "สร้างยามค่ำคืน" อีกครั้งอาจเกิดความขัดแย้งผสานและสิ่งนี้จะต้องทำโดยอัตโนมัติ

5
วิธีที่มีประสิทธิภาพที่สุดในการแบ่งปันรหัสระหว่างแอปพลิเคชัน. NET คืออะไร
ในงานของเราเรามีแอปพลิเคชั่น. net ที่แตกต่างกันมากมายซึ่งมีฟังก์ชั่นพื้นฐานมากมาย เราได้สร้างแอปพลิเคชันเหล่านี้โดยใช้สถาปัตยกรรมระดับ n ที่สะอาด แต่เราได้พบกับช่วงเวลาที่เราตระหนักว่าเราได้ใช้ฟังก์ชั่นเดิมซ้ำหลายครั้ง เห็นได้ชัดว่านี่เป็นการละเมิด DRY และเราต้องการแก้ไขให้ถูกต้อง เรากำลังใช้ Nuget เพื่อความสำเร็จสำหรับรหัสกาวทั่วไป (เดินสาย IoC บันทึกการตั้งค่า) แต่เราต้องการแบ่งปันข้อมูลและชั้นธุรกิจระหว่างแอปพลิเคชันทั้งหมดของเรา แนวคิดก็คือ UI จะจัดการกับส่วนต่างๆของชั้นธุรกิจที่ต้องการจริงๆเท่านั้น สิ่งนี้ดูเหมือนว่าจะเป็นปัญหาตรงไปตรงมาในตอนแรก แต่การพัฒนาอย่างต่อเนื่องอาจทำให้เกิดข้อผิดพลาดบางอย่างและเราไม่แน่ใจว่าจะดำเนินการอย่างไร สมมติว่าเราสร้างหนึ่งชั้นธุรกิจของเราเพื่อปกครองพวกเขาทั้งหมด ฉันจะเรียกมันว่า "รากฐาน" เราแจ้งแอปพลิเคชันของเราเพื่อใช้งานมูลนิธิและทุกอย่างก็ยอดเยี่ยมมาก รากฐานถูกแจกจ่ายไปยังเลเยอร์ UI แบบแสงผ่านทาง nuget และเราดูดี แต่แล้วเราก็เริ่มเพิ่มคุณสมบัติให้กับแอปพลิเคชันของเราและเราประสบปัญหา สมมติว่าเรากำลังทำงานในโครงการ A และเราเพิ่มคุณสมบัติใหม่ที่ต้องมีการเปลี่ยนแปลงในมูลนิธิ เราทำการเปลี่ยนแปลงรากฐาน (Foundation-A) และผลักดันพวกเขาออกไปยังฟีด nuget เป็นแพ็กเกจที่ไม่เสถียร Project A ได้รับแพ็คเกจ nuget ล่าสุดและทั้งหมดนั้นดี ในขณะเดียวกันผู้พัฒนารายอื่นกำลังทำงานในโครงการ B. เขาได้รับพื้นฐานล่าสุดจากการควบคุมแหล่ง แต่นำมาจากสาขาที่มีเสถียรภาพดังนั้นจึงไม่มีการเปลี่ยนแปลงโครงการ A …

2
เค้าโครงโครงการขนาดใหญ่: การเพิ่มคุณสมบัติใหม่ในโครงการย่อยหลายโครงการ
ฉันต้องการทราบวิธีการจัดการโครงการขนาดใหญ่ที่มีส่วนประกอบจำนวนมากพร้อมระบบการจัดการการควบคุมเวอร์ชัน ในโครงการปัจจุบันของฉันมี 4 ส่วนหลัก เว็บ เซิร์ฟเวอร์ คอนโซลผู้ดูแลระบบ เวที ส่วนของเว็บและเซิร์ฟเวอร์ใช้ 2 ไลบรารีที่ฉันเขียน โดยรวมมีที่เก็บ 5 git และที่เก็บข้อมูล 1 แห่ง สคริปต์บิลด์โปรเจ็กต์อยู่ในที่เก็บแพล็ตฟอร์ม มันทำให้กระบวนการสร้างทั้งหมดเป็นไปโดยอัตโนมัติ ปัญหาคือเมื่อฉันเพิ่มคุณสมบัติใหม่ที่มีผลต่อองค์ประกอบหลายอย่างฉันต้องสร้างสาขาสำหรับแต่ละ repo ที่ได้รับผลกระทบ ใช้งานคุณสมบัติ รวมมันกลับมา ความรู้สึกของฉันคือ "มีอะไรผิดปกติ" ดังนั้นฉันจึงควรสร้าง repo เดียวและวางองค์ประกอบทั้งหมดที่นั่น? ฉันคิดว่าการแตกกิ่งจะง่ายกว่าในกรณีนั้น หรือฉันเพิ่งจะทำสิ่งที่ฉันกำลังทำอยู่ตอนนี้ ในกรณีนั้นฉันจะแก้ปัญหานี้ในการสร้างสาขาในแต่ละที่เก็บได้อย่างไร

2
รูปแบบการแยกสาขาที่เหมาะสมสำหรับผลิตภัณฑ์ที่ควรมาพร้อมกับรุ่นของผลิตภัณฑ์ของบุคคลที่สามอื่น ๆ (และข้อดีข้อเสียของข้อเสนอหนึ่ง)
หมายเหตุ: คำถามของฉันมุ่งเน้นที่ปัญหาเฉพาะของฉัน (ซึ่งเกี่ยวข้องกับ Liferay) แต่ฉันหวังว่ามันจะมีประโยชน์สำหรับทุกคนที่ต้องการบำรุงรักษาโครงการเดียวกันในคอมไพล์รุ่นต่างๆ ผมทำงานใน บริษัท ที่เขียนจำนวนมากของปลั๊กอินสำหรับLiferay พอร์ทัล ปลั๊กอินเหล่านี้ (พอร์ตเล็ต, ธีม ฯลฯ ) โดยปกติจะสามารถใช้ซ้ำได้และแน่นอนควรได้รับการอัปเดตสำหรับพอร์ทัลเวอร์ชันใหม่ อย่างไรก็ตามเป็นเรื่องปกติที่จะต้องย้ายข้อมูลให้เราบอกว่าพอร์ตเล็ตเป็นเวอร์ชันใหม่ของ Liferay และเพื่อรักษาเวอร์ชันก่อนหน้า นอกจากนี้บ่อยครั้งที่เราต้องสร้างการปรับแต่งที่เฉพาะเจาะจงมากสำหรับลูกค้าบางรายซึ่งไม่สมเหตุสมผลที่จะเพิ่มใน "เวอร์ชันหลัก" ข้อกำหนดเหล่านี้ทำให้งานของเราซับซ้อน แต่โชคดีที่เราสามารถสันนิษฐานได้ว่ามีความเรียบง่าย ตัวอย่างเช่นปลั๊กอินมีการอัปเดตบ่อยครั้งโดยโปรแกรมเมอร์เพียงหนึ่งคนในแต่ละครั้ง มันเป็นเรื่องยากมากที่จะมีการเพิ่มคุณสมบัติสองอย่างขึ้นไปในปลั๊กอินในเวลาเดียวกัน ขณะนี้เรากำลังย้ายไปGitorious เราพยายามที่จะเข้าใจรูปแบบการแตกแขนงสำหรับสถานการณ์ดังกล่าว โมเดลของฉัน สิ่งที่ฉันเสนอคือ: แต่ละปลั๊กอินจะมีพื้นที่เก็บข้อมูลของตัวเองใน Gitorious ภายในโครงการ ตัวอย่างเช่นพอร์ตเล็ตสำหรับแสดงลูกแมวจะมีkittens-portletพื้นที่เก็บข้อมูลภายในliferay-portletsโครงการ เมื่อสร้างปลั๊กอินใหม่ให้สร้างขึ้นที่สาขาที่มีชื่อตามเวอร์ชัน Liferay (ตัวอย่างเช่นlf5.2) ทุกครั้งที่มีการปรับปรุงจะทำบนปลั๊กอิน, อัพเดทได้รับการอนุมัติและนำไปใช้ในการผลิต, การติดแท็กปลั๊กอินที่มีรุ่น (ตัวอย่างเช่นlf5.2v1, lf5.2v2ฯลฯ .) * ทุกครั้งที่มีการย้ายปลั๊กอินไปยัง Liferay เวอร์ชันใหม่เราจะทำการแยกสาขาเวอร์ชันล่าสุด (การสร้างเช่นสาขาlf6.0) lf6.0v1เมื่อในการผลิตหัวของสาขาใหม่จะได้รับแท็กเช่น ทุกครั้งที่เราต้องปรับแต่งปลั๊กอินในแบบเฉพาะลูกค้าเราสร้างสาขาที่มีชื่อลูกค้า (ตัวอย่างเช่นเราจะสร้างสาขาlf5.2clientcorpสำหรับลูกค้าของเรา "ClientCorp …

1
Git branching จากฟีเจอร์ branch เพื่อทำงานบนฟีเจอร์ย่อย
ขณะนี้เราอยู่ในสถานการณ์ต่อไปนี้ที่สาขาฟีเจอร์ได้รับการแยกสาขาสำหรับฟีเจอร์ย่อย (เช่นทำงานบนแบ็กเอนด์และส่วนหน้าสำหรับฟีเจอร์เดียวกัน): o | o development |\ | o feature-a | | | o | |\ | | o feature-a-sub | | | | | | | \ | o merged feature-a into feature-a-sub | / o feature-a-sub merged into development | | | o feature-a with future work on …
12 git  branching 

1
คอมไพล์ที่มีประโยชน์กระทำข้อความสำหรับสาขาที่ผสาน
ติดตามคำถามนี้ : ถ้าฉันทำงานเป็นทีมด้วยตัวเองฉันสามารถรักษาข้อความการส่งข้อความที่มีประโยชน์เมื่อทำการรวมสาขาโดยการบีบคอมมิชชันทั้งหมดลงใน diff เดียวแล้วจึงรวมส่วนนั้น ด้วยวิธีนี้ฉันสามารถเห็นการเปลี่ยนแปลงที่นำมาใช้ในสาขาได้อย่างง่ายดายและฉันมีบทสรุปเดียวที่อธิบายถึงคุณสมบัติ / การเปลี่ยนแปลง / สิ่งที่ประสบความสำเร็จในสาขานั้นเมื่อเรียกดูสาขาหลัก คำถามของฉันคือฉันจะทำสิ่งนี้ให้สำเร็จเมื่อทำงานกับทีมได้อย่างไร ในสถานการณ์ที่สาขาจะได้รับการผลักดันให้พื้นที่เก็บข้อมูลระยะไกลซึ่งหมายความว่าฉันไม่สามารถสควอชกระทำทั้งหมดที่อยู่ในสาขาลงไปที่เดียวกระทำ หากสาขาเป็นแบบสาธารณะฉันจะยังคงสามารถทำการผสานที่เป็นประโยชน์เพียงครั้งเดียวในสาขาหลักได้หรือไม่? (โดย "มีประโยชน์" ฉันหมายถึงความมุ่งมั่นในสายปรมาจารย์บอกฉัน (1) บทสรุปที่เป็นประโยชน์เกี่ยวกับสิ่งที่ทำในสาขาและ (2) ต่างจากเดิม)
12 git  branching 

6
เราจะรวมเฉพาะฟีเจอร์ที่พร้อมวางจำหน่ายในการผลิตของเราทุกสัปดาห์ได้อย่างไร
ฉันเป็นนักพัฒนาซอฟต์แวร์ในทีมเปรียวขนาดใหญ่พอสมควร (เรามีนักพัฒนาแปดคนทำการเปลี่ยนแปลงที่เก็บรหัสเดียว) ทุกสองสัปดาห์เราจะผลักดันซอฟต์แวร์เวอร์ชันใหม่ให้ผลิต นี่คือขั้นตอนการทำงานปัจจุบันของเรา: เมื่อเริ่มงานใหม่นักพัฒนาจะสร้าง "ฟีเจอร์บรานช์" จากสาขาการพัฒนาหลัก (เราใช้คอมไพล์ ) และทำงานนอกสาขาใหม่นี้ เมื่อนักพัฒนาซอฟต์แวร์ทำงานเสร็จแล้วพวกเขาจะรวมสาขาฟีเจอร์ของพวกเขากลับเข้าไปในสาขาการพัฒนา ผู้พัฒนาผสานสาขาการพัฒนาเข้ากับสาขา QA บิลด์จะถูกทริกเกอร์จากสาขา QA ผลลัพธ์ของโครงสร้างนี้ถูกปรับใช้ในสภาพแวดล้อม QA ของเราเพื่อให้ผู้ทดสอบเริ่มการทดสอบ เป็นเรื่องปกติที่ผู้ทดสอบของเราจะพบปัญหาเกี่ยวกับคุณสมบัติใหม่เหล่านี้ซึ่งได้รวมเข้ากับสาขา QA ซึ่งหมายความว่าในเวลาใดก็ตามสภาพแวดล้อม QA อาจมีคุณสมบัติใหม่หลายประการ - บางส่วนผ่านการทดสอบและปราศจากข้อบกพร่องและบางส่วนเสีย สิ่งนี้ทำให้การปล่อยทำได้ยากเพราะหายากที่ QA build อยู่ในสถานะพร้อมใช้งานการผลิต เพื่อบรรเทาปัญหานี้เราได้พยายามเริ่มต้น "การหยุด QA" ซึ่งหมายความว่านักพัฒนาไม่รวมสาขาการพัฒนาของเราเข้ากับสาขา QA สองสามวันก่อนการเปิดตัว การแก้ไขข้อบกพร่องของสภาพแวดล้อม QA นั้นเกิดขึ้นโดยตรงกับสาขา QA และรวมเข้ากับสาขาการพัฒนา ในทางทฤษฎีสิ่งนี้ทำให้คุณสมบัติใหม่แตกออกจาก QA ในขณะที่ยังช่วยให้เราสามารถแก้ไขปัญหาที่มีอยู่แล้วใน QA ในขณะที่แนวคิด "QA freeze" ประสบความสำเร็จเพียงบางส่วน แต่ก็ยากที่จะประสานงานและผู้คนมักสับสนว่าพวกเขาได้รับอนุญาตให้รวมกับ QA …

4
คุณควรปรับปรุงคุณภาพของรหัสขณะทำงานในฟีเจอร์ Branch
ฉันชอบบทความนี้มากเกี่ยวกับการทิ้งโค้ด / ไซต์แคมป์ไว้ในสถานะที่ดีกว่าที่คุณพบ - ดูเหมือนว่าแนวทางปฏิบัติในโลกแห่งความเป็นจริงเพื่อรักษาความสะอาดของโค้ดเอาไว้ ฉันชอบสาขาคุณลักษณะเป็นวิธีในการพัฒนาคุณลักษณะแยกต่างหากดังนั้นถ้าคุณไม่ชอบคุณจะไม่สามารถรวม ฯลฯ ได้อย่างง่ายดาย อย่างไรก็ตามหากฉันทำงานในสาขาฟีเจอร์และฉันพบรหัสที่น่าเกลียดฉันควรแก้ไขไหม รู้สึกเหมือนมีจำนวนขาลงที่จะแก้ไข: เมื่อฉันรวมสาขากลับเข้า diff จะยุ่งเหยิงรกด้วยการเปลี่ยนชื่อตัวแปรหรือการดึงฟังก์ชั่น หากสถานที่นั้นถูกทิ้งร้างคุณต้องเลือกการทำความสะอาด (ซึ่งอาจหรืออาจจะไม่ทำงานขึ้นอยู่กับว่าโค้ดที่อยู่ใกล้มันมีการเปลี่ยนแปลงอย่างไรทำให้เกิดความสับสน) ทำการทำใหม่หรือทิ้งมันไป ด้านพลิกถ้าฉันไม่ทำในขณะที่ฉันอยู่ในไฟล์แล้วชัดเจนฉันจะลืมที่จะทำในเวลาสองสามวันเมื่อฉันรวมสาขาใน ฉันถูกเตือนว่านี่เป็นพื้นฐานของความคิดเห็น (ฉันคิดว่าเป็นความจริงที่ชื่อรวมอยู่ด้วยshould) แต่ฉันรู้สึกเหมือนมีคำตอบ (แน่นอนว่าผู้คนใช้วิธีทั้งสองนี้ดังนั้นพวกเขาจึงต้องมีคำตอบ) นอกจากนี้คำถามเกี่ยวกับdevelopment methodologiesอยู่ในหัวข้อและฉันคิดว่าพวกเขาต้องการระดับความคิดเห็น

6
ในคอมไพล์วิธีการกำหนดเวอร์ชันสำหรับไลบรารีโหลทั้งหมดนั้นทำงานพร้อมกัน
เรากำลังทำโครงการ แต่เราใช้รหัสจำนวนมากระหว่างโครงการและมีห้องสมุดจำนวนมากที่มีรหัสทั่วไปของเรา ในขณะที่เราใช้งานโครงการใหม่เราค้นหาวิธีเพิ่มเติมในการแยกตัวประกอบของรหัสทั่วไปและใส่ลงในไลบรารี ห้องสมุดขึ้นอยู่กับแต่ละอื่น ๆ และโครงการขึ้นอยู่กับห้องสมุด แต่ละโปรเจ็กต์และไลบรารีทั้งหมดที่ใช้ในโปรเจ็กต์นั้นจำเป็นต้องใช้เวอร์ชันเดียวกันกับไลบรารีทั้งหมดที่อ้างถึง ถ้าเราปล่อยชิ้นส่วนของซอฟต์แวร์เราจะต้องแก้ไขข้อบกพร่องและอาจเพิ่มคุณสมบัติใหม่เป็นเวลาหลายปีบางครั้งก็เป็นเวลาหลายทศวรรษ เรามีห้องสมุดประมาณหนึ่งโหลการเปลี่ยนแปลงมักจะถูกตัดข้ามมากกว่าสองรายการและหลายทีมทำงานในหลายโครงการพร้อมกันโดยทำการเปลี่ยนแปลงพร้อมกันกับไลบรารีทั้งหมดเหล่านี้ เมื่อเร็ว ๆ นี้เราได้เปลี่ยนเป็นคอมไพล์และตั้งค่าที่เก็บสำหรับแต่ละไลบรารีและแต่ละโครงการ เราใช้ที่เก็บของเป็นที่เก็บข้อมูลทั่วไปทำสิ่งใหม่ ๆ ในฟีเจอร์สาขาจากนั้นทำการร้องขอการดึงและรวมเข้าด้วยกันหลังจากตรวจสอบแล้ว ปัญหาหลายอย่างที่เราต้องจัดการในโครงการต้องการให้เราทำการเปลี่ยนแปลงในหลาย ๆ ไลบรารีและรหัสเฉพาะของโครงการ สิ่งเหล่านี้มักจะรวมถึงการเปลี่ยนแปลงอินเทอร์เฟซของไลบรารีซึ่งบางอย่างไม่เข้ากัน (ถ้าคุณคิดว่ามันฟังดูแปลก ๆ : เราเชื่อมต่อกับฮาร์ดแวร์และซ่อนฮาร์ดแวร์ที่เฉพาะเจาะจงไว้ข้างหลังอินเตอร์เฟสทั่วไปเกือบทุกครั้งที่เรารวมฮาร์ดแวร์ของผู้ขายรายอื่นที่เราพบในกรณีที่อินเทอร์เฟซปัจจุบันของเราไม่ได้คาดหวัง ตัวอย่างเช่นสมมติว่าโครงการที่P1ใช้ห้องสมุดL1, และL2 ยังใช้และ, และใช้เช่นกัน กราฟการพึ่งพามีลักษณะดังนี้:L3L1L2L3L2L3 <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ ตอนนี้คิดคุณลักษณะสำหรับโครงการนี้ต้องมีการเปลี่ยนแปลงในP1และที่เปลี่ยนอินเตอร์เฟซของL3 L3ตอนนี้เพิ่มโปรเจ็กต์P2และP3ลงในแบบผสมซึ่งยังอ้างถึงไลบรารีเหล่านี้ เราไม่สามารถเปลี่ยนทุกสิ่งให้เป็นอินเทอร์เฟซใหม่ทำการทดสอบทั้งหมดและปรับใช้ซอฟต์แวร์ใหม่ …

6
การเลือกกลยุทธ์การแยกสาขาที่เหมาะสมสำหรับการเผยแพร่
เริ่มต้นด้วยทีม dev ใหม่ในโครงการใหม่และเราต้องกำหนดกลยุทธ์การแบ่งสาขาสำหรับแหล่งเก็บข้อมูลของเรา ( เช่น Microsoft Team Foundation Server 2010 ) เราได้ทำการอภิปรายกันอย่างเหนียวแน่นว่าจะ ... ก . มีสาขาReleaseหนึ่งสาขาที่เราผลิตงานสร้างและจากนั้นLabelเมื่อมีบางอย่างออกวางจำหน่ายจริง หรือ ข . มีสาขาReleaseใหม่สำหรับแต่ละ Release ใหม่เข้าสู่การผลิต ( เช่นเวอร์ชัน 1, 2, 3, ฯลฯ ... ) ตัวเลือกAดูเหมือนจะตรงไปตรงมา แต่เราไม่แน่ใจว่าสิ่งนี้จะนำไปสู่ปัญหาในระยะยาวหรือไม่ ตัวเลือกBดูเหมือนว่าจะเป็นเพียงการสร้างกิ่งไม้ที่มีอายุยืนยาวจำนวนมากเพียงครั้งเดียว ไม่มีใครมีประสบการณ์อย่างใดอย่างหนึ่งที่สามารถช่วยเราตัดสินใจได้ โดยเฉพาะฉันกำลังมองหาว่าจุดปวดอยู่ที่ใดสำหรับทางเลือกหนึ่ง อย่าลังเลที่จะมอบประสบการณ์เฉพาะที่เกี่ยวข้องกับ TFS และ / หรือนัยต่อการจัดการที่วางจำหน่าย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.