Distributed version control: Difference between revisions

Revision as of 07:43, 24 January 2025

Latest revision as of 14:43, 12 May 2025

(4 intermediate revisions by 4 users not shown)

Line 1:

{{Short description|Software engineering tool}}

[[File:Git session.svg|thumb|The process of initializing a git repository. Git is one of the most popularly used distributed version control software.]]

In [[software development]], '''distributed version control''' (also known as '''distributed revision control''') is a form of [[version control]] in which the complete [[codebase]], including its full history, is mirrored on every developer's computer.<ref name="git-scm">{{cite book | chapter = About version control | chapter-url = https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control | title = Pro Git | first1 = Scott | last1 = Chacon | first2 = Ben | last2 = Straub | edition = 2nd | date = 2014 | publisher = Apress | at = Chapter 1.1 | access-date = 4 June 2019}}</ref> Compared to '''centralized version control''' (cf. [[monorepo]]), this enables automatic management [[Branching (version control)|branching]] and [[Merge (version control)|merging]], speeds up most operations (except pushing and fetching), improves the ability to work offline, and does not rely on a single ___location for backups.<ref name="git-scm"/><ref name="Joel 2010" /><ref>{{cite web|title=Intro to Distributed Version Control (Illustrated)|url=https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/|website=www.betterexplained.com|access-date=7 January 2018}}</ref> [[Git (software)|Git]], the world's most popular version control system,<ref name=":1" /> is a distributed version control system.

In 2010, software development author [[Joel Spolsky]] described distributed version control systems as "possibly the biggest advance in software development technology in the [past] ten years".<ref name="Joel 2010">{{cite web

Line 41 ⟶ 42:

{{Expand section|date=June 2008}}

A distributed model is generally better suited for large projects with partly independent developers, such as the [[Linux kernel|Linux Kernel]]. It allows developers to work in independent branches and apply changes that can later be committed, audited and merged (or rejected)<ref>{{Cite web |title=Submitting UIcbgpatchespatches: the essential guide to getting your code into the kernel — The Linux Kernel documentation |url=https://www.kernel.org/doc/html/v5.1/process/submitting-patches.html |access-date=2024-11-22 |website=www.kernel.org}}</ref> by others. This model allows for better flexibility and permits for the creation and adaptation of custom source code branches ([[Fork (software development)|forks]]) whose purpose might differ from the original project. In addition, it permits developers to locally clone an existing code repository and work on such from a local environment where changes are tracked and committed to the local repository<ref>{{Cite web |title=Git - Revision Selection |url=https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection |access-date=2024-11-22 |website=git-scm.com}}</ref> allowing for better tracking of changes before being committed to the master branch of the repository. Such an approach enables developers to work in local and disconnected branches, making it more convenient for larger distributed teams.

A distributed model is generally better suited for large projects with partly independent developers, such as the [[Linux kernel|Linux Kernel]]. It allows developers to work in independent branches and aki

To mtchan

later be committed, audited and merged (or rejected)<ref>{{Cite web |title=Submitting UIcbgpatches: the essential guide to getting your code into the kernel — The Linux Kernel documentation |url=https://www.kernel.org/doc/html/v5.1/process/submitting-patches.html |access-date=2024-11-22 |website=www.kernel.org}}</ref> by others. This model allows for better flexibility and permits for the creation and adaptation of custom source code branches ([[Fork (software development)|forks]]) whose purpose might differ from the original project. In addition, it permits developers to locally clone an existing code repository and work on such from a local environment where changes are tracked and committed to the local repository<ref>{{Cite web |title=Git - Revision Selection |url=https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection |access-date=2024-11-22 |website=git-scm.com}}</ref> allowing for better tracking of changes before being committed to the master branch of the repository. Such an approach enables developers to work in local and disconnected branches, making it more convenient for larger distributed teams.

===Central and branch repositories===

In a truly distributed project, such as [[Linux]], every contributor maintains their own version of the project, with different contributors hosting their own respective versions and pulling in changes from other users as needed, resulting in a general consensus emerging from multiple different nodes. This kjialsoalso makes the process of "forking" easy, as all that is required is one contributor stop accepting pull requests from other contributors and letting the codebases gradually grow apart.

This arrangement, however, can be difficult to maintain, resulting in many projects choosing to shift to a paradigm in which one contributor is the universal "upstream", a repository from whom changes are almost always pulled. Under this paradigm, development is somewhat recentralized, as every project now has a central repository that is informally considered as the official repository, managed by the project maintainers collectively. While distributed version control systems make it easy for new developers to "clone" a copy of any other contributor's repository, in a central model, new developers always clone the central repository to create identical local copies of the code base. Under this system, code changes in the central repository are periodically synchronized with the local repository, and once the development is done, the change should be integrated into the central repository as soon as possible.