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

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

ข้อดีของระบบ DVCS (เมื่อเปรียบเทียบกับระบบรวมศูนย์) ได้แก่:

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

ข้อเสียของระบบ DVCS (เมื่อเปรียบเทียบกับระบบรวมศูนย์) ได้แก่:

• การดึงข้อมูลจากที่เก็บข้อมูลครั้งแรกจะช้ากว่าการดึงข้อมูลจากระบบควบคุมเวอร์ชันแบบรวมศูนย์ เนื่องจากโดยค่าเริ่มต้นแล้ว สาขาและประวัติการแก้ไขทั้งหมดจะถูกคัดลอกไปยังเครื่องโลคัล
• การขาดกลไกการล็อกซึ่งเป็นส่วนหนึ่งของระบบควบคุมเวอร์ชันแบบรวมศูนย์ส่วนใหญ่ ยังคงมีบทบาทสำคัญเมื่อพูดถึงไฟล์ไบนารีที่ไม่สามารถรวมกันได้ เช่น ไฟล์ภาพกราฟิก หรือไฟล์ไบนารีหรือแพ็กเกจ XML ที่ซับซ้อนเกินไป (เช่น เอกสาร Office, ไฟล์ PowerBI, แพ็กเกจ SQL Server Data Tools BI เป็นต้น)
• จำเป็นต้องมีพื้นที่จัดเก็บเพิ่มเติมเพื่อให้ผู้ใช้ทุกคนมีสำเนาประวัติโค้ดเบสทั้งหมด^{[ 7 ]}
• ความเสี่ยงต่อช่องโหว่ในโค้ดเพิ่มมากขึ้น เนื่องจากผู้เข้าร่วมทุกคนมีสำเนาโค้ดที่มีช่องโหว่อยู่ในเครื่องของตนเอง

ระบบบางระบบที่เดิมทีเป็นระบบรวมศูนย์ ปัจจุบันได้นำเสนอคุณสมบัติแบบกระจายศูนย์บางส่วนแล้ว ตัวอย่างเช่นTeam Foundation Serverและ Visual Studio Team Services ปัจจุบันรองรับทั้งที่เก็บข้อมูลการควบคุมเวอร์ชันแบบรวมศูนย์และแบบกระจายศูนย์ผ่านการโฮสต์ Git

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

โดยทั่วไปแล้วโมเดลแบบกระจายจะเหมาะสมกว่าสำหรับโครงการขนาดใหญ่ที่มีนักพัฒนาอิสระบางส่วน เช่นLinux Kernelโมเดลนี้ช่วยให้นักพัฒนาสามารถทำงานในสาขาอิสระและใช้การเปลี่ยนแปลงที่สามารถคอมมิต ตรวจสอบ และผสาน (หรือปฏิเสธ) ^{[ 9 ]}โดยผู้อื่นได้ในภายหลัง โมเดลนี้ช่วยให้มีความยืดหยุ่นมากขึ้นและอนุญาตให้สร้างและปรับเปลี่ยนสาขาซอร์สโค้ดที่กำหนดเอง ( forks ) ซึ่งวัตถุประสงค์อาจแตกต่างจากโครงการดั้งเดิม นอกจากนี้ยังช่วยให้นักพัฒนาสามารถโคลนที่เก็บโค้ดที่มีอยู่และทำงานในสภาพแวดล้อมท้องถิ่นซึ่งการเปลี่ยนแปลงจะถูกติดตามและคอมมิตไปยังที่เก็บโค้ดท้องถิ่น^{[ 10 ]}ทำให้สามารถติดตามการเปลี่ยนแปลงได้ดีขึ้นก่อนที่จะคอมมิตไปยังสาขาหลักของที่เก็บโค้ด แนวทางดังกล่าวช่วยให้นักพัฒนาสามารถทำงานในสาขาท้องถิ่นและไม่เชื่อมต่อกัน ทำให้สะดวกยิ่งขึ้นสำหรับทีมแบบกระจายขนาดใหญ่

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

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

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

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

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

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

ระบบ DVCS แบบโอเพนซอร์สรุ่นแรกๆ ได้แก่Arch , MonotoneและDarcsอย่างไรก็ตาม ระบบ DVCS แบบโอเพนซอร์สไม่ได้รับความนิยมมากนักจนกระทั่งมีการเปิดตัว GitและMercurial

BitKeeperถูกใช้ในการพัฒนาเคอร์เนล Linuxตั้งแต่ปี 2002 ถึง 2005 ^{[ 15 ]}การพัฒนาGitซึ่งปัจจุบันเป็นระบบควบคุมเวอร์ชันที่ได้รับความนิยมมากที่สุดในโลก^{[ 4 ]}เกิดขึ้นจากการตัดสินใจของบริษัทผู้ผลิต BitKeeper ที่จะยกเลิกใบอนุญาตฟรีที่ Linus Torvalds และนักพัฒนาเคอร์เนล Linux คนอื่นๆ เคยใช้ประโยชน์มาก่อน^{[ 15 ]}

• เรียงความเกี่ยวกับระบบควบคุมการแก้ไขต่างๆโดยเฉพาะส่วน "ระบบควบคุมเวอร์ชันแบบรวมศูนย์เทียบกับแบบกระจายศูนย์"
• บทนำเกี่ยวกับระบบควบคุมเวอร์ชันแบบกระจาย - บทความจาก IBM Developer Works