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

ฉันกำลังพยายามเลือกเวิร์กโฟลว์ Git ที่เหมาะสมที่สุดสำหรับผลิตภัณฑ์ของเรา นี่คือพารามิเตอร์: เรามีการเปิดตัวรุ่นใหญ่สองสามครั้งต่อปีสมมติว่ามากที่สุด 10 รายการ เรามีผลิตภัณฑ์หลายเวอร์ชันที่ใช้งานอยู่ในเวลาเดียวกัน (บางคนอยู่ใน v10.1, บางคนใน v11.2 ฯลฯ ) เราต้องสามารถทำงานกับหลาย ๆ รุ่นได้ในเวลาเดียวกัน (ดังนั้นเราจึงสามารถทำงานกับ v12.1 ได้ แต่เมื่อเราถึงจุดสิ้นสุดของการวางจำหน่ายเราจะเริ่มทำงานกับ v12.2 ในเวลาเดียวกัน) เราจำเป็นต้องสามารถเผยแพร่โปรแกรมแก้ไขด่วนเมื่อพบข้อบกพร่องที่สำคัญ จนถึงตอนนี้เป็นวิธีที่ฉันคิดว่าสามารถใช้งานได้: ใช้ repo ระยะไกลเดียว สร้างสาขา 12.1 จากต้นแบบ สร้างฟีเจอร์ย่อยตาม 12.1, คอมมิชชันเหล่านั้นและรวมกลับเป็น 12.1, กด เมื่อเราต้องการเริ่มทำงานในรุ่นอนาคตให้สร้างสาขาใหม่ 12.2 จาก 12.1 จากนั้นเมื่อทำงานกับคุณลักษณะสำหรับ 12.1 สร้างสาขาจาก 12.1 กระทำการเปลี่ยนแปลงและรวมเข้ากับทั้ง 12.1 และ 12.2 กด หากทำงานกับคุณลักษณะสำหรับ …

30 version-control  git 

ฉันอยากรู้ว่ามันเหมาะสมหรือไม่ที่จะแบ่งโครงการที่ฉันทำงานในที่เก็บสองแห่งแทนที่จะเป็นหนึ่งโครงการ จากสิ่งที่ฉันสามารถพูดได้: ส่วนหน้าจะถูกเขียนเป็น html + js แบ็กเอนด์ใน. net แบ็กเอนด์ไม่ได้ขึ้นอยู่กับส่วนหน้าและส่วนหน้าไม่ได้ขึ้นอยู่กับส่วนแบ็คเอนด์ ส่วนหน้าจะใช้ API พักผ่อนหย่อนใจดำเนินการในแบ็กเอนด์ ส่วนหน้าสามารถโฮสต์บนเซิร์ฟเวอร์ HTTP ใด ๆ คงที่ ณ ตอนนี้ที่เก็บมีโครงสร้างนี้: ราก: ส่วนหน้า / * แบ็กเอนด์ / * ฉันคิดว่ามันเป็นความผิดพลาดที่ทำให้โครงการทั้งสองอยู่ในที่เก็บเดียวกัน เนื่องจากโปรเจ็กต์ทั้งสองไม่มีการขึ้นต่อกันระหว่างกันดังนั้นจึงควรอยู่ในที่เก็บแต่ละรายการและหากจำเป็นต้องมีที่เก็บพาเรนต์ที่มีซับโดเลชัน ฉันได้รับแจ้งว่าไม่มีประโยชน์และเราจะไม่ได้รับประโยชน์ใด ๆ จากการทำเช่นนั้น นี่คือข้อโต้แย้งของฉัน: เรามีสองโมดูลที่ไม่ได้พึ่งพากัน การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา) ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีคนกดไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า) นักพัฒนาซอฟต์แวร์หนึ่งรายอาจใช้งานได้เฉพาะในแบ็กเอนด์ แต่จะต้องดึงส่วนหน้าหรือวิธีอื่น ๆ เสมอ ในระยะยาวเมื่อถึงเวลาต้องปรับใช้ ในบางวิธีส่วนหน้าสามารถปรับใช้กับเซิร์ฟเวอร์แบบคงที่หลายตัวในขณะที่มีเซิร์ฟเวอร์ส่วนหลังหนึ่งตัว ในทุกกรณีผู้คนจะถูกบังคับให้โคลนทั้งแบ็กเอนด์ด้วยหรือเพื่อให้สคริปต์ที่กำหนดเองเพื่อผลักดันให้เซิร์ฟเวอร์ทั้งหมดส่วนหน้าเท่านั้นหรือเพื่อลบแบ็กเอนด์ ง่ายกว่าเพียงแค่กด / ดึงเฉพาะส่วนหน้าหรือส่วนหลังกว่าทั้งสองอย่างหากจำเป็นต้องใช้เพียงส่วนเดียว …

30 project-management  version-control  git  mercurial  organization 

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

30 productivity  version-control  solo-development 

เมื่อพัฒนาสำหรับอุปกรณ์ฝังตัวและโลกแปลก ๆ อื่น ๆ เป็นไปได้มากว่ากระบวนการสร้างของคุณจะมีไบนารีที่เป็นกรรมสิทธิ์จำนวนมากโดยใช้เวอร์ชันที่เฉพาะเจาะจงมาก ดังนั้นคำถามคือพวกเขาเป็นส่วนหนึ่งของการควบคุมแหล่งที่มาของคุณ? สำนักงานของฉันดำเนินการโดยกฎของ "การตรวจสอบจากการควบคุมแหล่งรวมทุกสิ่งที่คุณต้องการในการรวบรวมรหัส" และสิ่งนี้นำไปสู่ข้อโต้แย้งที่ร้ายแรงบางอย่าง ข้อโต้แย้งหลักที่ผมเห็นกับนี้จะท้องอืด DB ควบคุมแหล่งที่มาของการขาดการ diffing ไฟล์ไบนารี ( ดูคำถามก่อนในเรื่อง) สิ่งนี้ขัดต่อความสามารถในการตรวจสอบสร้างรู้ว่าคุณมีสภาพแวดล้อมที่แม่นยำซึ่งนักพัฒนาก่อนหน้าตั้งใจและไม่ต้องตามล่าหาไฟล์ที่เหมาะสม (ด้วยรุ่นที่เฉพาะไม่น้อยกว่า!)

30 version-control  workflows 

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

30 version-control 

เราพัฒนาผลิตภัณฑ์ (ต้นแบบ) P_OLD ในภาษา X และตอนนี้เรากำลังเขียนมันใหม่ตั้งแต่ต้นเป็น P_NEW ในภาษา Y เนื่องจาก P_NEW และ P_OLD เป็นผลิตภัณฑ์เดียวกัน: P_NEW ควรเป็นเพียง brach ของ P_OLD เก่าหรือควรเป็นที่เก็บของมันเอง? เป็นวิธีปกติในการจัดการการเปลี่ยนแปลงครั้งใหญ่ในมุมมองการควบคุมเวอร์ชันอะไร

29 version-control  git  rewrite 

นี่คือตัวอย่างของรหัสชั่วคราว / ท้องถิ่น มันเป็นสิ่งจำเป็นในการทำงานกับ codebase แต่จะเป็นอันตรายต่อการเป็นส่วนหนึ่งของมัน: ไฟล์โครงการ อาจจำเป็นต้องแก้ไขพา ธ เพื่อให้แสดงเลย์เอาต์บนพีซีปัจจุบัน makefiles ตัวอย่างเช่นการปรับให้เหมาะสมอาจต้องปิดในระหว่างการดีบัก แต่ไม่ใช่สำหรับเซิร์ฟเวอร์ CI แฮ็กสกปรกน่าเกลียด ตัวอย่างเช่นreturn 7ในช่วงกลางของฟังก์ชั่นเพื่อทดสอบบางสิ่งบางอย่างขึ้นอยู่กับฟังก์ชั่นและสงสัยว่าจะทำลายที่ 7 หรือ 7 เป็นรหัสของปุ่มยังไม่ได้ใช้ที่ฉันกำลังใช้และต้องทดสอบตลอด ชีวิตของสาขาของฉัน ฉันได้พยายามรักษาผู้ที่อยู่ในคอมไพล์กระทำที่ฉันมักจะ rebase ไปด้านบนก่อนที่จะผลักดันไป repo HEAD~และผลักดันแล้ว สิ่งนี้ค่อนข้างไม่สะดวกและไม่สามารถทำงานกับ svn ได้ Stashing ทำให้ฉันกลัวยิ่งขึ้น - "ฉันจำได้หรือไม่ว่าฉันจะโผล่ขึ้นมาหลังจากกด?" การทำให้โค้ดไม่อยู่ในการควบคุมเวอร์ชันจะทำให้เกิดเสียงที่ไม่พึงประสงค์ทุกครั้งที่มีการคอมมิชชันและอาจมีการนำไปใช้ในตอนเย็นวันศุกร์โดยไม่ตั้งใจ อะไรจะเป็นทางออกที่มีสติสำหรับรหัสการโยนทิ้งเช่น?

29 version-control 

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

29 version-control  productivity  code-reviews 

ฉันสงสัยว่าฉันกำลังมุ่งเน้นไปที่ปัญหาที่ไม่ถูกต้องดังนั้นฉันจะอธิบายสิ่งที่ฉันคิดว่าเป็นปัญหาก่อนที่จะนำเสนอวิธีการแก้ปัญหาที่อาจเป็นผลเสียน้อยที่สุดที่ฉันจินตนาการ สถานการณ์ปัจจุบัน: ใน ปัจจุบันเพื่อนร่วมงานของฉันยอมรับการเปลี่ยนแปลงรหัสของพวกเขาหลังจากช่วงเวลา loooong เป็นระยะเวลานานโดยมีการเปลี่ยนแปลงกระจายไปทั่วทั้งโครงการ นั่นเป็นความคืบหน้าฉันเดาเพราะไม่นานมานี้พวกเขาเพิ่งวางไฟล์. zip ไว้ในเครือข่าย ยังคงการรวมกันเป็นฝันร้าย - และตรงไปตรงมาที่ฉันมีเพียงพอ และฉันก็เบื่อที่จะพูดคุยและอธิบายและขอร้องด้วย สิ่งนี้ต้องหยุด - ถ้าไม่มีฉันก็จะเป็น "คนเลว" ตลอดเวลา ทางออกของฉัน: เนื่องจากดูเหมือนว่าจะไม่รับรู้และ / หรือไม่มีความสนใจในปัญหาและฉันไม่สามารถคาดหวังความพยายามใด ๆ ที่จะใช้เวลานานกว่าสองสามวัน ... หยุดงานชั่วคราว, ชั่วโมง, ฉันต้องการเซิร์ฟเวอร์โค่นล้ม ซึ่งจู้จี้ คำถามของฉัน: ฉันไปทางฐานที่นี่หรือฉันกำลังดูปัญหาที่ผิด? ดูเหมือนว่าฉันขาดอะไรบางอย่างไปและฉันคิดว่าฉันกำลังถามสิ่งที่ผิดโดยดูที่เครื่องมือในการแก้ปัญหาของฉัน ฉันควรจะมองหาเครื่องมือในการแก้ปัญหานี้หรือฉันควรทำอย่างไรเพื่อแก้ไขปัญหานี้

28 version-control  teamwork  svn 

ฉันเพิ่งเจอห้องสมุด Python ใน GitHub ไลบรารี่นั้นยอดเยี่ยม แต่มีการพิมพ์ผิดที่หนึ่งในชื่อฟังก์ชั่น ขอเรียกว่าในขณะที่มันควรจะเป็นdummy_fuction() dummy_function()ฟังก์ชั่นนี้ "แน่นอน" และมักใช้ในระบบฝังตัว สิ่งแรกที่ควรคำนึงถึงคือการเพิ่มรุ่นที่สองของฟังก์ชั่นที่มีชื่อที่ถูกต้องและเพิ่มคำเตือนการเลิกใช้ในรุ่นแรกสำหรับรุ่นถัดไป คำถามสามข้อ: แนวทางข้างต้นอาจมีผลที่ไม่ตั้งใจหรือไม่? มีวิธีการมาตรฐานในการแก้ไขปัญหานี้หรือไม่? ควรมีคำเตือนใด ๆ เกี่ยวกับการคัดค้านทิ้งไว้นานเท่าใด

28 python  version-control  coding-standards  deprecation 

จากการเปิดเผยเมื่อเร็ว ๆ นี้เกี่ยวกับการตรวจสอบข้อมูลที่จัดเก็บโดยผู้ให้บริการออนไลน์ของรัฐบาลอย่างกว้างขวาง บริการ zero-knowledge คือบริการที่เก็บข้อมูลทั้งหมดที่เข้ารหัสด้วยคีย์ที่ไม่ได้จัดเก็บไว้บนเซิร์ฟเวอร์ การเข้ารหัสและถอดรหัสเกิดขึ้นที่ฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ไม่เคยเห็นข้อมูลธรรมดาหรือกุญแจ เป็นผลให้ผู้ให้บริการไม่สามารถถอดรหัสและให้ข้อมูลกับบุคคลที่สามได้แม้ว่าจะต้องการ เพื่อให้ตัวอย่าง: SpiderOakสามารถดูเป็น Dropbox เวอร์ชันที่ไม่มีความรู้ ในฐานะโปรแกรมเมอร์เราวางใจอย่างมากและไว้วางใจข้อมูลที่ละเอียดอ่อนที่สุดของเรา - รหัสของเรา - สำหรับผู้ให้บริการออนไลน์ในระดับหนึ่ง ๆ : ผู้ให้บริการโฮสติ้งรหัส (เช่น Bitbucket, Assembla และอื่น ๆ ) แน่นอนว่าฉันกำลังพูดถึงที่เก็บส่วนตัวที่นี่ - แนวคิดของศูนย์ความรู้ไม่มีประโยชน์สำหรับที่เก็บสาธารณะ คำถามของฉันคือ: มีอุปสรรคทางเทคโนโลยีใด ๆ ในการสร้างบริการโฮสติ้งโค้ดที่ไม่มีความรู้หรือไม่ ตัวอย่างเช่นมีบางอย่างเกี่ยวกับโปรโตคอลเครือข่ายที่ใช้โดยระบบควบคุมเวอร์ชันยอดนิยมเช่น SVN, Mercurial หรือ Git ที่จะทำให้มันยาก (หรือเป็นไปไม่ได้) ในการนำรูปแบบการสื่อสารข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์มาเข้ารหัสด้วย กุญแจสำคัญที่เซิร์ฟเวอร์ไม่รู้ วันนี้มีบริการโฮสติ้งโค้ดที่ไม่มีความรู้หรือไม่?

28 version-control  encryption  project-hosting  privacy 

ความระมัดระวังมักเพียงพอที่จะป้องกันปัญหา แต่บางครั้งฉันต้องตรวจสอบสาขาที่ฉันกำลังทำงานอยู่ ( เช่น "อืม ... ฉันอยู่ในdevสาขาใช่มั้ย") โดยการตรวจสอบเส้นทางการควบคุมของแหล่งสุ่ม ไฟล์. ในการมองหาวิธีที่ง่ายขึ้นฉันคิดว่าตั้งชื่อไฟล์โซลูชันตามนั้น ( เช่น MySolution_Dev.sln ) แต่ด้วยชื่อไฟล์ที่แตกต่างกันในแต่ละสาขาฉันไม่สามารถรวมไฟล์โซลูชันได้ มันไม่ได้เป็นเรื่องใหญ่ แต่มีวิธีการหรือ "เคล็ดลับเล็ก ๆ " ที่คุณใช้เพื่อให้แน่ใจว่าคุณอยู่ในสาขาที่ถูกต้องหรือไม่? ฉันใช้ Visual Studio 2010 กับ TFS 2008

27 version-control  visual-studio  team-foundation-server  branching 

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

27 version-control 

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

27 version-control  git  branching 

ฉันค้นหาและไม่สามารถหาเหตุผลทางธุรกิจใด ๆ ได้ว่าทำไมระบบ git / mercurial / bazzr จึงดีกว่าระบบรวมศูนย์ (การโค่นล้มการบังคับใช้) ถ้าคุณกำลังพยายามที่จะขาย DVCS ไปยังบุคคลที่ไม่ใช่ทางด้านเทคนิคสิ่งที่ข้อโต้แย้งที่คุณจะจัดให้มีการ DVCS กำไรที่เพิ่มขึ้น ฉันจะขว้างคอมไพล์ให้กับผู้จัดการของฉันในไม่ช้ามันจะใช้เวลาสักครู่ในการแปลงคลังเก็บโค่นล้มและค่าใช้จ่ายในการซื้อใบอนุญาต smartgit แก้ไขฉันพยายามทำให้คำถามนี้เป็นการสนทนาทั่วไปเกี่ยวกับการรวมศูนย์และการกระจายอำนาจ แต่ก็หลีกเลี่ยงไม่ได้ที่จะกลายเป็นการโค่นล้มของ Git vs แน่นอนว่ามีระบบรวมศูนย์ที่ดีกว่าการโค่นล้ม

26 version-control  mercurial  dvcs  svn  git