คำถามติดแท็ก version-control

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

14 version-control  code-reviews  svn 

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

13 version-control  branching  configuration-management  merging 

บริษัท ของฉัน (เรียกพวกเขาว่า Acme Technology) มีห้องสมุดประมาณหนึ่งพันไฟล์ต้นฉบับซึ่งเดิมมาจากกลุ่มการวิจัยของ Acme Labs ซึ่งได้รับการบ่มเพาะในกลุ่มพัฒนาสองสามปีที่ผ่านมาและได้มอบให้กับลูกค้าภายใต้ ไม่เปิดเผย. แอคพร้อมที่จะเปิดตัวโค้ด 75% ให้กับชุมชนโอเพนซอร์ส อีก 25% จะเปิดตัวในภายหลัง แต่สำหรับตอนนี้ยังไม่พร้อมสำหรับการใช้งานของลูกค้าหรือมีรหัสที่เกี่ยวข้องกับนวัตกรรมในอนาคตที่พวกเขาต้องการให้พ้นจากคู่แข่ง ปัจจุบันรหัสนี้ได้รับการจัดรูปแบบด้วย #ifdefs ที่อนุญาตให้ใช้รหัสฐานเดียวกันเพื่อทำงานกับแพลตฟอร์มการผลิตล่วงหน้าที่จะมีให้สำหรับนักวิจัยมหาวิทยาลัยและลูกค้าเชิงพาณิชย์ในวงกว้างมากขึ้นเมื่อมันเปิดแหล่งที่มาขณะที่ในเวลาเดียวกัน พร้อมสำหรับการทดลองและการสร้างต้นแบบและการทดสอบความเข้ากันได้กับแพลตฟอร์มในอนาคต การรักษาฐานรหัสเดียวถือเป็นสิ่งจำเป็นสำหรับเศรษฐศาสตร์ (และความมีสติ) ของกลุ่มของฉันซึ่งจะมีช่วงเวลาที่ยากลำบากในการรักษาสำเนาสองชุดในแบบคู่ขนาน ไฟล์ในฐานปัจจุบันของเรามีลักษณะดังนี้: > // Copyright 2012 (C) Acme Technology, All Rights Reserved. > // Very large, often varied and restrictive copyright license in English and French, > …

13 open-source  licensing  version-control  parsing 

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

13 version-control  git  branching 

ที่ทำงานเราใช้ SVN แต่ในนามเท่านั้น เราไม่แยกหรือรวม เราเก็บที่เก็บสองชุดหนึ่งที่ทำหน้าที่เป็นสาขา "แท็ก" ที่ได้รับการคัดลอกเมื่อเราทำการปรับใช้และเก็บไว้เพื่อแก้ไขข้อผิดพลาดและทันทีคุณสมบัติประเภทนี้ "ต้องไปโดยเร็ว" เราต้องจำไว้ว่าให้คัดลอกการเปลี่ยนแปลงที่ทำในหนึ่งสำเนาไปยังอีกชุดหนึ่ง ("ลำตัว") เรามีโครงการโหลภายในโฟลเดอร์เดียวในพื้นที่เก็บข้อมูลแทนที่จะแยกพวกมันออก ในระยะสั้นเกี่ยวกับสิ่งเดียวที่เราใช้ SVN สำหรับคือความสามารถในการกระทำ ทุกอย่างอื่นทำด้วยตนเอง ฉันประเมิน Mercurial แล้ว ฉันเคยใช้ Git มาก่อน (ฉันเป็นคนเดียวในทีมที่ใช้ DVCS) และฉันก็หยิบ Mercurial ขึ้นมาอย่างรวดเร็ว ฉันกำลังถกเถียงกันว่าแนะนำ Mercurial ให้กับคนอื่น ๆ ในทีมว่าเป็น "วิธีที่ดีกว่า" ในการทำสิ่งต่าง ๆ เพราะการแตกแขนงเป็นเรื่องง่ายการรวมกันนั้นง่ายกว่ามากและเราสามารถกระทำสิ่งต่าง ๆ ในเนื้อหาหัวใจของเรา สาขาเมื่อพวกเขาพร้อม เราจะได้รับประโยชน์ทั้งหมดของ SVN (และเราไม่ได้รับประโยชน์มากมายตอนนี้เพราะไม่มีใครเข้าใจ SVN ได้จริง) รวมถึงคุณสมบัติใหม่ที่เราไม่จำเป็นต้องมีไฟล์ที่ไม่มีเวอร์ชันมากมายลอยอยู่ดังนั้นถ้าเราต้องย้อนกลับ เราเมาแล้ว เวิร์กโฟลว์นั้นดูเรียบง่ายขึ้นเราแค่ต้องจำไว้ว่า "Commit" นั้นเป็นของท้องถิ่นและ "Push" ก็เหมือนกับการกระทำของ …

13 version-control  svn  mercurial 

ฉันได้มีส่วนร่วมในการอภิปรายเมื่อเร็ว ๆ นี้เกี่ยวกับวิธีจัดการ refactoring โดยทั่วไป (ซึ่งเป็นหัวข้อที่น่าสนใจในตัวเอง) ในที่สุดคำถามต่อไปนี้เกิดขึ้น: หนึ่งจัดการข้อขัดแย้งผสานที่เกิดขึ้นเนื่องจากมีคนทำ refactoring ส่วนหนึ่งของรหัสในขณะที่คนอื่นกำลังทำงานในคุณสมบัติสำหรับรหัสชิ้นเดียวกันได้อย่างไร โดยพื้นฐานแล้วฉันไม่มีความคิดวิธีจัดการกับสิ่งนี้อย่างมีประสิทธิภาพ มีวิธีปฏิบัติที่ดีที่สุดที่ควรปฏิบัติตามในเรื่องนี้หรือไม่? มีความแตกต่างในวิธีการจัดการนี้สำหรับระบบที่มีรหัสดั้งเดิมมากมายหรือไม่?

13 version-control  refactoring  legacy 

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

13 project-management  version-control  development-process  documentation  builds 

รู้เบื้องต้นเกี่ยวกับสถานการณ์ของฉัน ฉันทำงานให้กับ บริษัท พัฒนาเว็บไซต์ขนาดเล็ก เรามีทีมนักพัฒนา ASP.NET สี่คนซึ่งรวมถึงฉันด้วย โครงการของเราเกือบทั้งหมด (> 98%) เป็นโครงการแบบคนเดียวที่ใช้เวลาดำเนินการประมาณ 1-4 สัปดาห์ เราไม่ได้ใช้การควบคุมแหล่งที่มาหรือรุ่น สิ่งเดียวที่เรามีคือโฟลเดอร์แชร์บนเซิร์ฟเวอร์ภายในที่มีแหล่งข้อมูลล่าสุด (== แหล่งที่มาของแอปพลิเคชั่นที่ใช้งานจริง) ของโครงการทั้งหมด ในโอกาสที่หายากที่เราจำเป็นต้องทำงานในโครงการเดียวกันที่มีมากกว่าหนึ่งคนเราใช้ ... นอกเหนือจากการเปรียบเทียบ นักพัฒนาหนึ่งหรือสองครั้งต่อวันถามพวกเขาว่าพวกเขามีรุ่นที่รวบรวมและจากนั้นพวกเขาประสานรหัสของพวกเขาโดยใช้การเปรียบเทียบ เมื่อมีคนเพียงสองคนกำลังทำงานในโครงการนี้ทำงานได้ "ค่อนข้างดี" แต่ทันทีที่นักพัฒนารายที่สามเข้าสู่กระบวนการก็จะกลายเป็นขยะที่ไม่สามารถจัดการได้ โดยเฉพาะอย่างยิ่งเมื่อทุกคนเริ่มทำการเปลี่ยนแปลงฐานข้อมูล ฉัน (และหนึ่งหรือสองของนักพัฒนาเพื่อนของฉัน) ได้บอกเจ้านายของฉันหลายครั้งแล้วว่าเราควรเริ่มใช้รูปแบบของแหล่งที่มาและการควบคุมเวอร์ชันเช่น Git, Mercurial หรือ TFS (หัวหน้าของเราเป็นคนที่มีใจรักของ Microsoft) น่าเสียดายที่เจ้านายของฉันไม่เห็นประโยชน์ของการเปลี่ยนไปใช้ระบบควบคุมแหล่งที่มาและเวอร์ชั่นเพราะในสายตาของเขาทุกอย่างทำงานได้ดีในตอนนี้และเขาไม่ต้องการลงทุนเวลาและเงินในการตั้งค่าระบบใหม่และทำให้แน่ใจว่าทุกคน รู้วิธีการใช้งาน แม้ว่าฉันจะอธิบายข้อดี (เช่นการทำงานร่วมกันที่ง่ายขึ้นแอปพลิเคชันรุ่นต่าง ๆ วิธีที่ปลอดภัยกว่าในการเปลี่ยนรหัส ... ) สำหรับเขาเขายังไม่คิดว่ามันเป็นสิ่งที่เราต้องการ ในบรรดานักพัฒนาทั้งสี่มีเพียงสองคนเท่านั้น (รวมถึงฉัน) ที่มีประสบการณ์กับการควบคุมแหล่งที่มา (Git) และประสบการณ์นั้นมีจำกัดมาก ฉันรู้วิธีโคลนที่เก็บ …

13 development-process  version-control  teamwork 

อะไรคือวิธีสำคัญในการทำให้ทีมของคุณมีส่วนร่วมในการใช้การควบคุมเวอร์ชันในระหว่างการพัฒนาการพัฒนาเว็บหรืออื่น ๆ ฉันปฏิเสธที่จะทำงานโดยปราศจากมันซึ่งหมายความว่าทุกคนที่เกี่ยวข้องในโครงการจะต้องใช้ด้วย มันเป็นแค่แนวปฏิบัติที่ดี GUIs เช่น Tower ได้ช่วย แต่แนวคิดของมันพบกับความโกรธ ('ไม่ใช่งานของฉัน!' ทัศนคติที่ดี) ความขี้ขลาดหรือตรงไปตรงมาไม่ได้ใช้ (ใช้ FTP แทนหลีกเลี่ยงการควบคุมเวอร์ชันสำหรับการพูด dev หรือการปรับใช้ ) แก้ไข: ฉันควรจะชี้แจงเล็กน้อยที่ฉันไม่ได้หมายถึงภาพ / PSDs

13 version-control  teamwork 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา เรากำลัง bootstrapping ทีมใหม่ที่มีขนาดเล็กมาก (พูด 2-5) คำถามของฉันคือ: การควบคุมเวอร์ชันประเภทใดเหมาะกับทีมประเภทนี้มากที่สุดทั้งแบบรวมศูนย์หรือกระจาย

13 version-control 

ปัจจุบัน บริษัท ของฉันมี Visual Studio solation ใน repo SVN ที่จัดเป็นดังนี้: SolutionFolder (~3.5 GB) |-> SolutionName.sln |-> .. Some source code folders... (~250 MB) |-> ThirdParty (~3 GB) |-> Tools | -> Tool1 | -> Tool2 Tool1 และ Tool2 เป็นบิลด์อิสระ (มีโซลูชันของตัวเอง) แต่สร้างไฟล์ปฏิบัติการที่ใช้ในบิลด์หลัก โฟลเดอร์ ThirdParty มีการขึ้นต่อกันทั้งหมดของโครงการรวมถึงไฟล์. lib ขนาด 100+ MB ที่รวบรวมไว้ล่วงหน้าและไลบรารี่ขนาดใหญ่เช่นบูสต์ มันสะดวกที่จะมีทุกอย่างใน …

13 version-control  git 

ขณะนี้เรามีระบบการสร้างที่ซับซ้อนและไม่มีประสิทธิภาพซึ่งประกอบด้วย repos SVN และ Git จำนวนมาก (ประมาณ 50% ต่อรายการ) รวมถึงระบบที่เป็น repod submitules git เรายังมีสคริปต์แบบโฮมเมดที่จัดการสิ่งต่าง ๆ ได้ไม่มากก็น้อย จุดสำคัญของโค้ดเบสของเรา (แหล่งปิด) คือมันมีการเชื่อมโยงอย่างแน่นหนาและทุกโครงการจะถูกปล่อยออกมาในเวลาเดียวกันภายใต้เวอร์ชันเดียวกัน เราต้องการย้ายข้อมูลนี้ไปยังระบบที่ง่ายขึ้นและ VCS เดียวและกำลังพิจารณาตัวเลือกหลายอย่างรวมถึง: git submodules, google Repo และ monorepos VCS ขั้นสุดท้ายยังไม่ได้กำหนด (ยกเว้นตัวเลือกที่มอบอำนาจให้) และอาจเป็น svn คอมไพล์หรือแม้แต่อย่างอื่นถ้ามันจะเหมาะกับสถานการณ์ของเราดีขึ้น เรากำลังพยายามแสดงรายการบวกและลบของแต่ละวิธีแก้ปัญหาและหนึ่งในปัญหาสำคัญที่เรามีในขณะนี้คือ monorepos ว่ามันดูไม่ง่ายหรือเป็นไปได้ที่จะแบ่งปันเพียงบางโมดูลให้กับหน่วยงานภายนอก เราต้องการให้คนเหล่านั้นสามารถชำระเงินและทำงานได้ตามปกติในโมดูลเหล่านั้น แต่ไม่สามารถเข้าถึงรหัสหรือประวัติส่วนที่เหลือของ repo มันไม่ใช่สิ่งที่เราทำบ่อยครั้งหรืออย่างกว้างขวางในขณะนี้ แต่เราอาจจะเกิดขึ้นในอนาคตและเราไม่ต้องการให้เรื่องนี้กลายเป็นฝันร้ายเพราะเราตัดสินใจไม่ดีที่นี่ ระบบการจัดการสิทธิ์พิเศษนั้นมีอยู่ในระบบ VCS หรือไม่? หรือมีวิธีใดที่จะบรรเทาปัญหานี้ได้บ้าง?

12 version-control  migration 

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

12 version-control 

โดยปกติเมื่อฉันเขียนโปรแกรมฉันมีงานที่ชัดเจนก่อนหน้าฉัน แต่พบสิ่งที่น่ารำคาญที่ฉันต้องการทำความสะอาดเมื่อฉันไป ที่นี่ฉันเห็นสามตัวเลือก: ทำในภายหลัง (อาจลืม / ต้องใช้เวลาในการเพิ่มตั๋ว) ทำทันทีและส่งมอบงานของฉันในปัจจุบัน (ไม่ชัดเจน) ทำทันทีและกระทำแยกต่างหาก (ต้องค้นหาอาจทำผิดพลาดและไปที่ตัวเลือก # 2 โดยไม่ได้ตั้งใจ) นี่อาจเป็นพื้นฐานค่อนข้าง แต่มีวิธีใดบ้างที่จะหลีกเลี่ยงสิ่งนี้โดยใช้ svn / git / other?

12 version-control  git  svn  workflows 

ปัญหา ฉันอยู่ในโครงการซอฟต์แวร์ที่มีนักพัฒนาประมาณ 10 คนเราแบ่งปันซอร์สโค้ดผ่าน Mercurial เรามีการพัฒนาและสาขาการผลิตต่อการเปิดตัว ซ้ำแล้วซ้ำอีกในระหว่างโครงการเรามีซอร์สโค้ดจากหนึ่งสาขาคือ v1 เข้าสู่ patch และบำรุงรักษาสาขาสำหรับซอฟต์แวร์รุ่นก่อนหน้าเช่น v2 ซึ่งส่งผลให้เวลาที่ใช้ในการสำรองการกระทำผิดหรือรหัส (อาจไม่ใช่ -QAd) การเข้าถึงและการปรับใช้ในสาขาที่ไม่ถูกต้องหากเราไม่สังเกตเห็นว่ารหัสผิดไป สาขาและผสานการออกแบบ / วิธีการของเรา v1-test v1-patch1 v1-patch2 ^---------^-----------^ v1-prod / / \ \ -----------------------/ \ \ v1-dev \ \ \ --------------------------\ v2-dev \ \ \ ^-------^------------- v2-prod v2-test v2-patch1 ดังนั้นเราจะทำงานในสาขาพัฒนาการเผยแพร่จนกว่าจะถือว่าพร้อมแล้วจึงทำการปิดสาขาสำหรับการทดสอบ / UAT / สาขาการผลิตเดียวซึ่งการเผยแพร่และการบำรุงรักษาทั้งหมดเสร็จสิ้นแล้ว แท็กใช้เพื่อสร้างรุ่นของสาขานี้ …

12 version-control  training  dvcs