การควบคุมเวอร์ชัน

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

ในด้านวิศวกรรมซอฟต์แวร์การควบคุมเวอร์ชัน (หรือที่เรียกว่าการควบคุมการแก้ไข การควบคุมแหล่งที่มาหรือการจัดการซอร์สโค้ด ) คือกลุ่มของระบบที่รับผิดชอบในการจัดการการเปลี่ยนแปลงโปรแกรมคอมพิวเตอร์เอกสาร เว็บไซต์ขนาดใหญ่ หรือชุดข้อมูลอื่นๆ การควบคุมเวอร์ชันเป็นส่วนประกอบของ การจัดการการ กำหนดค่าซอฟต์แวร์ [1]

การเปลี่ยนแปลงมักจะระบุด้วยตัวเลขหรือรหัสตัวอักษร เรียกว่า "หมายเลขการแก้ไข" "ระดับการแก้ไข" หรือเพียงแค่ "การแก้ไข" ตัวอย่างเช่น ชุดเริ่มต้นของไฟล์คือ "รุ่น 1" เมื่อทำการเปลี่ยนแปลงครั้งแรก ชุดผลลัพธ์จะเป็น "การแก้ไข 2" เป็นต้น การแก้ไขแต่ละครั้งจะสัมพันธ์กับการประทับเวลาและบุคคลที่ทำการเปลี่ยนแปลง การแก้ไขสามารถเปรียบเทียบ กู้คืน และรวมเข้ากับไฟล์บางประเภทได้ [2]

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

โดยทั่วไปแล้วระบบควบคุมเวอร์ชันจะทำงานเป็นแอปพลิเคชันแบบสแตนด์อโลน แต่การควบคุมการแก้ไขยังฝังอยู่ในซอฟต์แวร์ประเภทต่างๆ เช่นโปรแกรมประมวลผลคำและสเปรดชีตเอกสารเว็บที่ทำงานร่วมกัน[ 3]และระบบการจัดการเนื้อหา เช่น ประวัติหน้าของWikipedia การควบคุมการแก้ไขทำให้สามารถคืนค่าเอกสารกลับไปเป็นการแก้ไขก่อนหน้า ซึ่งเป็นสิ่งสำคัญสำหรับการอนุญาตให้ผู้แก้ไขติดตามการแก้ไขของกันและกัน แก้ไขข้อผิดพลาด และป้องกันการก่อกวนและสแปมในวิ กิ

ภาพรวม

ในทางวิศวกรรมซอฟต์แวร์ คอมพิวเตอร์ การควบคุมการแก้ไขคือแนวทางปฏิบัติใดๆ ก็ตามที่ติดตามและให้การควบคุมการเปลี่ยนแปลงใน ซอร์สโค้ด นักพัฒนาซอฟต์แวร์บางครั้งใช้ซอฟต์แวร์ควบคุมการแก้ไขเพื่อรักษาเอกสารและไฟล์การกำหนดค่าตลอดจนซอร์สโค้ด

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

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

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

การควบคุมการแก้ไขอาจติดตามการเปลี่ยนแปลงของไฟล์การกำหนดค่าเช่น ไฟล์ที่จัดเก็บไว้ใน/etcหรือ/usr/local/etcบนระบบ Unix ซึ่งช่วยให้ผู้ดูแลระบบมีอีกวิธีหนึ่งในการติดตามการเปลี่ยนแปลงที่ทำขึ้นอย่างง่ายดายและวิธีย้อนกลับไปยังเวอร์ชันก่อนหน้าหากจำเป็นต้องเกิดขึ้น

ประวัติ

เครื่องมืออัปเดตซอฟต์แวร์ OS/360 IEBUPDTE ของ IBM มี ขึ้นตั้งแต่ปีพ.ศ. 2505 ซึ่งอาจเป็นเครื่องมือในระบบควบคุมเวอร์ชัน ระบบเต็มรูปแบบที่ออกแบบมาสำหรับการควบคุมซอร์สโค้ดเริ่มต้นขึ้นในปี 1972 ระบบควบคุมซอร์สโค้ดสำหรับระบบเดียวกัน (OS/360) บทนำของ Source Code Control System ซึ่งเผยแพร่เมื่อวันที่ 4 ธันวาคม พ.ศ. 2518 ได้บอกเป็นนัยว่าระบบนี้เป็นระบบควบคุมการแก้ไขโดยเจตนาระบบแรก [4] RCS ตามมาหลังจากนั้น[5]ด้วยเวอร์ชันเครือข่ายConcurrent Versions System รุ่นต่อไปหลังจาก Concurrent Versions System ถูกครอบงำโดยSubversion [ 6]ตามด้วยการเพิ่มขึ้นของการควบคุมการแก้ไขแบบกระจายเครื่องมือเช่นGit . [7]

โครงสร้าง

การควบคุมการแก้ไขจะจัดการการเปลี่ยนแปลงชุดข้อมูลเมื่อเวลาผ่านไป การเปลี่ยนแปลงเหล่านี้สามารถจัดโครงสร้างได้หลายวิธี

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

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

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

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

โครงสร้างกราฟ

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

ในแง่ของทฤษฎีกราฟการแก้ไขมักจะคิดว่าเป็นแนวการพัฒนา ( ลำต้น ) โดยแยกกิ่งออกจากส่วนนี้ ก่อตัวเป็นต้นไม้กำกับทิศทาง มองเห็นเป็นเส้นการพัฒนาคู่ขนานกัน ("สายหลัก" ของกิ่งก้าน) แตกแขนง ปิดลำต้น ในความเป็นจริง โครงสร้างซับซ้อนกว่า โดยสร้างกราฟ acyclic กำกับแต่สำหรับวัตถุประสงค์หลายประการ "ต้นไม้ที่มีการผสาน" เป็นการประมาณที่เพียงพอ

การแก้ไขจะเกิดขึ้นตามลำดับเมื่อเวลาผ่านไป และสามารถจัดเรียงตามลำดับได้ ไม่ว่าจะด้วยหมายเลขการแก้ไขหรือการประทับเวลา [หมายเหตุ 2]การแก้ไขจะขึ้นอยู่กับการแก้ไขที่ผ่านมา แม้ว่าจะเป็นไปได้ที่จะแทนที่การแก้ไขก่อนหน้าส่วนใหญ่หรือทั้งหมด เช่น "ลบข้อความที่มีอยู่ทั้งหมด แทรกข้อความใหม่" ในกรณีที่ง่ายที่สุด โดยไม่มีการแตกแขนงหรือเลิกทำ การแก้ไขแต่ละครั้งจะขึ้นอยู่กับรุ่นก่อนหน้าในทันที และจะสร้างบรรทัดง่ายๆ ด้วยเวอร์ชันล่าสุดเดียวคือ การแก้ไข "HEAD" หรือคำแนะนำ ใน แง่ ทฤษฎีกราฟการวาดการแก้ไขแต่ละรายการเป็นจุดและความสัมพันธ์ "การแก้ไขที่ได้รับ" แต่ละรายการเป็นลูกศร (โดยปกติจะชี้จากเก่าไปหาใหม่กว่า ในทิศทางเดียวกับเวลา) นี่คือกราฟเชิงเส้น. หากมีการแตกแขนง การแก้ไขในอนาคตหลายๆ ครั้งจะขึ้นอยู่กับการแก้ไขในอดีตหรือการเลิกทำ ดังนั้นการแก้ไขอาจขึ้นอยู่กับการแก้ไขที่เก่ากว่ารุ่นก่อนในทันที กราฟผลลัพธ์จะเป็นแผนผังที่มีทิศทางแทน(แต่ละโหนดสามารถมีได้มากกว่าหนึ่งโหนด ลูก) และมีเคล็ดลับหลายประการที่สอดคล้องกับการแก้ไขที่ไม่มีลูก ("การแก้ไขล่าสุดในแต่ละสาขา") [หมายเหตุ 3]โดยหลักการแล้ว แผนภูมิผลลัพธ์ไม่จำเป็นต้องมีเคล็ดลับที่ต้องการ (การแก้ไข "หลัก" ล่าสุด) – เพียงแค่การแก้ไขต่างๆ ที่หลากหลาย – แต่ในทางปฏิบัติ โดยทั่วไปแล้วหนึ่งทิปจะถูกระบุเป็น HEAD เมื่อการแก้ไขใหม่อิงตาม HEAD การแก้ไขนั้นจะถูกระบุว่าเป็น HEAD ใหม่ หรือถือเป็นสาขาใหม่ [หมายเหตุ 4]รายการการแก้ไขตั้งแต่เริ่มต้นจนถึง HEAD (ในแง่ทฤษฎีกราฟ เส้นทางที่ไม่ซ้ำกันในแผนภูมิ ซึ่งสร้างกราฟเชิงเส้นเหมือนเมื่อก่อน) คือช่วงลำตัวหรือเส้นหลัก [หมายเหตุ 5]ในทางกลับกัน เมื่อการแก้ไขสามารถอ้างอิงจากการแก้ไขก่อนหน้าได้มากกว่าหนึ่งรุ่น (เมื่อโหนดสามารถมีพาเร นต์ได้มากกว่าหนึ่งรายการ ) กระบวนการที่ได้จะเรียกว่าการผสานและเป็นหนึ่งในแง่มุมที่ซับซ้อนที่สุดของการควบคุมการแก้ไข สิ่งนี้มักเกิดขึ้นเมื่อการเปลี่ยนแปลงเกิดขึ้นในหลายสาขา (ส่วนใหญ่มักจะสองสาขา แต่เป็นไปได้มากกว่านั้น) ซึ่งรวมเป็นสาขาเดียวที่รวมการเปลี่ยนแปลงทั้งสองไว้ หากการเปลี่ยนแปลงเหล่านี้ทับซ้อนกัน อาจเป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะรวม และต้องมีการแทรกแซงด้วยตนเองหรือการเขียนใหม่

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

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

กลยุทธ์เฉพาะ

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

การควบคุมเวอร์ชันแพร่หลายในธุรกิจและกฎหมาย อันที่จริง "เส้นแดงตามสัญญา" และ "เส้นดำทางกฎหมาย" เป็นรูปแบบแรกสุดของการควบคุมการแก้ไข[8]และยังคงใช้ในธุรกิจและกฎหมายที่มีระดับความซับซ้อนต่างกันไป เทคนิคที่ซับซ้อนที่สุดกำลังเริ่มใช้สำหรับการติดตามการเปลี่ยนแปลงของไฟล์ CAD ทางอิเล็กทรอนิกส์ (ดูการจัดการข้อมูลผลิตภัณฑ์ ) แทนที่การใช้ระบบอิเล็กทรอนิกส์ "ด้วยตนเอง" ของการควบคุมการแก้ไขแบบดั้งเดิม [ ต้องการการอ้างอิง ]

โมเดลการจัดการแหล่งที่มา

ระบบควบคุมการแก้ไขแบบเดิมใช้โมเดลแบบรวมศูนย์ซึ่งฟังก์ชันการควบคุมการแก้ไขทั้งหมดเกิดขึ้นบนเซิร์ฟเวอร์ ที่ใช้ร่วม กัน หากนักพัฒนาสองคนพยายามเปลี่ยนไฟล์เดียวกันพร้อมกันโดยไม่มีวิธีจัดการการเข้าถึง นักพัฒนาอาจต้องเขียนทับงานของกันและกัน ระบบควบคุมการแก้ไขแบบรวมศูนย์ช่วยแก้ปัญหานี้ใน "รูปแบบการจัดการแหล่งที่มา" ที่แตกต่างกันสองแบบ ได้แก่ การล็อกไฟล์และการรวมเวอร์ชัน

การดำเนินการปรมาณู

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

การล็อกไฟล์

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

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

การรวมเวอร์ชัน

ระบบควบคุมเวอร์ชันส่วนใหญ่อนุญาตให้นักพัฒนาหลายคนแก้ไขไฟล์เดียวกันได้พร้อมกัน ผู้พัฒนารายแรกที่ "เช็คอิน" จะเปลี่ยนที่เก็บส่วนกลางได้สำเร็จเสมอ ระบบอาจอำนวยความสะดวกในการรวมการเปลี่ยนแปลงเพิ่มเติมลงในที่เก็บส่วนกลาง และรักษาการเปลี่ยนแปลงจากผู้พัฒนารายแรกเมื่อนักพัฒนารายอื่นเช็คอิน

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

แนวคิดของการแก้ไขที่สงวนไว้สามารถให้วิธีการทางเลือกในการล็อกไฟล์อย่างชัดเจนสำหรับการเข้าถึงการเขียนแบบเอกสิทธิ์เฉพาะบุคคล แม้ว่าจะมีความสามารถในการผสาน

ข้อมูลพื้นฐาน ป้ายกำกับ และแท็ก

เครื่องมือควบคุมการแก้ไขส่วนใหญ่จะใช้เพียงคำใดคำหนึ่งที่คล้ายกันเหล่านี้ (พื้นฐาน ป้ายกำกับ แท็ก) เพื่ออ้างถึงการดำเนินการระบุสแน็ปช็อต ("ป้ายกำกับโครงการ") หรือบันทึกของสแน็ปช็อต ("ลองใช้กับบรรทัดฐานX ") . โดยทั่วไปมีเพียงเงื่อนไขพื้นฐานป้ายชื่อหรือแท็กเท่านั้นที่ ใช้ในเอกสาร ประกอบหรือการอภิปราย พวกเขาสามารถถือเป็นคำพ้องความหมาย

ในโครงการส่วนใหญ่ สแนปชอตบางรายการมีความสำคัญมากกว่าภาพอื่นๆ เช่น ภาพที่ใช้ในการระบุการเผยแพร่ที่เผยแพร่ สาขา หรือเหตุการณ์สำคัญ

เมื่อใช้ทั้งคำว่าbaselineและlabelหรือtag อย่างใดอย่างหนึ่ง ร่วมกันในบริบทเดียวกันlabelและtagมักจะอ้างถึงกลไกภายในเครื่องมือในการระบุหรือสร้างบันทึกของ snapshot และbaselineบ่งชี้ถึงความสำคัญที่เพิ่มขึ้นของ label ที่กำหนด หรือแท็ก

การอภิปรายอย่างเป็นทางการส่วนใหญ่เกี่ยวกับ การจัดการการ ตั้ง ค่าคอนฟิกใช้คำพื้นฐาน

การควบคุมการแก้ไขแบบกระจาย

ระบบควบคุมการแก้ไขแบบกระจาย (DRCS) ใช้แนวทางแบบเพียร์ทูเพียร์ ตรงข้ามกับระบบแบบรวมศูนย์ ระหว่าง ไคลเอนต์และเซิร์ฟเวอร์ แทนที่จะเป็นที่เก็บส่วนกลางเพียงแห่งเดียวที่ไคลเอ็นต์ซิงโครไนซ์ สำเนาการทำงานของฐานโค้ดของเพียร์แต่ละตัวเป็นที่เก็บจริง [10] การควบคุมการแก้ไขแบบกระจายดำเนินการซิงโครไนซ์โดยการแลกเปลี่ยน แพต ช์ (ชุดการเปลี่ยนแปลง) จากเพียร์ถึงเพียร์ ส่งผลให้เกิดความแตกต่างที่สำคัญจากระบบรวมศูนย์:

  • ไม่มี Canonical สำเนาอ้างอิงของฐานรหัสที่มีอยู่โดยค่าเริ่มต้น สำเนาการทำงานเท่านั้น
  • การดำเนินการทั่วไป (เช่น คอมมิต ประวัติการดู และการคืนค่าการเปลี่ยนแปลง) ทำได้รวดเร็ว เนื่องจากไม่จำเป็นต้องสื่อสารกับเซิร์ฟเวอร์ส่วนกลาง [1] : 7 

การสื่อสารมีความจำเป็นเฉพาะเมื่อมีการผลักดันหรือดึงการเปลี่ยนแปลงไปยังหรือจากเพื่อนคนอื่นๆ

  • สำเนาการทำงานแต่ละชุดทำงานได้อย่างมีประสิทธิภาพเสมือนเป็นการสำรองข้อมูลระยะไกลของฐานรหัสและประวัติการเปลี่ยนแปลง โดยให้การป้องกันข้อมูลสูญหายโดยธรรมชาติ [1] : 4 

บูรณาการ

เครื่องมือควบคุมการแก้ไขที่ล้ำหน้ากว่าบางตัวมีสิ่งอำนวยความสะดวกอื่นๆ มากมาย ทำให้สามารถผสานรวมกับเครื่องมืออื่นๆ และกระบวนการวิศวกรรมซอฟต์แวร์ได้อย่างลึกซึ้งยิ่งขึ้น ปลั๊กอินมักจะมีให้สำหรับIDEเช่นOracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , XcodeและGNU Emacs (ผ่าน vc.el) ต้นแบบการวิจัยขั้นสูงจะสร้างข้อความยืนยันที่เหมาะสม[11]แต่ใช้ได้เฉพาะกับโครงการที่มีประวัติขนาดใหญ่อยู่แล้ว เนื่องจากข้อความยืนยันจะขึ้นอยู่กับแบบแผนและลักษณะเฉพาะของโครงการ(12)

คำศัพท์ทั่วไป

คำศัพท์อาจแตกต่างกันไปในแต่ละระบบ แต่คำศัพท์บางคำในการใช้งานทั่วไป ได้แก่[13]

พื้นฐาน
การแก้ไขเอกสารหรือไฟล์ต้นทางที่ได้รับอนุมัติซึ่งสามารถทำการเปลี่ยนแปลงในภายหลังได้ ดูข้อมูลพื้นฐาน ป้ายกำกับ และแท็
ตำหนิ
การค้นหาผู้แต่งและการแก้ไขที่แก้ไขบรรทัดใดบรรทัดหนึ่งล่าสุด
สาขา
ชุดของไฟล์ภายใต้การควบคุมเวอร์ชันอาจแตกแขนงหรือแยกส่วน ณ เวลาหนึ่ง เพื่อที่ว่าจากเวลานั้นเป็นต้นไป สำเนาสองชุดของไฟล์เหล่านั้นอาจพัฒนาด้วยความเร็วที่ต่างกันหรือในลักษณะที่ต่างกันโดยอิสระจากกัน
เปลี่ยน
การเปลี่ยนแปลง (หรือdiffหรือdelta ) แสดงถึงการแก้ไขเฉพาะในเอกสารภายใต้การควบคุมเวอร์ชัน ความละเอียดของการดัดแปลงที่พิจารณาถึงการเปลี่ยนแปลงจะแตกต่างกันไปตามระบบควบคุมเวอร์ชัน
เปลี่ยนรายการ
ในระบบควบคุมเวอร์ชันต่างๆ ที่มี การคอมมิต หลายการเปลี่ยนแปลงของอะตอมรายการการเปลี่ยนแปลง (หรือCL ) ชุดการเปลี่ยนแปลง การอัปเดตหรือโปรแกรมแก้ไขจะระบุชุดของการเปลี่ยนแปลงที่เกิดขึ้นในการคอมมิตครั้งเดียว นอกจากนี้ยังสามารถแสดงมุมมองตามลำดับของซอร์สโค้ด ซึ่งช่วยให้สามารถตรวจสอบแหล่งที่มาของ ID รายการการเปลี่ยนแปลงใดๆ ได้
เช็คเอาท์
ในการเช็คเอาท์ (หรือco ) คือการสร้างสำเนาการทำงานในเครื่องจากที่เก็บ ผู้ใช้อาจระบุการแก้ไขเฉพาะหรือขอรับเวอร์ชันล่าสุด คำว่า 'เช็คเอาต์' ยังสามารถใช้เป็นคำนามเพื่ออธิบายสำเนางานได้อีกด้วย เมื่อไฟล์ถูกเช็คเอาท์จากเซิร์ฟเวอร์ไฟล์ที่ใช้ร่วมกัน ผู้ใช้อื่นไม่สามารถแก้ไขได้ ให้คิดเหมือนโรงแรม เมื่อคุณเช็คเอาท์ คุณจะไม่สามารถเข้าถึงสิ่งอำนวยความสะดวกได้อีกต่อไป
โคลน
การโคลนหมายถึงการสร้างที่เก็บที่มีการแก้ไขจากที่เก็บอื่น ซึ่งเทียบเท่ากับการพุ ช ing หรือดึง ing ลงในพื้นที่เก็บข้อมูลเปล่า (เริ่มต้นใหม่) ในฐานะที่เป็นคำนาม ที่เก็บสองแห่งสามารถเรียกได้ว่าเป็นโคลนถ้าพวกมันถูกซิงโครไนซ์ไว้และมีการแก้ไขที่เหมือนกัน
มุ่งมั่น (นาม)
'commit' หรือ 'revision' (SVN) คือการแก้ไขที่ใช้กับที่เก็บ
สัญญา (กริยา)
ในการคอมมิต ( check in , ciหรือน้อยกว่านั้นinstall , sendหรือrecord ) คือการเขียนหรือรวมการเปลี่ยนแปลงที่ทำในสำเนาการทำงานกลับไปที่ที่เก็บ การคอมมิตประกอบด้วยข้อมูลเมตา โดยทั่วไปคือข้อมูลผู้เขียนและข้อความยืนยันที่อธิบายการเปลี่ยนแปลง
ขัดแย้ง
ความขัดแย้งเกิดขึ้นเมื่อฝ่ายต่าง ๆ ทำการเปลี่ยนแปลงในเอกสารเดียวกัน และระบบไม่สามารถกระทบยอดการเปลี่ยนแปลงได้ ผู้ใช้ต้องแก้ไขข้อขัดแย้งโดยรวมการเปลี่ยนแปลง หรือโดยการเลือกการเปลี่ยนแปลงหนึ่งให้กับอีกการเปลี่ยนแปลงหนึ่ง
การบีบอัดเดลต้า
ซอฟต์แวร์ควบคุมการแก้ไขส่วนใหญ่ใช้การบีบอัดเดลต้าซึ่งจะเก็บเฉพาะความแตกต่างระหว่างไฟล์รุ่นต่อๆ มาเท่านั้น ซึ่งช่วยให้สามารถจัดเก็บไฟล์เวอร์ชันต่างๆ ได้อย่างมีประสิทธิภาพมากขึ้น
ไดนามิกสตรีม
สตรีมที่เวอร์ชันไฟล์บางเวอร์ชันหรือทั้งหมดเป็นมิเรอร์ของเวอร์ชันของสตรีมพาเรนต์
ส่งออก
การ เอ็กซ์พอร์ตเป็นการรับไฟล์จากที่เก็บ คล้ายกับการเช็คเอาท์ยกเว้นว่าจะสร้างแผนผังไดเร็กทอรีที่สะอาดโดยไม่มีข้อมูลเมตาการควบคุมเวอร์ชันที่ใช้ในสำเนาการทำงาน มักใช้ก่อนเผยแพร่เนื้อหา เป็นต้น
ดึงข้อมูล
ดูดึง _
ไปข้างหน้าบูรณาการ
กระบวนการรวมการเปลี่ยนแปลงที่ทำในtrunk หลัก เข้ากับสาขาการพัฒนา (ฟีเจอร์หรือทีม)
ศีรษะ
บางครั้งเรียกว่าtipซึ่งหมายถึงการคอมมิชชันล่าสุด ไม่ว่ากับลำต้นหรือสาขา ลำต้นและกิ่งก้านแต่ละกิ่งมีหัวเป็นของตัวเอง แม้ว่าบางครั้งใช้ HEAD อย่างหลวมๆ เพื่ออ้างถึงลำต้นก็ตาม [14]
นำเข้า
การนำเข้าเป็นการกระทำของการคัดลอกแผนผังไดเร็กทอรีในเครื่อง (ซึ่งปัจจุบันไม่ใช่สำเนาที่ใช้งานได้) ลงในที่เก็บในครั้งแรก
เริ่มต้น
เพื่อสร้างที่เก็บใหม่ที่ว่างเปล่า
เดลต้าอินเตอร์ลีฟ
ซอฟต์แวร์ควบคุมการแก้ไขบางตัวใช้Interleaved deltasซึ่งเป็นวิธีการที่ช่วยให้จัดเก็บประวัติของไฟล์แบบข้อความได้อย่างมีประสิทธิภาพมากกว่าการใช้ การบีบอัดข้อมูล แบบเดลต้า
ฉลาก
ดูแท็
กำลังล็อค
เมื่อนักพัฒนาล็อกไฟล์ จะไม่มีใครสามารถอัปเดตไฟล์นั้นได้จนกว่าจะปลดล็อก การล็อกสามารถได้รับการสนับสนุนโดยระบบควบคุมเวอร์ชัน หรือผ่านการสื่อสารที่ไม่เป็นทางการระหว่างนักพัฒนา (หรือที่เรียกว่าการล็อกทางสังคม )
เมนไลน์
คล้ายกับลำต้นแต่อาจมีสายหลักสำหรับแต่ละสาขา
ผสาน
การผสานหรือการรวมเป็นการดำเนินการที่มีการนำการเปลี่ยนแปลงสองชุดไปใช้กับไฟล์หรือชุดของไฟล์ บางสถานการณ์ตัวอย่างมีดังนี้:
  • ผู้ใช้ที่ทำงานกับชุดของไฟล์อัปเดตหรือซิงค์สำเนาการทำงานกับการเปลี่ยนแปลงที่ทำ และตรวจสอบในที่เก็บโดยผู้ใช้รายอื่น [15]
  • ผู้ใช้พยายามเช็คอินไฟล์ที่ได้รับการอัปเดตโดยผู้อื่นเนื่องจากไฟล์ถูกเช็คเอาท์และซอฟต์แวร์ควบคุมการแก้ไขจะผสานไฟล์โดยอัตโนมัติ (โดยทั่วไป หลังจากที่แจ้งผู้ใช้ว่าควรดำเนินการผสานอัตโนมัติหรือไม่ และในบางกรณีเท่านั้น ทำเช่นนั้นหากการผสานสามารถแก้ไขได้อย่างชัดเจนและสมเหตุสมผล)
  • มีการ สร้าง สาขารหัสในไฟล์ได้รับการแก้ไขอย่างอิสระ และสาขาที่อัปเดตแล้วจะถูกรวมเข้าในtrunk เดียวที่รวมเป็นหนึ่ง เดียว
  • ชุดของไฟล์มี การ แตกแขนงปัญหาที่มีอยู่ก่อนการแตกสาขาได้รับการแก้ไขในสาขาหนึ่ง จากนั้นการแก้ไขจะรวมเข้ากับอีกสาขาหนึ่ง (การผสานแบบเลือกสรรประเภทนี้บางครั้งเรียกว่าการคัดสรรแบบเชอร์รี่เพื่อแยกความแตกต่างจากการผสานแบบสมบูรณ์ในกรณีก่อนหน้า)
ส่งเสริม
การคัดลอกเนื้อหาไฟล์จากตำแหน่งที่ควบคุมน้อยกว่าไปยังตำแหน่งที่มีการควบคุมมากกว่า ตัวอย่างเช่น จากพื้นที่ทำงานของผู้ใช้ไปยังที่เก็บ หรือจากสตรีมไปยังพาเรนต์ [16]
ดึงผลัก
คัดลอกการแก้ไขจากที่เก็บหนึ่งไปยังอีกที่หนึ่ง การ ดึงเริ่มต้นโดยที่เก็บการรับ ในขณะที่การพุ ช เริ่มต้นโดยต้นทาง บางครั้งการ ดึงข้อมูลถูกใช้เป็นคำพ้องความหมายสำหรับpullหรือหมายถึงการดึงตามด้วยการอัปเด
ดึงคำขอ
นักพัฒนาซอฟต์แวร์ขอให้ผู้อื่นรวมการเปลี่ยนแปลงที่ "ผลักดัน" เข้าด้วยกัน
ที่เก็บ
ที่เก็บ (หรือ "repo") เป็นที่เก็บข้อมูลปัจจุบันและประวัติของไฟล์ ซึ่งมักจะอยู่บนเซิร์ฟเวอร์ บางครั้งเรียกอีกอย่างว่าคลัง
แก้ไข
การแทรกแซงของผู้ใช้เพื่อแก้ไขข้อขัดแย้งระหว่างการเปลี่ยนแปลงต่างๆ ในเอกสารเดียวกัน
การรวมย้อนกลับ
กระบวนการรวมสาขาต่าง ๆ ของทีมเข้าไว้ในลำตัวหลักของระบบการกำหนดเวอร์ชัน
การแก้ไข
นอกจากนี้เวอร์ชัน : เวอร์ชันคือการเปลี่ยนแปลงรูปแบบใดๆ ใน SVK การแก้ไขคือสถานะในช่วงเวลาหนึ่งของทรีทั้งหมดในที่เก็บ
แบ่งปัน
การทำให้หนึ่งไฟล์หรือโฟลเดอร์พร้อมใช้งานในหลายสาขาพร้อมกัน เมื่อไฟล์ที่แชร์ถูกเปลี่ยนในสาขาหนึ่ง ไฟล์นั้นจะถูกเปลี่ยนในสาขาอื่น
ลำธาร
คอนเทนเนอร์สำหรับไฟล์ที่แยกสาขาที่มีความสัมพันธ์ที่ทราบกับคอนเทนเนอร์อื่นๆ สตรีมสร้างลำดับชั้น แต่ละสตรีมสามารถสืบทอดคุณสมบัติต่างๆ (เช่น เวอร์ชัน เนมสเปซ กฎเวิร์กโฟลว์ สมาชิก ฯลฯ) จากสตรีมหลัก
แท็ก
แท็กหรือป้ายกำกับหมายถึงสแนปชอตที่สำคัญในเวลา ซึ่งสอดคล้องกันในหลายไฟล์ ไฟล์เหล่านี้ในจุดนั้นทั้งหมดอาจถูกแท็กด้วยชื่อที่เข้าใจง่ายหรือมีความหมายหรือหมายเลขรุ่นแก้ไข ดูข้อมูลพื้นฐาน ป้ายกำกับ และแท็
กระโปรงหลังรถ
สายการพัฒนาเฉพาะที่ไม่ใช่สาขา (บางครั้งเรียกว่า Baseline, Mainline หรือ Master [17] [18] )
อัปเดต
การอัปเดต (หรือsyncแต่syncยังหมายถึงการรวมpushและpull ) ผสานการเปลี่ยนแปลงที่ทำในที่เก็บ (โดยบุคคลอื่น เป็นต้น) ลงในสำเนาการทำงาน ใน เครื่อง การอัปเดตยังเป็นคำที่ใช้โดยเครื่องมือ CM บางตัว (CM+, PLS, SMS) สำหรับแนวคิดแพ็คเกจการเปลี่ยนแปลง (ดู รายการการเปลี่ยนแปลง ) ตรงกันกับ การ ชำระเงินในระบบควบคุมการแก้ไขที่ต้องการให้แต่ละที่เก็บมีสำเนาทำงานเพียงชุดเดียว (ทั่วไปในระบบแบบกระจาย)
กำลังปลดล็อค
ปลดล็อค
สำเนาการทำงาน
สำเนา การทำงานคือสำเนาของไฟล์ในเครื่องจากที่เก็บ ณ เวลาที่กำหนดหรือการแก้ไข งานทั้งหมดที่ทำกับไฟล์ในที่เก็บจะทำในสำเนาการทำงานในขั้นต้น จึงเป็นที่มาของชื่อ ตามแนวคิดแล้ว มันคือแซนด์บ็อกซ์

ดูเพิ่มเติม

หมายเหตุ

  1. ^ ในกรณีนี้ แก้ไขบัฟเฟอร์เป็นรูปแบบรองของสำเนาการทำงาน และไม่ได้อ้างอิงถึงสิ่งนี้
  2. โดยหลักการแล้ว การแก้ไขสองครั้งอาจมีการประทับเวลาเหมือนกัน ดังนั้นจึงไม่สามารถสั่งซื้อทางออนไลน์ได้ โดยทั่วไปจะเป็นกรณีของที่เก็บแยกต่างหาก แม้ว่าจะเป็นไปได้สำหรับการเปลี่ยนแปลงหลายสาขาพร้อมกันในที่เก็บเดียว ในกรณีเหล่านี้ การแก้ไขสามารถถือเป็นชุดของบรรทัดที่แยกจากกัน หนึ่งรายการต่อที่เก็บหรือสาขา (หรือสาขาภายในที่เก็บ)
  3. ^ การแก้ไขหรือที่เก็บ "ทรี" ไม่ควรสับสนกับแผนผังไดเร็กทอรีของไฟล์ในสำเนาการทำงาน
  4. ^ โปรดทราบว่าหากสาขาใหม่อิงตาม HEAD โทโพโลยี HEAD ก็ไม่ใช่ทิปอีกต่อไป เนื่องจากมีโหนดย่อย
  5. ^ "สายหลัก" ยังสามารถอ้างถึงเส้นทางหลักในสาขาแยกต่างหาก

อ้างอิง

  1. a b c โอซัลลิแวน, ไบรอัน (2009). Mercurial: คู่มือขั้นสุดท้าย เซบาสโตโพล์: O'Reilly Media, Inc. ISBN 978059655474. สืบค้นเมื่อ4 กันยายน 2558 .
  2. ^ สกอตต์ ชาคอน; สตราบ, เบ็น (2014). Pro Git รุ่นที่สอง สหรัฐอเมริกา: เอ เพรส . หน้า 14.
  3. ^ " Google Docs " ดูสิ่งที่เปลี่ยนแปลงในไฟล์ Google Inc..
  4. ^ โรชไคนด์, มาร์ค เจ. (1975). "ระบบควบคุมซอร์สโค้ด" (PDF ) ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์ SE-1 (4): 364–370. ดอย : 10.1109/TSE.1975.6312866 . S2CID 10006076 .  
  5. ทิชี, วอลเตอร์ เอฟ. (1985). "Rcs — ระบบสำหรับการควบคุมเวอร์ชัน" . ซอฟต์แวร์: การฝึกฝนและประสบการณ์ 15 (7): 637–654. ดอย : 10.1002/spe.4380150703 . ISSN 0038-0644 . S2CID 2655086 .  
  6. คอลลินส์-ซัสมัน, เบ็น; ฟิตซ์แพทริค บีดับเบิลยู; Pilato, CM (2004), การควบคุมเวอร์ชันด้วยการโค่นล้ม , O'Reilly, ISBN 0-596-00448-6
  7. ^ โลลิเกอร์ จอน; แมคคัลล็อก, แมทธิว (2012). การควบคุมเวอร์ชันด้วย Git: เครื่องมือและเทคนิคอันทรงพลังสำหรับการพัฒนาซอฟต์แวร์ร่วมกัน โอเรลลี่ มีเดีย. หน้า 2–5. ISBN 9781449345044.
  8. ^ สำหรับแบบเขียนทางวิศวกรรม โปรดดูที่ Whiteprint#Document controlสำหรับระบบแบบแมนนวลบางระบบที่ใช้กันทั่วไปในคริสต์ศตวรรษที่ 20 เช่นขั้นตอนทางวิศวกรรมของเครื่องบินฮิวจ์การแก้ไขแต่ละครั้งต้องได้รับการอนุมัติจากLawrence A. Hyland ดูขั้นตอนการอนุมัติที่จัดตั้งขึ้นโดยรัฐบาลสหรัฐฯ
  9. สมาร์ท, จอห์น เฟอร์กูสัน (2008) เครื่องมือไฟฟ้า ของจาวา "โอเรลลี มีเดีย อิงค์" หน้า 301. ISBN 9781491954546. สืบค้นเมื่อ20 กรกฎาคม 2019 .
  10. ^ วีลเลอร์, เดวิด. ความคิดเห็นเกี่ยวกับซอฟต์แวร์โอเพ่นซอร์ส / ซอฟต์แวร์ฟรี (OSS/FS) ระบบการจัดการการกำหนดค่าซอฟต์แวร์ (SCM ) เก็บจากต้นฉบับเมื่อ 9 พฤศจิกายน 2020 . สืบค้นเมื่อ8 พฤษภาคม 2550 .
  11. คอร์เตส-คอย, หลุยส์ เฟอร์นันโด; ลินาเรส-วาสเกซ, มาริโอ; อปอนเต, ไจโร; Poshyvanyk, เดนิส (2014). "สร้างข้อความยืนยันโดยอัตโนมัติผ่านการสรุปการเปลี่ยนแปลงซอร์สโค้ด" 2014 IEEE 14th International Working Conference เกี่ยวกับการวิเคราะห์และ การจัดการซอร์สโค้ด อีอีอี น. 275–284. ดอย : 10.1109/scam.2014.14 . ISBN 978-1-4799-6148-1. S2CID  360545 .
  12. เอเตมาดี, คชายาร์; มอนเพอร์รัส, มาร์ติน (2020-06-27). "ความเกี่ยวข้องของการเรียนรู้ข้ามโครงงานกับเพื่อนบ้านที่ใกล้ที่สุดเพื่อสร้างข้อความยืนยัน" การประชุมเชิงปฏิบัติการด้านวิศวกรรมซอฟต์แวร์ ครั้งที่ 42 ของ IEEE/ ACM โซล สาธารณรัฐเกาหลี: ACM. หน้า 470–475. arXiv : 2010.01924 . ดอย : 10.1145/3387940.3391488 . ISBN 9781450379632. S2CID  221911386 .
  13. วิงเกิร์ด, ลอร่า (2005). ประสิทธิภาพการปฏิบัติ โอเรลลี่. ISBN 0-596-10185-6. เก็บถาวรจากต้นฉบับเมื่อ 2007-12-21 . สืบค้นเมื่อ2006-08-27 .
  14. ^ เกรกอรี แกรี่ (3 กุมภาพันธ์ 2554) "Trunk vs. HEAD ในระบบควบคุมเวอร์ชัน" . Java, Eclipse และเกร็ดความรู้ด้านเทคนิคอื่นสืบค้นเมื่อ2012-12-16 .
  15. ^ Collins-Sussman, Fitzpatrick & Pilato 2004 , 1.5: SVN tour cycle แก้ไข : 'The G ย่อมาจาก merGed ซึ่งหมายความว่าไฟล์มีการเปลี่ยนแปลงในเครื่องตั้งแต่เริ่มต้น แต่การเปลี่ยนแปลงที่มาจากที่เก็บไม่ทับซ้อนกับโลคัล การเปลี่ยนแปลง.'
  16. ^ คู่มือแนวคิด (เวอร์ชัน 4.7 ฉบับปรับปรุง) แอคคิวเรฟ กรกฎาคม 2551
  17. ^ วอลเลน, แจ็ค (2020-09-22). "GitHub ที่จะแทนที่ master ด้วย main เริ่มในเดือนตุลาคม: สิ่งที่นักพัฒนาต้องทำตอนนี้" . เทครี พับบลิค. สืบค้นเมื่อ2022-04-24 .
  18. ↑ ไฮน์เซ, แคโรลีน ( 2020-11-24 ). "เหตุใด GitHub จึงเปลี่ยนชื่อสาขาหลักเป็นสาขาหลัก" . ฝั่งเซิร์ฟเวอร์ สืบค้นเมื่อ2022-04-24 .

ลิงค์ภายนอก