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

การควบคุมเวอร์ชันเป็นส่วนประกอบของ การ จัดการการกำหนดค่าซอฟต์แวร์^{[ 1 ]}

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

ระบบควบคุมเวอร์ชันประกอบด้วยตัวเลือกในการดูเวอร์ชันเก่าและย้อนกลับไฟล์ไปยังเวอร์ชันก่อนหน้า

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

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

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

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

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

เครื่องมืออัปเดตซอฟต์แวร์ IEBUPDTEของ IBM OS/360 มีมาตั้งแต่ปี 1962 ซึ่งอาจถือได้ว่าเป็นต้นแบบของเครื่องมือระบบควบคุมเวอร์ชัน แพ็กเกจการจัดการซอร์สโค้ดและการควบคุมเวอร์ชันสองแพ็กเกจที่ใช้กันอย่างแพร่หลายในระบบ IBM 360/370 คือThe Librarian และPanvalet ^{[ 4 ] [ 5 ]}

ระบบเต็มรูปแบบที่ออกแบบมาเพื่อควบคุมซอร์สโค้ดเริ่มต้นขึ้นในปี 1972: ระบบควบคุมซอร์สโค้ด (SCCS) สำหรับ OS/360 อีกครั้ง คู่มือผู้ใช้ของ SCCS โดยเฉพาะบทนำ ซึ่งเผยแพร่เมื่อวันที่ 4 ธันวาคม 1975 บ่งชี้ว่าเป็นระบบควบคุมการแก้ไขแบบตั้งใจครั้งแรก^{[ 6 ]}ระบบควบคุมการแก้ไข (RCS) ตามมาในปี 1982 ^{[ 7 ]}และต่อมาระบบเวอร์ชันพร้อมกัน (CVS) ได้เพิ่มคุณสมบัติเครือข่ายและการพัฒนาพร้อมกันให้กับ RCS หลังจาก CVS ผู้สืบทอดที่โดดเด่นคือ^{Subversion [} 8 ] ^{ตามมา}ด้วยการเกิดขึ้นของ เครื่องมือ ^{ควบคุม}เวอร์ชันแบบกระจายเช่นGit [ ^{9 ]}

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

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

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

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

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

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

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

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

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

การควบคุมการแก้ไขทางวิศวกรรมได้รับการพัฒนาจากกระบวนการที่เป็นทางการโดยอิงจากการติดตามการแก้ไขแบบพิมพ์เขียวหรือเส้นร่าง เบื้องต้น "MIL-STD-100G: มาตรฐานการปฏิบัติของกระทรวงกลาโหมสำหรับแบบเขียนทางวิศวกรรม" (PDF)กระทรวงกลาโหมสหรัฐอเมริกา 9 มิถุนายน 1997 สืบค้นเมื่อ 16 พฤษภาคม 2026ระบบควบคุมนี้ช่วยให้สามารถย้อนกลับไปยังสถานะก่อนหน้าของการออกแบบได้โดยปริยาย ในกรณีที่พบทางตันทางวิศวกรรมในการพัฒนาการออกแบบ ตารางแก้ไขถูกใช้เพื่อติดตามการเปลี่ยนแปลงที่เกิดขึ้น นอกจากนี้ พื้นที่ที่ได้รับการแก้ไขในแบบร่างจะถูกเน้นด้วยกลุ่มเมฆแก้ไข

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

การพัฒนาเกมมักเกี่ยวข้องกับไฟล์ไบนารีขนาดใหญ่และทีมงานที่ทำงานร่วมกันข้ามสาขาวิชาต่างๆ ดังนั้น สตูดิโอเกมจึงใช้ระบบควบคุมเวอร์ชันที่มีการสนับสนุนที่ดีสำหรับไฟล์ไบนารีขนาดใหญ่ การล็อกไฟล์ และการซิงโครไนซ์ที่รวดเร็ว เครื่องมือทั่วไป ได้แก่ Perforce และระบบบนคลาวด์รุ่นใหม่ๆ อีกหลายระบบ^{[ 11 ] [ 12 ]}

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

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

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

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

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

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

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

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

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

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

การอภิปรายอย่างเป็นทางการส่วนใหญ่เกี่ยวกับการจัดการการกำหนดค่ามักใช้คำว่า " เส้นฐาน" (baseline )

ระบบควบคุมการแก้ไขแบบกระจาย (DRCS) ใช้แนวทางแบบ peer-to-peer ซึ่งแตกต่างจาก แนวทางแบบ client-serverของระบบแบบรวมศูนย์ แทนที่จะเป็นที่เก็บข้อมูลส่วนกลางเพียงแห่งเดียวที่ไคลเอนต์ทำการซิงโครไนซ์ สำเนาการทำงานของโค้ดเบสของแต่ละ peer ถือเป็นที่เก็บข้อมูลที่แท้จริง^{[ 14 ]} การควบคุมการแก้ไขแบบกระจายดำเนินการซิงโครไนซ์โดยการแลกเปลี่ยนแพตช์ (ชุดการเปลี่ยนแปลง) จาก peer หนึ่งไปยังอีก peer หนึ่ง ซึ่งส่งผลให้เกิดความแตกต่างที่สำคัญบางประการจากระบบแบบรวมศูนย์:

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

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

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

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

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

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

ประโยชน์หลักประการหนึ่งคือความสามารถในการเก็บประวัติและย้อนกลับการเปลี่ยนแปลง ทำให้ผู้พัฒนาสามารถยกเลิกการเปลี่ยนแปลงได้อย่างง่ายดาย ซึ่งจะทำให้ผู้พัฒนามีโอกาสทดลองมากขึ้น ลดความกังวลเรื่องการทำให้โค้ดที่มีอยู่เสียหาย^{[ 16 ]}

การแตกสาขาช่วยในการปรับใช้และการจัดการ การเผยแพร่ การแตกสาขาและการรวม การผลิต การบรรจุ และการติดฉลากแพตช์ ซอร์สโค้ด และการประยุกต์ใช้แพตช์กับฐานโค้ดได้ง่าย ช่วยลดความซับซ้อนในการบำรุงรักษาและการพัฒนาพร้อมกันของฐานโค้ดหลายฐานที่เกี่ยวข้องกับขั้นตอนต่างๆ ของกระบวนการปรับใช้ เช่น การพัฒนา การทดสอบ การจัดเตรียม การผลิต เป็นต้น^{[ 17 ]}

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

เมื่อเกิดข้อผิดพลาด การรู้ว่าได้ทำอะไรไปเมื่อใดจะช่วยลดความเสียหายและฟื้นฟูได้ โดยช่วยในการระบุว่ามีปัญหาอะไรเกิดขึ้น เกิดขึ้นมานานแค่ไหน และกำหนดขอบเขตของปัญหาและวิธีแก้ไข^{[ 19 ]}สามารถติดตั้งและทดสอบเวอร์ชันก่อนหน้าเพื่อตรวจสอบข้อสรุปที่ได้จากการตรวจสอบโค้ดและข้อความคอมมิต^{[ 20 ]}

การควบคุมเวอร์ชันสามารถทำให้การดีบักง่ายขึ้นอย่างมาก การใช้กรณีทดสอบกับหลายเวอร์ชันสามารถระบุการเปลี่ยนแปลงที่ทำให้เกิดข้อผิดพลาดได้อย่างรวดเร็ว^{[ 21 ]} นักพัฒนาไม่จำเป็นต้องคุ้นเคยกับโค้ดเบสทั้งหมด และสามารถมุ่งเน้นไปที่โค้ดที่ทำให้เกิดปัญหาได้

การควบคุมเวอร์ชันช่วยเพิ่มประสิทธิภาพการทำงานร่วมกันได้หลายวิธี เนื่องจากการควบคุมเวอร์ชันสามารถระบุการเปลี่ยนแปลงที่ขัดแย้งกันได้ เช่น การเปลี่ยนแปลงที่ไม่เข้ากันที่เกิดขึ้นกับบรรทัดโค้ดเดียวกัน จึงไม่จำเป็นต้องมีการประสานงานระหว่างนักพัฒนามากนัก^{[ 22 ]}

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

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

ปลั๊กอินมักมีให้ใช้งานสำหรับIDEเช่นOracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , XcodeและGNU Emacs (ผ่าน vc.el) ต้นแบบการวิจัยขั้นสูงสร้างข้อความคอมมิตที่เหมาะสม^{[ 24 ]}

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

ฉบับแก้ไขที่ได้รับการอนุมัติของเอกสารหรือไฟล์ต้นฉบับ ซึ่งสามารถทำการเปลี่ยนแปลงเพิ่มเติมได้ในภายหลัง โปรดดูที่เส้นฐาน ป้ายกำกับ และแท็ก

ค้นหาชื่อผู้เขียนและเวอร์ชันที่แก้ไขบรรทัดนั้นล่าสุด

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

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

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

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

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

การคอมมิต (หรือที่เรียกว่า check in , ci หรือ install , submitหรือrecordซึ่งใช้กันน้อยกว่า) คือการเขียนหรือรวมการเปลี่ยนแปลงที่เกิดขึ้นในสำเนาการทำงานกลับไปยังที่เก็บข้อมูล การคอมมิตประกอบด้วยข้อมูลเมตา ซึ่งโดยทั่วไปคือข้อมูลผู้เขียนและข้อความคอมมิตที่อธิบายถึงการเปลี่ยนแปลง

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

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

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

สตรีมที่ไฟล์บางเวอร์ชันหรือทั้งหมดเป็นสำเนาของเวอร์ชันในสตรีมหลัก

การส่งออก (Exporting)คือการดึงไฟล์ออกจากที่เก็บข้อมูล (Repository) คล้ายกับการเช็คเอาท์ (Check Out)แต่จะสร้างโครงสร้างไดเร็กทอรีที่สะอาดปราศจากข้อมูลเมตาของการควบคุมเวอร์ชันที่ใช้ในสำเนาใช้งาน (Working Copy) โดยทั่วไปมักใช้ก่อนการเผยแพร่เนื้อหา เป็นต้น

ดูการดึง

กระบวนการรวมการเปลี่ยนแปลงที่เกิดขึ้นในสาขาหลัก (main trunk)เข้ากับสาขาสำหรับการพัฒนา (feature หรือ team)

บางครั้งเรียกว่าtipซึ่งหมายถึง commit ล่าสุด ไม่ว่าจะเป็น trunk หรือ branch trunk และแต่ละ branch ต่างก็มี head ของตัวเอง แม้ว่าบางครั้ง HEAD จะถูกใช้ในความหมายกว้างๆ ว่า trunk ก็ตาม^{[ 31 ]}

การนำเข้าคือการคัดลอกโครงสร้างไดเร็กทอรีในเครื่อง (ซึ่งไม่ใช่สำเนาที่ใช้งานอยู่) เข้าไปในที่เก็บข้อมูลเป็นครั้งแรก

เพื่อสร้าง repository ใหม่ที่ว่างเปล่า

ซอฟต์แวร์ควบคุมเวอร์ชันบางตัวใช้Interleaved deltasซึ่งเป็นวิธีการที่ช่วยให้จัดเก็บประวัติของไฟล์ข้อความได้อย่างมีประสิทธิภาพมากกว่าการใช้การ บีบอัดแบบ Delta

ดูแท็ก

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

คล้ายกับลำต้นแต่แต่ละสาขาสามารถมีเส้นหลักได้

การรวมหรือการผสานข้อมูลคือการดำเนินการที่ใช้การเปลี่ยนแปลงสองชุดกับไฟล์หรือกลุ่มไฟล์ ตัวอย่างสถานการณ์บางส่วนมีดังนี้:

• ผู้ใช้ที่ทำงานกับชุดไฟล์จะอัปเดตหรือซิงค์สำเนางานของตนกับการเปลี่ยนแปลงที่ทำและตรวจสอบในที่เก็บโดยผู้ใช้อื่น^{[ 32 ]}
• ผู้ใช้พยายามเช็คอินไฟล์ที่ได้รับการอัปเดตโดยผู้อื่นนับตั้งแต่ไฟล์เหล่านั้นถูกเช็คเอาท์และซอฟต์แวร์ควบคุมเวอร์ชันจะรวมไฟล์โดยอัตโนมัติ (โดยทั่วไป หลังจากถามผู้ใช้ว่าควรดำเนินการรวมไฟล์โดยอัตโนมัติหรือไม่ และในบางกรณีจะดำเนินการรวมไฟล์ก็ต่อเมื่อสามารถแก้ไขปัญหาการรวมไฟล์ได้อย่างชัดเจนและสมเหตุสมผล)
• มีการสร้าง สาขาใหม่ ขึ้นมา จาก นั้นจึงทำการแก้ไขโค้ดในไฟล์ต่างๆ อย่างอิสระ และในภายหลังสาขาที่ได้รับการอัปเดตแล้วจะถูกรวมเข้ากับสาขาหลัก เดียวที่เป็นหนึ่งเดียว
• มีการแยกไฟล์ชุดหนึ่งออกเป็นสาขาจากนั้นแก้ไขปัญหาที่มีอยู่ก่อนการแยกสาขาในสาขาหนึ่ง และรวมการแก้ไขนั้นเข้ากับสาขาอื่น (การรวมแบบเลือกเฉพาะส่วนนี้บางครั้งเรียกว่าcherry pickเพื่อแยกความแตกต่างจากการรวมแบบสมบูรณ์ในกรณีที่ผ่านมา)

การกระทำของการคัดลอกเนื้อหาไฟล์จากตำแหน่งที่มีการควบคุมน้อยกว่าไปยังตำแหน่งที่มีการควบคุมมากกว่า ตัวอย่างเช่น จากพื้นที่ทำงานของผู้ใช้ไปยังที่เก็บข้อมูล หรือจากสตรีมไปยังสตรีมแม่^{[ 33 ]}

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

การที่ผู้ใช้เข้ามาแทรกแซงเพื่อแก้ไขความขัดแย้งระหว่างการเปลี่ยนแปลงต่างๆ ที่เกิดขึ้นในเอกสารเดียวกัน

กระบวนการรวมสาขาของทีมต่างๆ เข้ากับสาขาหลักของระบบการจัดการเวอร์ชัน

เวอร์ชันหมายถึง การเปลี่ยนแปลงรูปแบบใดๆ ใน SVK การแก้ไข (Revision) คือ สถานะ ณ จุดเวลาใดเวลาหนึ่งของโครงสร้างทั้งหมดในที่เก็บข้อมูล

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

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

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

ลำต้น คือสายการพัฒนาที่ ไม่ซ้ำกันซึ่งไม่ใช่สาขา (บางครั้งเรียกว่า Baseline, Mainline หรือ Master ^{[ 40 ] [ 41 ]} )

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

การปลดล็อก

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

• "คู่มือภาพประกอบเกี่ยวกับการควบคุมเวอร์ชัน" ฉบับอธิบายได้ดียิ่งขึ้น.
• Sink, Eric, "ระบบควบคุมเวอร์ชัน" ( SCM ) (วิธีการใช้งาน)หลักการพื้นฐานของการควบคุมเวอร์ชัน