Distributed version control: Difference between revisions

Revision as of 16:23, 14 April 2024

Latest revision as of 14:43, 12 May 2025

(20 intermediate revisions by 17 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''', this enables automatic management [[Branching (version control)|branching]] and [[Merge (version control)|merging]], speeds up most operations (except pushing and pullingfetching), 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 12 ⟶ 13:

==Distributed vs. centralized==

Distributed version control systems (DVCS) use a [[peer-to-peer]] approach to [[version control]], as opposed to the [[client–server model|client–server]] approach of centralized systems. Distributed revision control synchronizes repositories by transferring [[Patch (Unix)|patches]] from peer to peer. There is no single central version of the codebase; instead, each user has a working copy and the full change history.

'''Advantages of DVCS (compared with centralized systems) include:'''

* Allows users to work productively when not connected to a network.

* Common operations (such as commits, viewing history, and reverting changes) are faster for DVCS, because there is no need to communicate with a central server.<ref name='OSullivan'>{{cite web

Line 28 ⟶ 29:

* On [[FOSS]] software projects it is much easier to create a [[Fork (software development)|project fork]] from a project that is stalled because of leadership conflicts or design disagreements.

'''Disadvantages of DVCS (compared with centralized systems) include:'''

* Initial checkout of a repository is slower as compared to checkout in a centralized version control system, because all branches and revision history are copied to the local machine by default.

* The lack of locking mechanisms that is part of most centralized VCS and still plays an important role when it comes to non-mergeable binary files such as graphic assets or too complex single file binary or XML packages (e.g. office documents, PowerBI files, SQL Server Data Tools BI packages, etc.).{{citation needed|date=January 2018}}

Line 41 ⟶ 42:

{{Expand section|date=June 2008}}

TheA distributed model is generally better suited for large projects with partly independent developers, such as the [[Linux kernel|Linux project,Kernel]]. becauseIt allows developers canto work independentlyin andindependent submitbranches theirand apply changes forthat mergecan (orlater rejection).be Thiscommitted, flexibilityaudited allowsand adoptingmerged custom(or sourcerejected)<ref>{{Cite codeweb contribution|title=Submitting workflows, such aspatches: the [[integratoressential workflow]],guide whichto isgetting theyour mostcode widely used.Unlikeinto the centralizedkernel model— whereThe developersLinux mustKernel serializedocumentation their|url=https://www.kernel.org/doc/html/v5.1/process/submitting-patches.html work|access-date=2024-11-22 to|website=www.kernel.org}}</ref> avoidby problemsothers. withThis differentmodel versions,allows infor thebetter distributedflexibility model,and developerspermits can clonefor the entirecreation and historyadaptation of thecustom source code tobranches their([[Fork local(software machines.development)|forks]]) Theywhose commitpurpose theirmight changesdiffer tofrom theirthe localoriginal project. repositoriesIn firstaddition, creatingit 'changepermits sets,'developers beforeto pushinglocally themclone toan theexisting mastercode repository. Thisand approachwork enableson developerssuch tofrom worka locallylocal andenvironment disconnected,where makingchanges itare moretracked convenientand forcommitted distributedto teams.the local repository<ref>{{Cite web |last=Upadhaye |first=Annu |date=22 Feb 2023 |title=CentralizedGit vs Distributed- VersionRevision ControlSelection |url=https://wwwgit-scm.geeksforgeeks.orgcom/centralizedbook/en/v2/Git-vsTools-distributedRevision-version-control-which-one-should-we-choose/Selection |access-date=4 April 2024-11-22 |website=GFGgit-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===

Line 74 ⟶ 75:

* [[BitKeeper]]

* [[GNU Bazaar]]

* [[Darcs]]

* [[Concurrent Versions System]], a predecessor of distributed version control systems

* [[TortoiseHg]], a graphical interface for Mercurial