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

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

19 version-control  git  github  etiquette 

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

19 version-control 

ฉันกำลังพัฒนาเว็บไซต์ใน php ใน localhost และเมื่อโมดูลของมันเสร็จสมบูรณ์ฉันอัพโหลดบนคลาวด์เพื่อให้เพื่อนของฉันสามารถทดสอบอัลฟา ขณะที่ฉันพัฒนาต่อไปฉันมีไฟล์มากมายและฉันก็ไม่ทราบว่าไฟล์ที่ฉันแก้ไขหรือเปลี่ยนแปลง ฯลฯ ฉันเคยได้ยินว่ามีบางสิ่งที่เป็น 'การควบคุมเวอร์ชัน' เพื่อจัดการไฟล์ทั้งหมด แต่ไม่แน่ใจว่ามันทำงานอย่างไร ดังนั้นคำถามของฉันคือ: มีวิธีที่ง่าย / บริการ / แอพพลิเคชั่นให้ฉันติดตามการแก้ไข / การเปลี่ยนแปลง / ไฟล์ใหม่ทั้งหมดและจัดการไฟล์เมื่อฉันพัฒนาเว็บไซต์หรือไม่ ทันทีที่ฉันทำโมดูลฉันต้องการอัปโหลดบนคลาวด์ (ฉันใช้ Amazon Cloud Service) หากมีสิ่งใดเกิดขึ้นกับไฟล์ใหม่ฉันอาจต้องการกลับไปใช้ไฟล์เก่า และบางทีในหนึ่งหรือสองคลิกฉันจะได้เห็นไฟล์ที่ฉันแก้ไขหรือเปลี่ยนแปลงตั้งแต่ไฟล์ล่าสุดที่ฉันอัปโหลด?

19 version-control 

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

19 version-control  dvcs 

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

19 bug  version-control 

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

19 version-control 

ฉันต้องการคำแนะนำเกี่ยวกับวิธีการจัดโครงสร้างโครงการของเราใน Git เราใช้ Java และ Maven เป็นเครื่องมือสร้างของเรา Maven kinda ถือว่าโครงการทั้งหมดของคุณมีบรรพบุรุษร่วมกันในที่สุด Maven ยังสามารถเป็นราชินีละครจริงเมื่อสิ่งที่ไม่ติดตั้งตรงทาง Apache ชุดมูลนิธิโครงการของพวกเขา (ทุกคนที่ใช้ปล่อยปลั๊กอินอาจจะรู้ว่าสิ่งที่ผมพูดถึง) เราต้องการ pom พาเรนต์ระดับบนสุดที่ควบคุมเวอร์ชันของปลั๊กอินและสร้างการกำหนดค่า (การกำหนดค่า repo สิ่งที่จะสร้างการตั้งชื่ออนุสัญญารุ่นของปลั๊กอิน ฯลฯ ) Maven ต้องการให้โครงการไอทีทั้งหมดของเราอยู่ในโฟลเดอร์ย่อยของโครงการหลักนั้น นี่หมายถึง repo Git ขนาดใหญ่หนึ่งรายการสำหรับองค์กร สิ่งนี้จะทำให้สภาพแวดล้อมที่มีเสียงดังมาก หากมีสองทีมที่ทำงานในโครงการที่ไม่เกี่ยวข้องพวกเขาจะต้องดึงการรวมตัวของทีมอื่นอย่างต่อเนื่อง ฉันอยากได้ repo หนึ่งต่อโครงการ แต่การปะทะแบบนั้นกับโมเดลลำดับขั้นสุดยอดของ Maven ซึ่งต้องการโครงการย่อยเป็นโฟลเดอร์ย่อย ฉันต้องการคำแนะนำเกี่ยวกับวิธีที่ผู้คนคืนดีแบบจำลองทั้งสองนี้ ... ขอบคุณ!

19 java  version-control  git  maven 

ผู้จัดการของเรากำลังติดตามความมุ่งมั่นของGitในทุกโครงการของเรา ปกติแล้วนี่ไม่ใช่ปัญหาและฉันชอบความจริงที่ว่าการควบคุมเวอร์ชันให้บันทึกการทำงานทั้งหมดที่เกิดขึ้นโดยเฉพาะอย่างยิ่งสำหรับการตรวจสอบและวิเคราะห์ในภายหลัง (ในกรณีที่มีอะไรผิดพลาด) อย่างไรก็ตามผู้จัดการได้แสดงความคิดเห็นเล็กน้อยเพื่อถามว่าผู้คนทำงานอะไรเมื่อเขาเห็นการกระทำที่อ่าน "การแก้ไขสไตล์" หรือข้อความการกระทำใด ๆ ที่ไม่ได้อ้างอิงหมายเลขตั๋วในระบบการจัดการงานของเรา มีวิธีแก้ปัญหาทางสังคมหรือทางเทคนิคหรือไม่? ข้อมูลเพิ่มเติม: นี่คือโครงการบำรุงรักษาดังนั้นจึงมีกลุ่มของ "ต้องทำ A แล้ว B แล้ว C และจากนั้น D และในที่สุดก็ต้องใช้ X" งานที่เกิดขึ้น ข้อมูลเพิ่มเติม: ข้อความการส่งข้อความพิเศษที่ยกธงกับผู้จัดการนั้นอยู่ใกล้กับ "รวมวิธีที่ดีกว่าในการ X, Y และ Z" ซึ่งเป็นข้อความการปรับโครงสร้างมากกว่าการแก้ไขโวหารง่าย ๆ

18 version-control  management 

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

18 open-source  version-control  git  refactoring  branching 

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

18 dvcs  version-control 

หากคุณกำลังทำโครงการเดี่ยว - คุณจะใช้เครื่องมือ CI เพื่อสร้างจากพื้นที่เก็บข้อมูลหรือไม่? ฉันใช้ Hudson และ Cruise Control ในสภาพแวดล้อมแบบทีมซึ่งเป็นสิ่งสำคัญในการสร้างทันทีที่ทุกคนตรวจสอบสิ่งใด ฉันคิดว่าคุณค่าของการควบคุมเวอร์ชันยังคงชัดเจน แต่ฉันต้องสร้างหลังจากคอมมิชชันทุกครั้งเพราะฉันเพิ่งจะสร้างบนเครื่องของฉันและไม่มีใครทำอะไร

18 version-control  continuous-integration  builds  solo-development 

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

17 version-control  code-reviews  release-management 

ฉันเป็นผู้รับเหมาที่เพิ่งเริ่มต้นกับ บริษัท ทีมคือนักพัฒนา 3 คนซึ่งประกอบด้วยผู้พัฒนา 2 คนถึงระดับกลางและอีกคนในระดับเดียวกันเริ่มเร็ว ๆ นี้และตัวฉันเอง (6 ปี xp) สำหรับนักพัฒนาทั้งสองที่มีอยู่มันเป็นงานแรกของพวกเขาที่ออกจากมหาวิทยาลัย / วิทยาลัยและพวกเขาไม่เคยมีนักพัฒนาอาวุโสที่ดูแลงานของพวกเขามาก่อน ไม่มีนโยบายการควบคุมเวอร์ชันที่ชัดเจน นักพัฒนาทำการพัฒนาทั้งหมดบนลำตัวแล้วนำไปใช้กับการผลิตโดยตรงจากเครื่องพัฒนาของพวกเขา ทีมที่มีอยู่ไม่คุ้นเคยกับการแตกแขนง ฉันกำลังเปลี่ยนแปลงทั้งหมดนี้และแนะนำเซิร์ฟเวอร์ CI, การทดสอบ TDD / การจัดเตรียม / การผลิต ฯลฯ พร้อมกับนโยบายการควบคุมเวอร์ชันเพื่อชมเชยสิ่งนี้ ระบบควบคุมแหล่งที่มาคือ TFS ซึ่งฉันไม่เคยใช้มาก่อน มันถูกกำหนดค่าให้เป็นแหล่งเก็บข้อมูลขนาดยักษ์ ฉันได้เขียนพอยน์เตอร์ให้กับพวกเขาแล้ว แต่มีอะไรอีกบ้างที่ฉันควรเพิ่ม / แก้ไขโดยคำนึงถึงประสบการณ์ของทีม นโยบายการควบคุมเวอร์ชัน การพัฒนาจะทำบนลำต้น หากการเปลี่ยนแปลงคาดว่าจะใช้เวลานานกว่าหนึ่งสัปดาห์ก็ควรจะทำในสาขาที่มีการผสานปกติจากลำตัวเข้าไปในสาขาเพื่อหยุดทั้งสองออกจากซิงค์ สร้างสาขาย่อยสำหรับรหัสการผลิต สาขานั้นควรมีรหัสที่มั่นคงเท่านั้น เราสามารถมีสาขาย่อยหนึ่งสาขาที่ได้รับการอัพเดตจากลำตัวหนึ่งครั้งต่อการวิ่งหรือเราสามารถสร้างสาขาย่อยแยกต่างหากสำหรับแต่ละสัปดาห์ หากจำเป็นต้องแก้ไขข้อบกพร่องเร่งด่วนที่มีผลกระทบต่อรหัสการผลิตรหัสนั้นจะถูกสร้างขึ้นในสาขาที่วางจำหน่ายและผสานกลับเข้าไปในลำต้น หากเรานำกลยุทธ์การเปิดตัวสาขาหนึ่งมาใช้ลำต้นจะถูกรวมเข้ากับสาขาที่วางจำหน่ายหนึ่งครั้งต่อการวิ่งไปยังจุดสิ้นสุดของการวิ่ง ถ้าเราใช้สาขาแยกต่อกลยุทธ์การปล่อยแล้วลำตัวไม่เคยถูกรวมเข้ากับสาขาการปล่อย ในบางสถานการณ์อาจจำเป็นต้องทำการแก้ไขข้อบกพร่องสองครั้งในสาขาที่แตกต่างกันหากสาขาแยกกันมากเกินไป หากเรากำลังวิ่งสั้น ๆ สิ่งนี้ไม่ควรเกิดขึ้นบ่อยเกินไป ฉันวางแผนที่จะมีสามเซิร์ฟเวอร์ …

17 version-control  development-process  team-foundation-server 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ไม่กี่เดือนที่ผ่านมาฉันขุดลงในการโค่นล้มและ GIT และรู้สึกผิดหวัง พวกเขาจัดการ SOURCE CODE ได้ดี แต่ไม่ใช่ด้านอื่น ๆ ตัวอย่างเช่นเว็บไซต์ภายใต้การควบคุมเวอร์ชันจำเป็นต้องจัดการการเป็นเจ้าของไฟล์ / ไดเรกทอรีการเข้าถึงการอ่านและเขียนไฟล์ / ไดเรกทอรีรายการควบคุมการเข้าถึงการประทับเวลาเนื้อหาฐานข้อมูล และลิงก์ภายนอก มีระบบควบคุมเวอร์ชันที่สามารถทำการพลิกกลับได้อย่างสมบูรณ์แบบเมื่อทำการโหลดจากการสำรองข้อมูลรายเดือนหรือไม่?

17 version-control  git  svn  backups  revisions 

การควบคุมเวอร์ชันสำหรับโปรแกรม ladder logic (LL) สำหรับตัวควบคุมตรรกะที่ตั้งโปรแกรมได้ (PLC) ดูเหมือนจะไม่มีอยู่จริง อาจเป็นเพราะ LL เป็นภาษาภาพและมีแนวโน้มที่จะถูกเก็บไว้ในไฟล์ไบนารีหรืออาจเป็นเพราะการควบคุมซอร์สโค้ดไม่ได้ "ติดอยู่" ในวงการวิศวกรรมการควบคุมกระบวนการ - หรือบางที Google-Fu ของฉันอ่อนแอในคืนนี้ คุณรู้วิธีแก้ปัญหาที่เป็นจริงและมีประโยชน์สำหรับการควบคุมเวอร์ชันสำหรับระบบดังกล่าวหรือไม่? คำนิยาม: realistic = การเปลี่ยนแปลงโปรแกรมถูกติดตามโดยผู้ใช้และอาจมีการพลิกกลับและการรวม มีประโยชน์ = ระบบทำงานร่วมกับนักออกแบบ LL ที่มองเห็นได้ไม่ จำกัด LL จากผู้ผลิต PLC รายเดียวและไม่เสียค่าใช้จ่ายเป็นจำนวนเงินที่ไร้สาระ? หมายเหตุ: ฉันเคยได้ยินคนที่ใช้ SVN หรือ Mercurial et al เพื่อติดตามไฟล์ไบนารี แต่ฉันไม่คิดว่าความสามารถ diff / merge จะแสดงความแตกต่างที่สามารถอ่านได้ ภาคผนวก: ตอนแรกเราต้องสนับสนุน PLC ของ Allen-Bradley เท่านั้น …

17 version-control