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

วินัยการเขียนโปรแกรมสำหรับการติดตามการจัดเก็บและการเรียกคืนการแก้ไขของรหัสที่มา

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

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

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

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

16
เป็นความคิดที่ดีที่จะใส่หมายเลขข้อผิดพลาดในการแสดงความคิดเห็นในจุดเริ่มต้นของไฟล์ต้นฉบับ? [ปิด]
มันเป็นการดีหรือไม่ที่จะใส่หมายเลขบั๊กในไฟล์ลงในความคิดเห็นส่วนหัว? ความคิดเห็นจะมีลักษณะเช่นนี้: MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description ดูเหมือนว่ามีประโยชน์ แต่ก็ถือว่าเป็นการปฏิบัติที่ไม่ดี?

11
เคยตกลงใช้รหัสไม่ทำงานหรือไม่?
เป็นความคิดที่ดีหรือไม่ที่ต้องส่งรหัสการทำงานเท่านั้น? การมอบหมายนี้ไม่จำเป็นต้องออกจากที่เก็บในสถานะใช้งานเป็น: ... เราอยู่ในช่วงเริ่มต้นของการออกแบบรหัสยังไม่เสถียร ... คุณเป็นผู้พัฒนาเพียงผู้เดียวในโครงการ คุณรู้ว่าทำไมสิ่งต่าง ๆ ไม่ทำงาน นอกจากนี้คุณไม่ได้หยุดการทำงานของใครก็ตามโดยการส่งรหัสที่ผิดพลาด ... รหัสในปัจจุบันใช้งานไม่ได้ เราจะทำการเปลี่ยนแปลงครั้งใหญ่ ลองทำเพื่อที่จะมีประเด็นที่จะย้อนกลับไปสู่สิ่งที่น่าเกลียด ... สายโซ่ยาวไม่มีปัญหาหากมีรหัสที่ใช้ไม่ได้ในสาขาท้องถิ่น กล่าวคือ ไฟล์ท้องถิ่น การจัดเตรียมพื้นที่ มุ่งมั่นในสาขาท้องถิ่น กระทำในสาขาคุณสมบัติส่วนบุคคลระยะไกล ผสานกับdevelopสาขาระยะไกล ผสานกับmasterสาขาระยะไกล ผสานกับreleaseสาขาระยะไกล ... กระทำก่อนกำหนดกระทำบ่อย ๆ ดังนั้นในคำถามที่เชื่อมโยงข้างต้นคำตอบส่วนใหญ่บอกว่าการคอมไพล์โค้ดที่ไม่สามารถคอมไพล์ได้นั้นไม่มีปัญหาในสาขาท้องถิ่นและฟีเจอร์ ทำไม? มูลค่าของการกระทำที่เสียหายคืออะไร? ที่เพิ่มเข้ามา: มีความคิดเห็นที่ได้รับการโหวตสูงสองสามรายการโดยบอกว่าในสาขาท้องถิ่นสามารถทำได้ทุกอย่างที่ต้องการ อย่างไรก็ตามฉันไม่สนใจด้านเทคนิคของคำถาม แต่ฉันต้องการเรียนรู้แนวปฏิบัติที่ดีที่สุด - นิสัยที่คนที่ทำงานมาหลายปีในอุตสาหกรรมมีผลงานมากที่สุด ฉันประหลาดใจกับคำตอบที่ยอดเยี่ยมมากมาย! พวกเขานำฉันไปสู่ข้อสรุปว่าฉันไม่ชำนาญในการใช้สาขาเพื่อจัดระเบียบโค้ดของฉัน

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

8
คุณสามารถแนะนำเทมเพลต / แนวทางการส่งข้อความที่ดีเพื่อบังคับใช้ใน บริษัท ได้หรือไม่? [ปิด]
ใน Git เป็นไปได้ที่จะตั้งค่าและบังคับใช้เทมเพลตการคอมมิท คุณสามารถแนะนำเทมเพลต / แนวทางปฏิบัติที่ดีเพื่อบังคับใช้ใน บริษัท ได้หรือไม่?

8
อะไรคือคำว่าซอร์สโค้ดที่ใหญ่มากที่คอมมิท [ปิด]
บางครั้งเมื่อเราตรวจสอบประวัติการกระทำของซอฟต์แวร์เราอาจเห็นว่ามีข้อผูกพันบางอย่างที่ใหญ่มาก - พวกเขาอาจเปลี่ยนไฟล์ 10 หรือ 20 ไฟล์ที่มีการเปลี่ยนแปลงหลายร้อยบรรทัดซอร์สโค้ด (เดลต้า) ฉันจำได้ว่ามีคำที่ใช้กันทั่วไปสำหรับการกระทำที่ยิ่งใหญ่ แต่ฉันจำไม่ได้ว่าคำนั้นคืออะไร มีใครช่วยฉันบ้าง อะไรคือคำที่ผู้เขียนโปรแกรมมักใช้เพื่ออ้างถึงการกระทำที่ยิ่งใหญ่และยักษ์ใหญ่? BTW มีการเปลี่ยนแปลงมากมายรวมกันเป็นแนวปฏิบัติที่ดีหรือไม่? ปรับปรุง: ขอบคุณพวกคุณสำหรับการสนทนาที่สร้างแรงบันดาลใจ! แต่ฉันคิดว่า "code bomb" เป็นคำที่ฉันกำลังมองหา

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

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

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

6
รูปแบบสเปรดชีตที่เป็นมิตรกับ Git? [ปิด]
เรากำลังพยายามย้ายกระบวนการเอกสารโครงการของเราจาก Google เอกสารไปยังชุดของที่เก็บ Git ที่โฮสต์ด้วยตนเอง เอกสารข้อความนั้นง่ายต่อการคอมไพล์เนื่องจากเรามักไม่ต้องการการจัดรูปแบบแฟนซีเราจะแปลงทุกอย่างเป็นพูดคำสั่งย่อยด้วยตัวเลือกเพื่อฝัง LaTeX สำหรับกรณีที่ซับซ้อน แต่สเปรดชีตเป็นเรื่องที่แตกต่างกันมาก ... มีรูปแบบสเปรดชีต (- เหมือน) ที่เป็นมิตรกับระบบควบคุมเวอร์ชัน (และยิ่งกว่านั้นคือมนุษย์สามารถอ่านได้เหมือนกับ Markdown)? "รูปแบบที่เป็นมิตร": Git ทำงานได้ดีกับรูปแบบ ( ไม่ใช้ XML) และสร้างความแตกต่างที่มนุษย์สามารถอ่านได้ ( การกำหนดค่าเพิ่มเติมที่เกี่ยวข้องกับเครื่องมือภายนอกนั้นใช้ได้) เห็นได้ชัดว่ารสชาติ Markdown อนุญาตให้สร้างตารางแบบคงที่ แต่ฉันต้องการที่จะใช้สิ่งต่าง ๆ เช่นSUM()ฯลฯ ... (โปรดทราบว่า CSV มีปัญหาเดียวกัน) ไม่มี WYSIWYG เป็นไร แต่การสนับสนุนเครื่องมือแก้ไข / เครื่องมือที่ดีจะเป็น ดี โปรดอัพเดท: คำตอบที่เป็นมิตรกับ Linux เท่านั้น ไม่มี MS Office

8
ความปลอดภัยและความน่าเชื่อถือในการโฮสต์เว็บไซต์เช่น sourceforge, github หรือ bitbucket สำหรับโปรเจ็กต์แบบปิดเป็นอย่างไร [ปิด]
ฉันกำลังพิจารณาใช้ sourceforge, bitbucket หรือ github สำหรับการจัดการการควบคุมแหล่งที่มาสำหรับธุรกิจของฉัน ฉันมีโครงการแบบเปิดและฉันมีส่วนร่วมในโครงการเปิดเช่น gcc แต่ฉันก็มีธุรกิจที่ฉันพัฒนาซอฟต์แวร์โอเพนซอร์สสำหรับการใช้ชีวิตของฉัน แหล่งที่เชื่อถือได้ความเชื่อถือของ Github หรือ Bitbucket ในแง่ของการรักษาความปลอดภัยของซอฟต์แวร์จากการสอดรู้สอดเห็นหรือไม่? โฮสติ้งมีความเสถียรเพียงใดในแง่ของการป้องกันการสูญหายของข้อมูล? มีใครบ้างไหมที่ใช้ตรรกะทางธุรกิจกับชุดดังกล่าว? มีใครออกสำรวจโซลูชันโฮสติ้งหลาย ๆ

7
การควบคุมเวอร์ชันทำงานบนไมโครคอมพิวเตอร์ในยุค 80 และ 90 อย่างไร
ฉันอยากรู้ว่าทีมโปรแกรมเมอร์มักจะจัดการการพัฒนาซอฟต์แวร์ของพวกเขาในยุค 80 และต้นยุค 90 อย่างไร มีการจัดเก็บซอร์สโค้ดทั้งหมดไว้ในเครื่องเดียวที่ทุกคนทำงานหรือถูกส่งผ่านไปมาและคัดลอกด้วยตนเองผ่านฟลอปปี้และรวมเข้าด้วยกันหรือพวกเขาใช้ระบบควบคุมการแก้ไขผ่านเครือข่าย (ตัวอย่างเช่น CVS) เช่นเดียวกับที่เราทำ ตอนนี้หรือไม่ หรืออาจจะมีการใช้ CVS ออฟไลน์เช่นเดียวกัน ทุกวันนี้ทุกคนขึ้นอยู่กับการควบคุมแหล่งที่มา .. มันไม่มีเกมง่ายๆ แต่ในยุค 80 เครือข่ายคอมพิวเตอร์ไม่ใช่เรื่องง่ายที่จะตั้งค่าและสิ่งต่าง ๆ เช่นแนวปฏิบัติที่ดีที่สุดยังคงถูกคิดออก ... ฉันรู้ว่าในการเขียนโปรแกรม 70s และ 60s นั้นค่อนข้างแตกต่างกันดังนั้นการควบคุมการแก้ไขจึงไม่จำเป็น แต่ในยุค 80 และ 90 ที่ผู้คนเริ่มใช้คอมพิวเตอร์เพื่อเขียนรหัสและแอปพลิเคชันเริ่มเพิ่มขนาดและขอบเขตดังนั้นฉันจึงสงสัยว่าผู้คนจัดการกับสิ่งเหล่านั้นได้อย่างไร นอกจากนี้สิ่งนี้แตกต่างระหว่างแพลตฟอร์มอย่างไร พูดว่า Apple กับ Commodore 64 กับ Amiga กับ MS-DOS เทียบกับ Windows กับ Atari หมายเหตุ: ส่วนใหญ่ฉันพูดถึงการเขียนโปรแกรมบนไมโครคอมพิวเตอร์ในแต่ละวันไม่ใช่เครื่อง UNIX ขนาดใหญ่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.