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

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

117 version-control  branching  solo-development 

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

115 version-control  issue-tracking 

ฉันได้ยินเกี่ยวกับ บริษัท ใหญ่ ๆ บางแห่งเช่น Google และ Facebook ใช้ Perforce มีเหตุผลใดบ้างที่ SVN / Git ไม่สามารถแทนที่ Perforce ได้?

113 version-control 

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

100 version-control  development-process  scm  cowboy-coding 

ในระหว่างการประชุมเกี่ยวกับการย้อนกลับของ SDK ของบุคคลที่สามจากรุ่นล่าสุดมีการบันทึกไว้ว่านักพัฒนาของเราตั้งค่าสถานะไว้แล้วในประวัติการส่งมอบที่ไม่ควรใช้เวอร์ชันล่าสุด นักพัฒนาบางคนแย้งว่านี่เป็นวิธีปฏิบัติที่ไม่ดีและควรมีการบันทึกไว้ในไฟล์ต้นฉบับ (เช่น// Don't upgrade SDK Version x.y.z, see ticket 1234) หรือในREADMEไฟล์ระดับโครงการแทน คนอื่นแย้งว่าเนื่องจากประวัติการกระทำเป็นส่วนหนึ่งของเอกสารโครงการจึงเป็นที่ยอมรับสำหรับข้อมูลดังกล่าวเนื่องจากเราทุกคนควรอ่านมันต่อไป ควรใช้ประวัติการส่งข้อมูลเพื่อส่งข้อมูลสำคัญไปยังผู้พัฒนารายอื่นหรือควรทำซ้ำข้อมูลดังกล่าวไปยังตำแหน่งอื่นเช่นโครงการREADMEหรือความคิดเห็นในไฟล์ต้นฉบับที่เกี่ยวข้อง?

94 version-control  documentation 

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

84 tools  version-control  git  svn 

ฉันสงสัยอยู่เสมอว่าทำไม git ชอบแฮชมากกว่าหมายเลขการแก้ไข หมายเลขการแก้ไขมีความชัดเจนและง่ายต่อการอ้างถึง (ในความคิดของฉัน): มีความแตกต่างระหว่างการบอกใครสักคนให้ดูการแก้ไข 1200 หรือกระทำ 92ba93e! (เพียงยกตัวอย่างหนึ่ง) ดังนั้นมีเหตุผลสำหรับการออกแบบนี้หรือไม่?

80 version-control  git 

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

78 version-control  comments 

ฉันรู้สึกว่าระบบควบคุมเวอร์ชันขจัดความจำเป็นที่จะต้อง "บันทึกการเปลี่ยนแปลง" ถูกฉาบทุกที่ในรหัส ฉันมักจะเห็นการใช้งานอย่างต่อเนื่องของบันทึกการเปลี่ยนแปลงรวมถึงบล็อกยาวขนาดใหญ่ที่จุดเริ่มต้นของขั้นตอนการจัดเก็บที่มีส่วนใหญ่ถูกบล็อกออกสำหรับการเปลี่ยนแปลงในไฟล์และทิ้งรหัสด้วยสิ่งต่าง ๆ เช่น: // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 และ: // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> เหตุผลสำหรับสิ่งนี้ตามที่อธิบายให้ฉันคือการใช้เวลานานเกินไปในการตรวจสอบบันทึก VCS ของเราพยายามค้นหาว่าใครเปลี่ยนอะไรและเพราะอะไรในขณะที่เก็บไว้ในไฟล์รหัสตัวเองไม่ว่าจะอยู่ด้านบนสุดหรือใกล้เคียง การเปลี่ยนแปลงทำให้ง่ายต่อการดูว่าใครเปลี่ยนอะไรและเมื่อไหร่ ในขณะที่ฉันเห็นประเด็นนั้นดูเหมือนว่าจะซ้ำซ้อนและเป็นเพียงแค่ของเล็ก ๆ น้อย ๆ "เอ๋เราไม่เข้าใจวิธีการใช้ VCS ของเราอย่างถูกต้องดังนั้นเราจะไม่สนใจสิ่งนั้นเลย" คุณคิดอย่างไร? คุณใช้ทั้งความคิดเห็นและบันทึกหรือไม่ แค่บันทึก คุณพบว่าการโค้ดง่ายขึ้นเมื่อคุณเห็นโค้ดบล็อกข้างต้นที่ John Smith …

75 version-control  coding-standards  maintenance 

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

73 version-control  experience 

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

69 version-control  code-quality 

ฉันคิดว่านี่เป็นสถานการณ์ทั่วไป: ฉันทดสอบบางรหัสค้นหาข้อผิดพลาดแก้ไขและยอมรับข้อผิดพลาดแก้ไขไปยังที่เก็บ สมมติว่ามีหลายคนที่ทำงานในโครงการนี้ฉันควรสร้างรายงานข้อผิดพลาดก่อนกำหนดให้กับตัวเองและอ้างถึงในข้อความกระทำ (เช่น "แก้ไขข้อผิดพลาด # XYZ ข้อผิดพลาดเกิดจาก X และ Y. แก้ไขโดย Q และ R ")? อีกทางหนึ่งฉันสามารถข้ามรายงานข้อผิดพลาดและส่งข้อความเช่น "แก้ไขข้อผิดพลาดที่ทำให้เกิด A เมื่อ B ข้อผิดพลาดเกิดจาก X และ Y. แก้ไขโดย Q และ R" การปฏิบัติที่ดีกว่าคืออะไร?

68 project-management  version-control  issue-tracking 

ผมอยากจะรู้ว่า ในโครงการ C # หรือ VB.NET เราควรรวมโฟลเดอร์ PACKAGE (โฟลเดอร์แพคเกจ nugget ที่สร้างขึ้นเพื่อรูทของโครงการของฉันที่มีไฟล์ nupkg และเนื้อหาอื่น ๆ ) ไปยังแหล่งเก็บข้อมูลแหล่งควบคุม (Git เป็นต้น)

68 c#  version-control  git  vb.net 

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

68 git  version-control  project-management 

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

68 version-control  git  dvcs  merging