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

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

223 git  software  branching  merging 

ข้อดีอย่างหนึ่งของการใช้ DVCS คือเวิร์กโฟลว์edit-commit-merge (การแก้ไขมากกว่าการผสานผสานกระทำบ่อยครั้งบังคับใช้โดย CVCS) การอนุญาตให้บันทึกการเปลี่ยนแปลงที่ไม่ซ้ำกันแต่ละครั้งในที่เก็บซึ่งเป็นอิสระจากการรวมกันทำให้มั่นใจได้ว่าDAGสะท้อนถึงสายเลือดที่แท้จริงของโครงการอย่างถูกต้อง ทำไมเว็บไซต์จำนวนมากถึงพูดถึงความต้องการที่จะ "หลีกเลี่ยงการรวมคอมมิท"? การไม่รวมการกระทำก่อนหน้าหรือการทำโพสต์ใหม่เข้าด้วยกันทำให้ยากต่อการแยกการถดถอยการย้อนกลับการเปลี่ยนแปลงที่ผ่านมา ฯลฯ จุดชี้แจง:พฤติกรรมเริ่มต้นสำหรับ DVCS คือการสร้างการรวมการกระทำ ทำไมหลายสถานที่พูดถึงความปรารถนาที่จะเห็นประวัติศาสตร์การพัฒนาเชิงเส้นที่ซ่อนการกระทำเหล่านี้ไว้?

68 version-control  git  dvcs  merging 

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

40 version-control  branching  merging 

ฉันมีลูกค้าที่ยืนยันว่าเราแยกการพัฒนาใหม่ออกจากสาขาหลักตลอดทั้งปี 2559 พวกเขามีทีมอื่นอีก 3-4 ทีมที่ทำงานในแอปพลิเคชั่นในความสามารถที่หลากหลาย มีการเปลี่ยนแปลงขนาดใหญ่จำนวนมาก (การสลับวิธีการฉีดการพึ่งพาการทำความสะอาดโค้ดด้วย ReSharper ฯลฯ ) ตอนนี้ฉันตกหลุมรักที่จะรวมหลักในสาขาการพัฒนาใหม่ของเราเพื่อเตรียมที่จะผลักดันการเปลี่ยนแปลงของเราขึ้นโซ่ เมื่อดึงจดหมายเวียนครั้งแรกของฉัน TFS รายงานไฟล์ ~ 6500 ด้วยการแก้ไขข้อขัดแย้ง บางส่วนจะง่าย แต่บางตัวก็ยากกว่า (โดยเฉพาะบางตัวของจาวาสคริปต์ตัวควบคุม api และบริการที่สนับสนุนตัวควบคุมเหล่านี้) มีวิธีที่ฉันสามารถทำได้ซึ่งจะทำให้เรื่องนี้ง่ายขึ้นสำหรับฉันหรือไม่ เพื่อชี้แจงฉันแสดงความกังวลอย่างมากกับวิธีนี้หลายครั้งตลอดทาง ลูกค้าคือและตระหนักถึงปัญหานี้ เนื่องจากพวกเขาเลือกที่จะย่อพนักงาน QA (1 ผู้ทดสอบสำหรับ 4 devs, ไม่มีการทดสอบอัตโนมัติ, การทดสอบการถดถอยเล็กน้อย) พวกเขายืนยันว่าเราแยกสาขาของเราออกจากการเปลี่ยนแปลงในสาขาหลักภายใต้ข้ออ้างว่าสิ่งนี้จะลดความต้องการของเรา ผู้ทดสอบเพื่อทราบเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นที่อื่น หนึ่งในปัญหาที่ใหญ่กว่าที่นี่คือการอัปเกรดเป็นรุ่นแองกูลาร์และซอฟต์แวร์อื่น ๆ ของบุคคลที่สาม - โชคไม่ดีที่เราไม่มีวิธีการที่ดีในการสร้างโซลูชันนี้จนกว่าจะนำชิ้นส่วนทั้งหมดกลับเข้าที่

32 visual-studio  merging 

ฉันเพิ่งมาข้ามบทความ MSDN เกี่ยวกับการแยกทางและการผสานและ SCM: การแตกแขนงและผสานรองพื้น - คริส Birmele ในบทความพวกเขาบอกว่า 'บิ๊กแบงผสาน' เป็นปฏิปักษ์ต่อการรวม: Big Bang Merge - ชะลอการรวมสาขาเพื่อสิ้นสุดความพยายามในการพัฒนาและพยายามรวมสาขาทั้งหมดพร้อมกัน ฉันรู้ว่านี่คล้ายกับสิ่งที่ บริษัท ของฉันทำกับสาขาการพัฒนาทั้งหมดที่ผลิต ฉันทำงานที่ บริษัท ขนาดเล็กมากโดยมีคนคนหนึ่งทำหน้าที่เป็นผู้ตรวจสอบขั้นสุดท้าย + มีอำนาจในการรวมลำตัว เรามีนักพัฒนา 5 คน (รวมถึงฉันด้วย) เราแต่ละคนจะได้รับมอบหมายภารกิจ / ข้อบกพร่อง / โครงการแยกจากกันและเราจะแยกแต่ละสาขาออกจากเส้นทางปัจจุบัน (การโค่นล้ม) จากนั้นทำการพัฒนาในสาขาของเราทดสอบผลลัพธ์เขียนเอกสาร หากจำเป็นให้ดำเนินการตรวจสอบแบบเพียร์และข้อเสนอแนะกับนักพัฒนาอื่น ๆ แล้วส่งสาขาสำหรับความคิดเห็น + ผสานในซอฟต์แวร์การจัดการโครงการของเรา เจ้านายของฉันซึ่งเป็นผู้มีอำนาจ แต่เพียงผู้เดียวในที่เก็บ trunk จะทำการตรวจสอบความคิดเห็นทั้งหมดของสาขาจนกว่าจะถึงจุดเดียวในเวลาที่เขาจะแสดงความคิดเห็นให้มากที่สุดเท่าที่จะทำได้บางสาขาจะถูกโยนทิ้งเพื่อปรับปรุง / แก้ไข กิ่งไม้จะถูกรวมเข้ากับลำต้นบางสาขาจะถูกโยนกลับเนื่องจากความขัดแย้ง ฯลฯ ไม่ใช่เรื่องแปลกที่เราจะมีสาขาที่ใช้งานอยู่ 10-20 …

28 svn  anti-patterns  merging  scm 

สำเนาซ้ำที่เป็นไปได้: ฉันเป็นผู้ที่ถูกโค่นล้มทำไมฉันจึงควรพิจารณาหรือไม่พิจารณา Mercurial หรือ Git หรือ DVCS อื่น ๆ ทุกครั้งที่คุณได้ยินคนพูดว่าการควบคุมเวอร์ชันแบบกระจาย (Git, HG) นั้นดีกว่าการควบคุมเวอร์ชั่นแบบรวมศูนย์ (เช่น SVN) เนื่องจากการรวมกันนั้นยากและเจ็บปวดใน SVN สิ่งนี้คือฉันไม่เคยมีปัญหาใด ๆ กับการรวมใน SVN และเนื่องจากคุณเคยได้ยินการอ้างสิทธิ์ที่ทำโดยผู้สนับสนุน DVCS และไม่ใช่ผู้ใช้ SVN จริงมันมีแนวโน้มที่จะเตือนฉันเกี่ยวกับโฆษณาที่น่ารังเกียจบนทีวีที่พวกเขา พยายามขายสิ่งที่คุณไม่ต้องการโดยให้นักแสดงทำผิดพลาดแสร้งทำเป็นว่าสิ่งที่คุณมีอยู่แล้วและใช้งานได้ดีใช้ยากอย่างไม่น่าเชื่อ และกรณีการใช้งานที่นำขึ้นมาอย่างสม่ำเสมอคือการรวมสาขาอีกครั้งหนึ่งซึ่งทำให้ฉันนึกถึงโฆษณาผลิตภัณฑ์ฟางแมนอีกครั้ง หากคุณรู้ว่าคุณกำลังทำอะไรคุณไม่ควร (และไม่ควรต้อง) รวมสาขาในตอนแรก (แน่นอนว่ามันยากที่จะทำเมื่อคุณทำอะไรผิดพลาดและไร้สาระ!) ดังนั้นการลดกรณีการใช้ชาวฟางที่ไร้สาระมีอะไรบ้างในการรวม SVN ที่ยากกว่าการรวมในระบบ DVCS โดยรวม

28 git  svn  mercurial  dvcs  merging 

ฉันเพิ่งเรียนรู้ว่าเมื่อรวมสองสาขาในคอมไพล์ถ้ามีการเปลี่ยนแปลงในสองบรรทัดที่อยู่ติดกันคอมไพล์ประกาศความขัดแย้งนี้ ตัวอย่างเช่นหากไฟล์test.txtมีเนื้อหานี้: Line 1: A Line 2: B Line 3: C Line 4: D และในสาขาmasterเราเปลี่ยนสิ่งนี้เป็น Line 1: A Line 2: B1 Line 3: C Line 4: D ในขณะที่สาขาtestingเราเปลี่ยนสิ่งนี้เป็น Line 1: A Line 2: B Line 3: C1 Line 4: D และจากนั้นพยายามที่จะรวมtestingเข้าไปในmasterคอมไพล์ประกาศความขัดแย้งผสาน ความคาดหวังที่ไร้เดียงสาของฉันคือการรวมจะเกิดขึ้นโดยไม่มีความขัดแย้งและให้สิ่งนี้: Line 1: A Line 2: B1 Line 3: …

25 git  merging 

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

16 version-control  git  merging 

อะไรคือข้อดีของการใช้คำขอดึงแทนที่จะรวมสาขาเข้ากับต้นแบบโดยไม่มี โดยเฉพาะอย่างยิ่งในทีมที่นักพัฒนาซอฟต์แวร์ทุกคนสามารถเข้าถึงมาสเตอร์ได้อย่างสมบูรณ์

16 version-control  git  development-process  merging  pull-requests 

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

13 version-control  branching  configuration-management  merging 

ตอนนี้ฉันใช้ GitHub มาระยะหนึ่งแล้วฉันมักจะใช้ฟีเจอร์ - สาขาแล้วก็เริ่มคำขอดึงซึ่งตัวฉันเองรวมเข้าด้วยกัน ฉันพบว่ามันช่วยฉันติดตามว่าฉันรวมสาขาที่ไหน แต่เมื่อเร็ว ๆ นี้ฉันได้อ่านมากขึ้นเกี่ยวกับวิธีการทำงานของ Git และฉันก็ตระหนักว่าฉันสามารถใช้การผสานที่มุ่งมั่นในการอ้างถึงเมื่อฉันรวมสาขา ดังนั้นฉันควรทำอย่างไรเมื่อรวมฟีเจอร์บรานช์เข้ากับมาสเตอร์: ทำการผสานคอมมิชชันบนมาสเตอร์จากนั้นดันต้นน้ำหรือดันสาขาท้องถิ่นและเริ่มคำขอดึง? ฉันได้อ่านIntroducing Pull Requests สำหรับทีม 2 คนแล้วรวมคำขอของฉันเองหรือ และขั้นตอนการทำงานกับ 2 คนในโครงการคืออะไรและฉันควรจะเปิดคำขอดึงจากสาขาใน repo อย่างเป็นทางการหรือทางแยกของฉัน? แต่ดูเหมือนว่าไม่มีใครตอบคำถามที่ฉันต้องการ

12 git  github  merging  pull-requests 

ฉันเริ่มต้นกับ SVN และหลายแหล่งกล่าวว่าการรวมกันเป็นเรื่องยากมากใน SVN เมื่อเทียบกับเครื่องมือ DVCS คำถามล่าสุดที่ฉันสามารถหาที่นี่ใน SE มีจาก 2012 บางครั้งมีการกล่าวถึงเหตุผลที่ SVN ก่อนหน้า v1.5 ไม่มีข้อมูลเมตา แต่ SVN อยู่ในรุ่น 1.8.9 ในขณะนี้ ระบุว่า SVN นั้นเป็นผู้ใหญ่มากกว่า v1.5 และโดยเฉพาะอย่างยิ่งความจริงที่ว่าเราไม่ได้ใช้ SVN 1.5 ดังนั้นเราจึงไม่ต้องทนทุกข์ทรมานจากการขาดข้อมูลเมตาที่กล่าวถึง - ยังมีความถูกต้องมากในการโต้แย้งกับ SVN ฉันเข้าใจว่า DVCS มีวิธีที่แตกต่างอย่างสิ้นเชิงซึ่งมักเป็นที่ต้องการมากกว่า แต่สำหรับผู้ที่ "ต้อง" ues SVN ไม่ว่าด้วยเหตุผลใดก็ตามการรวมกันไม่ใช่ "นรก" จริง ๆ อีกแล้วใช่ไหม

11 version-control  svn  merging