Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Version control
open-in-new
<h2 id="overview">Overview</h2> <p>As teams develop software, it is common to <a href="/facts/Software_deployment/9yMpwGTu">deploy</a> multiple versions of the same software, and for different developers to work on one or more different versions simultaneously. <a href="/facts/Software_bug/I1uSXySv">Bugs</a> or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program develops). Therefore, for the purposes of locating and fixing bugs, it is vitally important to be able to retrieve and run different versions of the software to determine in which version(s) the problem occurs. It may also be necessary to develop two versions of the software concurrently: for instance, where one version has bugs fixed, but no new features (<a href="/facts/Branching_(revision_control)/1m0qK9tv">branch</a>), while the other version is where new features are worked on (<a href="/facts/Trunk_(software)/AhNovaNw">trunk</a>). </p><p>At the simplest level, developers could simply retain multiple copies of the different versions of the program, and label them appropriately. This simple approach has been used in many large software projects. While this method can work, it is inefficient as many near-identical copies of the program have to be maintained. This requires a lot of self-discipline on the part of developers and often leads to mistakes. Since the code base is the same, it also requires granting read-write-execute permission to a set of developers, and this adds the pressure of someone managing permissions so that the code base is not compromised, which adds more complexity. Consequently, systems to automate some or all of the revision control process have been developed. This <a href="/facts/Abstraction_(computer_science)/hAnxmJle">abstracts</a> most operational steps (hides them from ordinary users). </p><p>Moreover, in software development, legal and business practice, and other environments, it has become increasingly common for a single document or snippet of code to be edited by a team, the members of which may be geographically dispersed and may pursue different and even contrary interests. Sophisticated revision control that tracks and accounts for ownership of changes to documents and code may be extremely helpful or even indispensable in such situations. </p><p>Revision control may also track changes to <a href="/facts/Configuration_files/DDzU0FLJ">configuration files</a>, such as those typically stored in /etc or /usr/local/etc on <a href="/facts/Unix/0pNL2seI">Unix</a> systems. This gives system administrators another way to easily track changes made and a way to roll back to earlier versions should the need arise. </p><p>Many version control systems identify the version of a file as a number or letter, called the <i>version number</i>, <i>version</i>, <i>revision number</i>, <i>revision</i>, or <i>revision level</i>. For example, the first version of a file might be version <i>1</i>. When the file is changed the next version is <i>2</i>. Each version is associated with a <a href="/facts/Timestamp/6lApANE6">timestamp</a> and the person making the change. Revisions can be compared, restored, and, with some types of files, merged.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> </p> <h2 id="history">History</h2> <p class="note">See also: <a href="/facts/Comparison_of_version_control_software/prfPW9sV">Comparison of version control software § History and adoption</a></p> <p>IBM's OS/360 <a href="/facts/Support_programs_for_OS%2f360_and_successors/d0kWFFAf">IEBUPDTE</a> software update tool dates back to 1962, arguably a precursor to version control system tools. Two source management and version control packages that were heavily used by IBM 360/370 installations were <a href="/facts/The_Librarian_(version_control_system)/AojrndyX">The Librarian</a> and <a href="/facts/Panvalet/Q5YGPQ8R">Panvalet</a>.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a><a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p><p>A full system designed for source code control was started in 1972: the <a href="/facts/Source_Code_Control_System/v85GIeBx">Source Code Control System</a> (SCCS), again for the OS/360. SCCS's user manual, especially the introduction, which was published on December 4, 1975, implied that it was the first deliberate revision control system.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> The <a href="/facts/Revision_Control_System/9rHoEV5Y">Revision Control System</a> (RCS) followed in 1982<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> and, later, <a href="/facts/Concurrent_Versions_System/PKnqSra2">Concurrent Versions System</a> (CVS) added network and concurrent development features to RCS. After CVS, a dominant successor was <a href="/facts/Apache_Subversion/b5j9wAbt">Subversion</a>,<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> followed by the rise of <a href="/facts/Distributed_version_control/PDAlqzRE">distributed version control</a> tools such as <a href="/facts/Git/U5Ty9QmQ">Git</a>.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> </p> <h2 id="structure">Structure</h2> <p>Revision control manages changes to a set of data over time. These changes can be structured in various ways. </p><p>Often the data is thought of as a collection of many individual items, such as files or documents, and changes to individual files are tracked. This accords with intuitions about separate files but causes problems when identity changes, such as during renaming, splitting or merging of files. Accordingly, some systems such as <a href="/facts/Git/U5Ty9QmQ">Git</a>, instead consider changes to the data as a whole, which is less intuitive for simple changes but simplifies more complex changes. </p><p>When data that is under revision control is modified, after being retrieved by <i>checking out,</i> this is not in general immediately reflected in the revision control system (in the <i>repository</i>), but must instead be <i>checked in</i> or <i>committed.</i> A copy outside revision control is known as a "working copy". As a simple example, when editing a computer file, the data stored in memory by the editing program is the working copy, which is committed by saving. Concretely, one may print out a document, edit it by hand, and only later manually input the changes into a computer and save it. For source code control, the working copy is instead a copy of all files in a particular revision, generally stored locally on the developer's computer;<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> in this case saving the file only changes the working copy, and checking into the repository is a separate step. </p><p>If multiple people are working on a single data set or document, they are implicitly creating branches of the data (in their working copies), and thus issues of merging arise, as discussed below. For simple collaborative document editing, this can be prevented by using <a href="/facts/File_locking/QektVCQs">file locking</a> or simply avoiding working on the same document that someone else is working on. </p><p>Revision control systems are often centralized, with a single authoritative data store, the <i>repository,</i> and check-outs and check-ins done with reference to this central repository. Alternatively, in <a href="/facts/Distributed_revision_control/PDAlqzRE">distributed revision control</a>, no single repository is authoritative, and data can be checked out and checked into any repository. When checking into a different repository, this is interpreted as a merge or patch. </p> <h3>Graph structure</h3> <p>In terms of <a href="/facts/Graph_theory/VVPCd4TX">graph theory</a>, revisions are generally thought of as a line of development (the <i>trunk</i>) with branches off of this, forming a directed tree, visualized as one or more parallel lines of development (the "mainlines" of the branches) branching off a trunk. In reality the structure is more complicated, forming a <a href="/facts/Directed_acyclic_graph/k6zq1os9">directed acyclic graph</a>, but for many purposes "tree with merges" is an adequate approximation. </p><p>Revisions occur in sequence over time, and thus can be arranged in order, either by revision number or timestamp.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> Revisions are based on past revisions, though it is possible to largely or completely replace an earlier revision, such as "delete all existing text, insert new text". In the simplest case, with no branching or undoing, each revision is based on its immediate predecessor alone, and they form a simple line, with a single latest version, the "HEAD" revision or <i>tip</i>. In <a href="/facts/Graph_theory/VVPCd4TX">graph theory</a> terms, drawing each revision as a point and each "derived revision" relationship as an arrow (conventionally pointing from older to newer, in the same direction as time), this is a <a href="/facts/Linear_graph/4Y2f35eM">linear graph</a>. If there is branching, so multiple future revisions are based on a past revision, or undoing, so a revision can depend on a revision older than its immediate predecessor, then the resulting graph is instead a <a href="/facts/Directed_tree/TCWk4Joy">directed tree</a> (each node can have more than one child), and has multiple tips, corresponding to the revisions without children ("latest revision on each branch").<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> In principle the resulting tree need not have a preferred tip ("main" latest revision) – just various different revisions – but in practice one tip is generally identified as HEAD. When a new revision is based on HEAD, it is either identified as the new HEAD, or considered a new branch.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> The list of revisions from the start to HEAD (in graph theory terms, the unique path in the tree, which forms a linear graph as before) is the <i>trunk</i> or <i>mainline.</i><a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> Conversely, when a revision can be based on more than one previous revision (when a node can have more than one <i>parent</i>), the resulting process is called a <i><a href="/facts/Merge_(revision_control)/776L9Du9">merge</a>,</i> and is one of the most complex aspects of revision control. This most often occurs when changes occur in multiple branches (most often two, but more are possible), which are then merged into a single branch incorporating both changes. If these changes overlap, it may be difficult or impossible to merge, and require manual intervention or rewriting. </p><p>In the presence of merges, the resulting graph is no longer a tree, as nodes can have multiple parents, but is instead a rooted <a href="/facts/Directed_acyclic_graph/k6zq1os9">directed acyclic graph</a> (DAG). The graph is acyclic since parents are always backwards in time, and rooted because there is an oldest version. Assuming there is a trunk, merges from branches can be considered as "external" to the tree – the changes in the branch are packaged up as a <i>patch,</i> which is applied to HEAD (of the trunk), creating a new revision without any explicit reference to the branch, and preserving the tree structure. Thus, while the actual relations between versions form a DAG, this can be considered a tree plus merges, and the trunk itself is a line. </p><p>In distributed revision control, in the presence of multiple repositories these may be based on a single original version (a root of the tree), but there need not be an original root - instead there can be a separate root (oldest revision) for each repository. This can happen, for example, if two people start working on a project separately. Similarly, in the presence of multiple data sets (multiple projects) that exchange data or merge, there is no single root, though for simplicity one may think of one project as primary and the other as secondary, merged into the first with or without its own revision history. </p> <h2 id="specialized-strategies">Specialized strategies</h2> <p>Engineering revision control developed from formalized processes based on tracking revisions of early blueprints or <a href="/facts/Whiteprint/XcLmUA8D">bluelines</a>. This system of control implicitly allowed returning to an earlier state of the design, for cases in which an engineering dead-end was reached in the development of the design. A revision table was used to keep track of the changes made. Additionally, the modified areas of the drawing were highlighted using revision clouds. </p> <h3>In business and law</h3> <p>Version control is widespread in business and law. Indeed, "contract redline" and "legal blackline" are some of the earliest forms of revision control,<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> and are still employed in business and law with varying degrees of sophistication. The most sophisticated techniques are beginning to be used for the electronic tracking of changes to <a href="/facts/CAD_file/5gSXrmmN">CAD files</a> (see <a href="/facts/Product_data_management/9ATPbmAz">product data management</a>), supplanting the "manual" electronic implementation of traditional revision control. </p> <h2 id="source-management-models">Source-management models</h2> <p>Traditional revision control systems use a centralized model where all the revision control functions take place on a shared <a href="/facts/Server_(computing)/dEaYFD7r">server</a>. If two developers try to change the same file at the same time, without some method of managing access the developers may end up overwriting each other's work. Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging. </p> <h3>Atomic operations</h3> <p class="note">Main article: <a href="/facts/Atomic_commit/hnapELwd">Atomic commit</a></p> <p>An operation is <i>atomic</i> if the system is left in a consistent state even if the operation is interrupted. The <i>commit</i> operation is usually the most critical in this sense. Commits tell the revision control system to make a group of changes final, and available to all users. Not all revision control systems have atomic commits; Concurrent Versions System lacks this feature.<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> </p> <h3>File locking</h3> <p>The simplest method of preventing "<a href="/facts/Concurrent_access/JWnmhVd5">concurrent access</a>" problems involves <a href="/facts/File_locking/QektVCQs">locking files</a> so that only one developer at a time has write access to the central "<a href="/facts/Repository_(version_control)/PjE4Vkes">repository</a>" copies of those files. Once one developer "checks out" a file, others can read that file, but no one else may change that file until that developer "checks in" the updated version (or cancels the checkout). </p><p>File locking has both merits and drawbacks. It can provide some protection against difficult merge conflicts when a user is making radical changes to many sections of a large file (or group of files). If the files are left exclusively locked for too long, other developers may be tempted to bypass the revision control software and change the files locally, forcing a difficult manual merge when the other changes are finally checked in. In a large organization, files can be left "checked out" and locked and forgotten about as developers move between projects - these tools may or may not make it easy to see who has a file checked out. </p> <h3>Version merging</h3> <p class="note">Main article: <a href="/facts/Merge_(version_control)/776L9Du9">Merge (version control)</a></p> <p>Most version control systems allow multiple developers to edit the same file at the same time. The first developer to "check in" changes to the central repository always succeeds. The system may provide facilities to <a href="/facts/Merge_(revision_control)/776L9Du9">merge</a> further changes into the central repository, and preserve the changes from the first developer when other developers check in. </p><p>Merging two files can be a very delicate operation, and usually possible only if the data structure is simple, as in <a href="/facts/Text_file/zYW4JmES">text files</a>. The result of a merge of two <a href="/facts/Image_file/tLGQogv3">image files</a> might not result in an image file at all. The second developer checking in the code will need to take care with the merge, to make sure that the changes are compatible and that the merge operation does not introduce its own <a href="/facts/Logic/8JnpJLtt">logic</a> errors within the files. These problems limit the availability of automatic or semi-automatic merge operations mainly to simple text-based documents, unless a specific merge <a href="/facts/Plug-in_(computing)/351Du3Wu">plugin</a> is available for the file types. </p><p>The concept of a <i>reserved edit</i> can provide an optional means to explicitly lock a file for exclusive write access, even when a merging capability exists. </p> <h3>Baselines, labels and tags</h3> <p>Most revision control tools will use only one of these similar terms (baseline, label, tag) to refer to the action of identifying a snapshot ("label the project") or the record of the snapshot ("try it with baseline <i>X</i>"). Typically only one of the terms <i>baseline</i>, <i>label</i>, or <i>tag</i> is used in documentation or discussion; they can be considered synonyms. </p><p>In most projects, some snapshots are more significant than others, such as those used to indicate published releases, branches, or milestones. </p><p>When both the term <i>baseline</i> and either of <i>label</i> or <i>tag</i> are used together in the same context, <i>label</i> and <i>tag</i> usually refer to the mechanism within the tool of identifying or making the record of the snapshot, and <i>baseline</i> indicates the increased significance of any given label or tag. </p><p>Most formal discussion of <a href="/facts/Configuration_management/BRDwuKRk">configuration management</a> uses the term <a href="/facts/Baseline_(configuration_management)/n7vaav6A"><i>baseline</i></a>. </p> <h2 id="distributed-revision-control">Distributed revision control</h2> <p class="note">Main article: <a href="/facts/Distributed_version_control/PDAlqzRE">Distributed version control</a></p> <p>Distributed revision control systems (DRCS) take a peer-to-peer approach, as opposed to the <a href="/facts/Client%25E2%2580%2593server_model/FSnf27C5">client–server</a> approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a <a href="/facts/Good_faith/oSeufTYc">bona-fide</a> repository.<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> Distributed revision control conducts synchronization by exchanging <a href="/facts/Patch_(computing)/sIHVBPls">patches</a> (change-sets) from peer to peer. This results in some important differences from a centralized system: </p> <ul><li>No canonical, reference copy of the codebase exists by default; only working copies.</li> <li>Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a>: 7 </li></ul> <p>Rather, communication is only necessary when pushing or pulling changes to or from other peers. </p> <ul><li>Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a>: 4 </li></ul> <h2 id="best-practices">Best practices</h2> <p>Following best practices is necessary to obtain the full benefits of version control. Best practice may vary by version control tool and the field to which version control is applied. The generally accepted best practices in <a href="/facts/Software_development/UUfsAaYY">software development</a> include: making incremental, small, changes; making <a href="/facts/Commit_(version_control)/4jfSuklB">commits</a> which involve only one task or fix -- a corollary to this is to commit only code which works and does not knowingly break existing functionality; utilizing branching to complete functionality before release; writing clear and descriptive commit messages, make what why and how clear in either the commit description or the code; and using a consistent branching strategy.<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a> Other best software development practices such as <a href="/facts/Code_review/1I93ffGF">code review</a> and automated <a href="/facts/Regression_testing/37GwvbAS">regression testing</a> may assist in the following of version control best practices. </p> <h2 id="costs-and-benefits">Costs and benefits</h2> <p>Costs and benefits will vary dependent upon the version control tool chosen and the field in which it is applied. This section speaks to the field of software development, where version control is widely applied. </p> <h3>Costs</h3> <p>In addition to the costs of licensing the version control software, using version control requires time and effort. The concepts underlying version control must be understood and the technical particulars required to operate the version control software chosen must be learned. Version control best practices must be learned and integrated into the organization's existing software development practices. Management effort may be required to maintain the discipline needed to follow best practices in order to obtain useful benefit. </p> <h3>Benefits</h3> <h4>Allows for reverting changes</h4> <p>A core benefit is the ability to keep history and revert changes, allowing the developer to easily undo changes. This gives the developer more opportunity to experiment, eliminating the fear of breaking existing code.<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a> </p> <h4>Branching simplifies deployment, maintenance and development</h4> <p>Branching assists with deployment. Branching and merging, the production, packaging, and labeling of source code <a href="/facts/Patch_(computing)/sIHVBPls">patches</a> and the easy application of patches to code bases, simplifies the maintenance and concurrent development of the multiple code bases associated with the various stages of the deployment process; development, testing, staging, production, etc.<a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a> </p> <h4>Damage mitigation, accountability and process and design improvement</h4> <p>There can be damage mitigation, accountability, process and design improvement, and other benefits associated with the record keeping provided by version control, the tracking of who did what, when, why, and how.<a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a> </p><p>When bugs arise, knowing what was done when helps with damage mitigation and recovery by assisting in the identification of what problems exist, how long they have existed, and determining problem scope and solutions.<a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> Previous versions can be installed and tested to verify conclusions reached by examination of code and commit messages.<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a> </p> <h4>Simplifies debugging</h4> <p>Version control can greatly simplify debugging. The application of a test case to multiple versions can quickly identify the change which introduced a bug.<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a> The developer need not be familiar with the entire code base and can focus instead on the code that introduced the problem. </p> <h4>Improves collaboration and communication</h4> <p>Version control enhances collaboration in multiple ways. Since version control can identify conflicting changes, i.e. incompatible changes made to the same lines of code, there is less need for coordination among developers.<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a> </p><p>The packaging of commits, branches, and all the associated commit messages and version labels, improves communication between developers, both in the moment and over time.<a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a> Better communication, whether instant or deferred, can improve the code review process, the testing process, and other critical aspects of the software development process. </p> <h2 id="integration">Integration</h2> <p>Some of the more advanced revision-control tools offer many other facilities, allowing deeper integration with other tools and software-engineering processes. </p> <h3>Integrated development environment</h3> <p><a href="/facts/Plug-in_(computing)/351Du3Wu">Plugins</a> are often available for <a href="/facts/Integrated_development_environment/jbEINSQf">IDEs</a> such as <a href="/facts/Oracle_JDeveloper/mehgK5Dj">Oracle JDeveloper</a>, <a href="/facts/IntelliJ_IDEA/h689XrQz">IntelliJ IDEA</a>, <a href="/facts/Eclipse_(computing)/YoqHVjas">Eclipse</a>, <a href="/facts/Visual_Studio/omNe6Lej">Visual Studio</a>, <a href="/facts/Delphi_(programming_language)/sUFUXQ8r">Delphi</a>, <a href="/facts/NetBeans/9kqvIVFG">NetBeans IDE</a>, <a href="/facts/Xcode/glURdIVT">Xcode</a>, and <a href="/facts/GNU_Emacs/MPxf7qRC">GNU Emacs</a> (via vc.el). Advanced research prototypes generate appropriate commit messages.<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a> </p> <h2 id="common-terminology">Common terminology</h2> <p>Terminology can vary from system to system, but some terms in common usage include:<a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> </p> <h3>Baseline</h3> <p class="note">Main article: <a href="/facts/Baseline_(configuration_management)/n7vaav6A">Baseline (configuration management)</a></p> <p>An approved revision of a document or source file to which subsequent changes can be made. See baselines, labels and tags. </p> <h3>Blame</h3> <p>A search for the author and revision that last modified a particular line. </p> <h3>Branch</h3> <p class="note">Main article: <a href="/facts/Branching_(revision_control)/1m0qK9tv">Branching (revision control)</a></p> <p>A set of files under version control may be <i>branched</i> or <i>forked</i> at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other. </p> <h3>Change</h3> <p>A <i>change</i> (or <i><a href="/facts/Diff/MtzRWwql">diff</a></i>, or <i><a href="/facts/Delta_encoding/2NQlyAUc">delta</a></i>) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems. </p> <h3>Change list</h3> <p>On many version control systems with <a href="/facts/Atomic_transaction/A356GsoW">atomic</a> multi-change commits, a <i>change list</i> (or <i>CL</i>), <i>change set</i>, <i>update</i>, or <i><a href="/facts/Patch_(computing)/sIHVBPls">patch</a></i> identifies the set of <i>changes</i> made in a single commit. This can also represent a sequential view of the source code, allowing the examination of source as of any particular changelist ID. </p> <h3>Checkout</h3> <p>To <i>check out</i> (or <i>co</i>) is to create a local working copy from the repository. A user may specify a specific revision or obtain the latest. The term 'checkout' can also be used as a noun to describe the working copy. When a file has been checked out from a shared file server, it cannot be edited by other users. Think of it like a hotel, when you check out, you no longer have access to its amenities. </p> <h3>Clone</h3> <p><i>Cloning</i> means creating a repository containing the revisions from another repository. This is equivalent to <i>push</i>ing or <i>pull</i>ing into an empty (newly initialized) repository. As a noun, two repositories can be said to be <i>clone</i>s if they are kept synchronized, and contain the same revisions. </p> <h3>Commit (noun)</h3> <p class="note">This section is an excerpt from <a href="/facts/Changeset/zPvGrzmF">Changeset</a>.[<a href="https://en.wikipedia.org/w/index.php?title=Changeset&action=edit">edit</a>]</p> In version control software, a <a href="/facts/Changeset/zPvGrzmF">changeset</a> (also known as commit<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a> and revision<a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a><a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a>) is a set of alterations packaged together, along with meta-information about the alterations. A changeset describes the exact differences between two successive versions in the version control system's repository of changes. Changesets are typically treated as an <a href="/facts/Atomicity_(database_systems)/A356GsoW">atomic</a> unit, an indivisible set, by version control systems. This is one <a href="/facts/Synchronization_model/CPyUTwf7">synchronization model</a>.<a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a><a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a> <h3>Commit (verb)</h3> <p class="note">Main article: <a href="/facts/Commit_(revision_control)/4jfSuklB">Commit (revision control)</a></p> <p>To <i><a href="/facts/Commit_(revision_control)/4jfSuklB">commit</a></i> (<i>check in</i>, <i>ci</i> or, more rarely, <i>install</i>, <i>submit</i> or <i>record</i>) is to write or merge the changes made in the working copy back to the repository. A commit contains metadata, typically the author information and a commit message that describes the change. </p> <h3>Commit message</h3> <p>A short note, written by the developer, stored with the commit, which describes the commit. Ideally, it records why the modification was made, a description of the modification's effect or purpose, and non-obvious aspects of how the change works. </p> <h3>Conflict</h3> <p>A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must <i>resolve</i> the conflict by combining the changes, or by selecting one change in favour of the other. </p> <h3>Delta compression</h3> <p class="note">Main article: <a href="/facts/Delta_compression/2NQlyAUc">Delta compression</a></p> <p>Most revision control software uses <a href="/facts/Delta_compression/2NQlyAUc">delta compression</a>, which retains only the differences between successive versions of files. This allows for more efficient storage of many different versions of files. </p> <h3>Dynamic stream</h3> <p>A stream in which some or all file versions are mirrors of the parent stream's versions. </p> <h3>Export</h3> <p><i>Exporting</i> is the act of obtaining the files from the repository. It is similar to <i>checking out</i> except that it creates a clean directory tree without the version-control metadata used in a working copy. This is often used prior to publishing the contents, for example. </p> <h3>Fetch</h3> <p>See <i>pull</i>. </p> <h3>Forward integration</h3> <p>The process of merging changes made in the main <i>trunk</i> into a development (feature or team) branch. </p> <h3>Head</h3> <p>Also sometimes called <i>tip</i>, this refers to the most recent commit, either to the trunk or to a branch. The trunk and each branch have their own head, though HEAD is sometimes loosely used to refer to the trunk.<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a> </p> <h3>Import</h3> <p><i>Importing</i> is the act of copying a local directory tree (that is not currently a working copy) into the repository for the first time. </p> <h3>Initialize</h3> <p>To create a new, empty repository. </p> <h3>Interleaved deltas</h3> <p>Some revision control software uses <a href="/facts/Interleaved_deltas/v99uBTEF">Interleaved deltas</a>, a method that allows storing the history of text based files in a more efficient way than by using <a href="/facts/Delta_compression/2NQlyAUc">Delta compression</a>. </p> <h3>Label</h3> <p>See <i>tag</i>. </p> <h3>Locking</h3> <p class="note">Main article: <a href="/facts/File_locking/QektVCQs">File locking</a></p> <p>When a developer <i><a href="/facts/File_locking/QektVCQs">locks</a></i> a file, no one else can update that file until it is unlocked. Locking can be supported by the version control system, or via informal communications between developers (aka <i>social locking</i>). </p> <h3>Mainline</h3> <p>Similar to <i>trunk</i>, but there can be a mainline for each branch. </p> <h3>Merge</h3> <p class="note">Main article: <a href="/facts/Merge_(revision_control)/776L9Du9">Merge (revision control)</a></p> <p>A <i>merge</i> or <i>integration</i> is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows: </p> <ul><li>A user, working on a set of files, <i>updates</i> or <i>syncs</i> their working copy with changes made, and checked into the repository, by other users.<a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a></li> <li>A user tries to <i>check in</i> files that have been updated by others since the files were <i>checked out</i>, and the <i>revision control software</i> automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved).</li> <li>A <i>branch</i> is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified <i>trunk</i>.</li> <li>A set of files is <i>branched</i>, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch. (This type of selective merge is sometimes known as a <i>cherry pick</i> to distinguish it from the complete merge in the previous case.)</li></ul> <h3>Promote</h3> <p>The act of copying file content from a less controlled location into a more controlled location. For example, from a user's workspace into a repository, or from a stream to its parent.<a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a> </p> <h3>Pull, push</h3> <p>Copy revisions from one repository into another. <i>Pull</i> is initiated by the receiving repository, while <i>push</i> is initiated by the source. <i>Fetch</i> is sometimes used as a synonym for <i>pull</i>, or to mean a <i>pull</i> followed by an <i>update</i>. </p> <h3>Pull request</h3> <p class="note">This section is an excerpt from <a href="/facts/Distributed_version_control/PDAlqzRE">Distributed version control § Pull requests</a>.[<a href="https://en.wikipedia.org/w/index.php?title=Distributed_version_control&action=edit">edit</a>]</p> <p>Contributions to a source code repository that uses a distributed version control system are commonly made by means of a pull request, also known as a merge request.<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a> The contributor requests that the project maintainer <i>pull</i> the source code change, hence the name "pull request". The maintainer has to <i>merge</i> the pull request if the contribution should become part of the source base.<a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a> </p><p>The developer creates a pull request to notify maintainers of a new change; a comment thread is associated with each pull request. This allows for <a href="/facts/Code_review/1I93ffGF">focused discussion of code changes</a>. Submitted pull requests are visible to anyone with repository access. A pull request can be accepted or rejected by maintainers.<a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a> </p> Once the pull request is reviewed and approved, it is merged into the repository. Depending on the established workflow, the code may need to be tested before being included into official release. Therefore, some projects contain a special branch for merging untested pull requests.<a class="footnote-ref" id="fnref:42" href="#fn:42"><sup>42</sup></a><a class="footnote-ref" id="fnref:43" href="#fn:43"><sup>43</sup></a> Other projects run an automated test suite on every pull request, using a <a href="/facts/Continuous_integration/M4RYgSzt">continuous integration</a> tool, and the reviewer checks that any new code has appropriate test coverage. <h3>Repository</h3> <p class="note">This section is an excerpt from <a href="/facts/Repository_(version_control)/PjE4Vkes">Repository (version control)</a>.[<a href="https://en.wikipedia.org/w/index.php?title=Repository_(version_control)&action=edit">edit</a>]</p> In version control systems, a <a href="/facts/Repository_(version_control)/PjE4Vkes">repository</a> is a data structure that stores <a href="/facts/Metadata/qt35z79C">metadata</a> for a set of files or <a href="/facts/Directory_structure/t7lEWPpd">directory structure</a>.<a class="footnote-ref" id="fnref:44" href="#fn:44"><sup>44</sup></a> Depending on whether the version control system in use is distributed, like <a href="/facts/Git/U5Ty9QmQ">Git</a> or <a href="/facts/Mercurial/lEkoYb6C">Mercurial</a>, or centralized, like <a href="/facts/Apache_Subversion/b5j9wAbt">Subversion</a>, <a href="/facts/Concurrent_Versions_System/PKnqSra2">CVS</a>, or <a href="/facts/Perforce/y9wI1f6T">Perforce</a>, the whole set of information in the repository may be duplicated on every user's system or may be maintained on a single <a href="/facts/Server_(computing)/dEaYFD7r">server</a>.<a class="footnote-ref" id="fnref:45" href="#fn:45"><sup>45</sup></a> Some of the metadata that a repository contains includes, among other things, a historical record of changes in the repository, a set of commit objects, and a set of references to commit objects, called <i>heads</i>. <h3>Resolve</h3> <p>The act of user intervention to address a conflict between different changes to the same document. </p> <h3>Reverse integration</h3> <p>The process of merging different team branches into the main trunk of the versioning system. </p> <h3>Revision and version</h3> <p>A <a href="/facts/Software_versioning/EP8VXAUU">version</a> is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository. </p> <h3>Share</h3> <p>The act of making one file or folder available in multiple branches at the same time. When a shared file is changed in one branch, it is changed in other branches. </p> <h3>Stream</h3> <p>A container for branched files that has a known relationship to other such containers. Streams form a hierarchy; each stream can inherit various properties (like versions, namespace, workflow rules, subscribers, etc.) from its parent stream. </p> <h3>Tag</h3> <p class="note">Main article: <a href="/facts/Revision_tag/X72LaKLX">Revision tag</a></p><p> A <i><a href="/facts/Revision_tag/X72LaKLX">tag</a></i> or <i>label</i> refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. See baselines, labels and tags. </p><h3>Trunk</h3> <p class="note">Main article: <a href="/facts/Trunk_(software)/AhNovaNw">Trunk (software)</a></p> <p>The <a href="/facts/Trunk_(software)/AhNovaNw">trunk</a> is the unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master<a class="footnote-ref" id="fnref:46" href="#fn:46"><sup>46</sup></a><a class="footnote-ref" id="fnref:47" href="#fn:47"><sup>47</sup></a>) </p> <h3>Update</h3> <p>An <i>update</i> (or <i>sync</i>, but <i>sync</i> can also mean a combined <i>push</i> and <i>pull</i>) merges changes made in the repository (by other people, for example) into the local <i>working copy</i>. <i>Update</i> is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see <i>changelist</i>). Synonymous with <i>checkout</i> in revision control systems that require each repository to have exactly one working copy (common in distributed systems) </p> <h3>Unlocking</h3> <p>Releasing a lock. </p> <h3>Working copy</h3> <p>The <i>working copy</i> is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a <i><a href="/facts/Sandbox_(software_development)/pDfD8M6S">sandbox</a></i>. </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Change_control/c9bv6CPq">Change control</a></li> <li><a href="/facts/Changelog/5SleaUGC">Changelog</a></li> <li><a href="/facts/Blockchain/8H43GgWy">Blockchain</a></li> <li><a href="/facts/Comparison_of_version-control_software/prfPW9sV">Comparison of version-control software</a></li> <li><a href="/facts/Comparison_of_source-code-hosting_facilities/pqq0GEjT">Comparison of source-code-hosting facilities</a></li> <li><a href="/facts/Data_version_control/BdCjmuKx">Data version control</a></li> <li><a href="/facts/Distributed_version_control/PDAlqzRE">Distributed version control</a></li> <li><a href="/facts/List_of_version-control_software/gjAW2d8c">List of version-control software</a></li> <li><a href="/facts/Non-linear_editing/xN4H6gw4">Non-linear editing</a></li> <li><a href="/facts/Software_configuration_management/VReDo7g4">Software configuration management</a></li> <li><a href="/facts/Software_versioning/EP8VXAUU">Software versioning</a></li> <li><a href="/facts/Versioning_file_system/g1gDkdcN">Versioning file system</a></li></ul> <h2 id="notes">Notes</h2> <h2 id="external-links">External links</h2> <ul><li>"Visual Guide to Version Control", <a href="http://betterexplained.com/articles/a-visual-guide-to-version-control/"><i>Better explained</i></a>.</li> <li>Sink, Eric, "Source Control", <a href="http://www.ericsink.com/scm/source_control.html"><i>SCM</i></a> (how-to). The basics of version control.</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>O'Sullivan, Bryan (2009). Mercurial: the Definitive Guide. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-55547-4. Archived from the original on 8 December 2019. Retrieved 4 September 2015. <a href="978-0-596-55547-4" target="_blank">978-0-596-55547-4</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>"Google Docs", See what's changed in a file, Google Inc., archived from the original on 2022-10-06, retrieved 2021-04-21. <a href="/wiki/Google_Docs" target="_blank">/wiki/Google_Docs</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Scott, Chacon; Straub, Ben (2014). Pro Git Second Edition. United States: Apress. p. 14. Archived from the original on 2015-12-25. Retrieved 2022-02-19. <a href="https://git-scm.com/book/en/v2" target="_blank">https://git-scm.com/book/en/v2</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Goetz, Martin (May 3, 2002). "An Interview with Martin Goetz" (Interview). Interviewed by Jeffrey R. Yost. Washington, D.C.: Charles Babbage Institute, University of Minnesota. pp. 5–7. Archived from the original on September 26, 2024. Retrieved August 17, 2023. <a href="https://conservancy.umn.edu/handle/11299/107328" target="_blank">https://conservancy.umn.edu/handle/11299/107328</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Piscipo, Joseph (May 3, 2002). "An Interview with Joseph Piscopo" (Interview). Interviewed by Thomas Haigh. Washington, D.C.: Charles Babbage Institute, University of Minnesota. pp. 3, 5, 12–13. Archived from the original on September 26, 2024. Retrieved August 17, 2023. <a href="https://conservancy.umn.edu/handle/11299/107601" target="_blank">https://conservancy.umn.edu/handle/11299/107601</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Rochkind, Marc J. (1975). "The Source Code Control System" (PDF). IEEE Transactions on Software Engineering. SE-1 (4): 364–370. doi:10.1109/TSE.1975.6312866. S2CID 10006076. <a href="https://basepath.com/aup/talks/SCCS-Slideshow.pdf" target="_blank">https://basepath.com/aup/talks/SCCS-Slideshow.pdf</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Tichy, Walter F. (1985). "Rcs — a system for version control". Software: Practice and Experience. 15 (7): 637–654. doi:10.1002/spe.4380150703. ISSN 0038-0644. S2CID 2605086. Archived from the original on 2024-09-26. Retrieved 2023-12-28. <a href="https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1393&context=cstech" target="_blank">https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1393&context=cstech</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Version Control with Subversion, O'Reilly, ISBN 0-596-00448-6 <a href="0-596-00448-6" target="_blank">0-596-00448-6</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Loeliger, Jon; McCullough, Matthew (2012). Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development. O'Reilly Media. pp. 2–5. ISBN 978-1-4493-4504-4. Archived from the original on 2024-09-26. Retrieved 2023-03-22. <a href="978-1-4493-4504-4" target="_blank">978-1-4493-4504-4</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>In this case, edit buffers are a secondary form of working copy, and not referred to as such. <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>In principle two revisions can have identical timestamp, and thus cannot be ordered on a line. This is generally the case for separate repositories, though is also possible for simultaneous changes to several branches in a single repository. In these cases, the revisions can be thought of as a set of separate lines, one per repository or branch (or branch within a repository). <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>The revision or repository "tree" should not be confused with the directory tree of files in a working copy. <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>If a new branch is based on HEAD, then topologically HEAD is no longer a tip, since it has a child. <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>"Mainline" can also refer to the main path in a separate branch. <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>For Engineering drawings, see Whiteprint#Document control, for some of the manual systems in place in the twentieth century, for example, the Engineering Procedures of Hughes Aircraft, each revision of which required approval by Lawrence A. Hyland; see also the approval procedures instituted by the U.S. government. <a href="/wiki/Whiteprint#Document_control" target="_blank">/wiki/Whiteprint#Document_control</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Smart, John Ferguson (2008). Java Power Tools. "O'Reilly Media, Inc.". p. 301. ISBN 978-1-4919-5454-6. Archived from the original on 26 September 2024. Retrieved 20 July 2019. <a href="978-1-4919-5454-6" target="_blank">978-1-4919-5454-6</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>Wheeler, David. "Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems". Archived from the original on November 9, 2020. Retrieved May 8, 2007. <a href="https://web.archive.org/web/20201109022758/http://www.dwheeler.com/essays/scm.html" target="_blank">https://web.archive.org/web/20201109022758/http://www.dwheeler.com/essays/scm.html</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>O'Sullivan, Bryan (2009). Mercurial: the Definitive Guide. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-55547-4. Archived from the original on 8 December 2019. Retrieved 4 September 2015. <a href="978-0-596-55547-4" target="_blank">978-0-596-55547-4</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>O'Sullivan, Bryan (2009). Mercurial: the Definitive Guide. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-55547-4. Archived from the original on 8 December 2019. Retrieved 4 September 2015. <a href="978-0-596-55547-4" target="_blank">978-0-596-55547-4</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>GitLab. "What are Git version control best practices?". gitlab.com. Retrieved 2022-11-11. <a href="https://about.gitlab.com/topics/version-control/version-control-best-practices/" target="_blank">https://about.gitlab.com/topics/version-control/version-control-best-practices/</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>Alessandro Picarelli (2020-11-17). "The cost of not using version control". Archived from the original on 2022-11-19. Retrieved 2022-11-18. In terms of man hours it's going to cost you 6 to 48 times what it would have cost you using version control, and that's for rewinding a couple of models for a single developer. <a href="https://www.claytex.com/tech-blog/the-cost-of-not-using-version-control/" target="_blank">https://www.claytex.com/tech-blog/the-cost-of-not-using-version-control/</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Irma Azarian (2023-06-14). "A Review of Software Version Control: Systems, Benefits, and Why it Matters". Archived from the original on 2024-09-26. Retrieved 2022-11-18. Version control systems allow you to compare files, identify differences, and merge the changes if needed prior to committing any code. Versioning is also a great way to keep track of application builds by being able to identify which version is currently in development, QA, and production. <a href="https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/" target="_blank">https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>ReQtest (2020-10-26). "What Are The Benefits Of Version Control?". Archived from the original on 2022-11-22. Retrieved 2022-11-21. The history of the document provides invaluable information about the author and the date of editing. It also gives on the purpose of the changes made. It will have an impact on the developer that works on the latest version as it will help to solve problems experienced in earlier versions. The ability to identify the author of the document enables the current team to link the documents to specific contributors. This, in turn, enables the current team to uncover patterns that can help with fixing bugs. This will help to improve the overall functionality of the software. <a href="https://reqtest.com/requirements-blog/what-are-benefits-of-version-control/" target="_blank">https://reqtest.com/requirements-blog/what-are-benefits-of-version-control/</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>Chiradeep BasuMallick (2022-10-06). "What Is Version Control? Meaning, Tools, and Advantages". Archived from the original on 2022-11-19. Retrieved 2022-11-18. Software teams can understand the evolution of a solution by examining prior versions through code reviews. <a href="https://www.spiceworks.com/tech/devops/articles/what-is-version-control/" target="_blank">https://www.spiceworks.com/tech/devops/articles/what-is-version-control/</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>Chiradeep BasuMallick (2022-10-06). "What Is Version Control? Meaning, Tools, and Advantages". Archived from the original on 2022-11-19. Retrieved 2022-11-18. If an error is made, developers can go back in time and review prior iterations of the code to remedy the mistake while minimizing disturbance for all team members. <a href="https://www.spiceworks.com/tech/devops/articles/what-is-version-control/" target="_blank">https://www.spiceworks.com/tech/devops/articles/what-is-version-control/</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>Chacon, Scott; Straub, Ben (2022-10-03). "Pro Git" (Version 2.1.395-2-g27002dd ed.). Apress. Archived from the original on 2024-09-26. Retrieved 2022-11-18. The git bisect tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search. <a href="https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Debugging" target="_blank">https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Debugging</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>Irma Azarian (2023-06-14). "A Review of Software Version Control: Systems, Benefits, and Why it Matters". Archived from the original on 2024-09-26. Retrieved 2022-11-18. Versioning is a priceless process, especially when you have multiple developers working on a single application, because it allows them to easily share files. Without version control, developers will eventually step on each other's toes and overwrite code changes that someone else may have completed without even realizing it. Using these systems allows you to check files out for modifications, then, during check-in, if the files have been changed by another user, you will be alerted and allowed to merge them. <a href="https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/" target="_blank">https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>Jesse Phillips (2019-01-21) [2018-12-12]. "Git is a Communication tool". Archived from the original on 2022-11-19. Retrieved 2022-11-18. There are continued discussions on using rebase, merge, and/or squash. I want to bring focus to the point of all these choices, communicating. <a href="https://dev.to/jessekphillips/git-is-a-communication-tool--2j9k" target="_blank">https://dev.to/jessekphillips/git-is-a-communication-tool--2j9k</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo; Poshyvanyk, Denys (2014). "On Automatically Generating Commit Messages via Summarization of Source Code Changes". 2014 IEEE 14th International Working Conference on Source Code Analysis and Manipulation. IEEE. pp. 275–284. doi:10.1109/scam.2014.14. ISBN 978-1-4799-6148-1. S2CID 360545. <a href="978-1-4799-6148-1" target="_blank">978-1-4799-6148-1</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>Wingerd, Laura (2005). Practical Perforce. O'Reilly. ISBN 0-596-10185-6. Archived from the original on 2007-12-21. Retrieved 2006-08-27. <a href="0-596-10185-6" target="_blank">0-596-10185-6</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>changeset in the gitglossary <a href="https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefchangesetachangeset" target="_blank">https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefchangesetachangeset</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>revision in the gitglossary <a href="https://git-scm.com/docs/gitglossary#def_revision" target="_blank">https://git-scm.com/docs/gitglossary#def_revision</a> <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>UnderstandingMercurial - Mercurial <a href="https://mercurial.selenic.com/wiki/UnderstandingMercurial#Committing_changes" target="_blank">https://mercurial.selenic.com/wiki/UnderstandingMercurial#Committing_changes</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>Mercurial: ChangeSet Archived January 15, 2010, at the Wayback Machine <a href="http://mercurial.selenic.com/wiki/ChangeSet" target="_blank">http://mercurial.selenic.com/wiki/ChangeSet</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>"Version Control System Comparison". Better SCM Initiative. Archived from the original on 2009-03-21. <a href="https://web.archive.org/web/20090321051311/http://better-scm.berlios.de/comparison/comparison.html" target="_blank">https://web.archive.org/web/20090321051311/http://better-scm.berlios.de/comparison/comparison.html</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>Gregory, Gary (February 3, 2011). "Trunk vs. HEAD in Version Control Systems". Java, Eclipse, and other tech tidbits. Archived from the original on 2020-09-20. Retrieved 2012-12-16. <a href="http://garygregory.wordpress.com/2011/02/03/trunk-vs-head-in-version-control-systems/" target="_blank">http://garygregory.wordpress.com/2011/02/03/trunk-vs-head-in-version-control-systems/</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>Collins-Sussman, Fitzpatrick & Pilato 2004, 1.5: SVN tour cycle resolve: ‘The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.’ - Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Version Control with Subversion, O'Reilly, ISBN 0-596-00448-6 <a href="https://archive.org/details/versioncontrolwi00coll" target="_blank">https://archive.org/details/versioncontrolwi00coll</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Concepts Manual (Version 4.7 ed.). Accurev. July 2008. <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>Sijbrandij, Sytse (29 September 2014). "GitLab Flow". GitLab. Retrieved 4 August 2018. <a href="https://about.gitlab.com/2014/09/29/gitlab-flow/" target="_blank">https://about.gitlab.com/2014/09/29/gitlab-flow/</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>Johnson, Mark (8 November 2013). "What is a pull request?". Oaawatch. Retrieved 27 March 2016. <a href="http://oss-watch.ac.uk/resources/pullrequest" target="_blank">http://oss-watch.ac.uk/resources/pullrequest</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>"Using pull requests". GitHub. Retrieved 27 March 2016. <a href="https://help.github.com/articles/using-pull-requests/" target="_blank">https://help.github.com/articles/using-pull-requests/</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> <li id="fn:42"><p>Johnson, Mark (8 November 2013). "What is a pull request?". Oaawatch. Retrieved 27 March 2016. <a href="http://oss-watch.ac.uk/resources/pullrequest" target="_blank">http://oss-watch.ac.uk/resources/pullrequest</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></p></li> <li id="fn:43"><p>"Making a Pull Request". Atlassian. Retrieved 27 March 2016. <a href="https://www.atlassian.com/git/tutorials/making-a-pull-request" target="_blank">https://www.atlassian.com/git/tutorials/making-a-pull-request</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></p></li> <li id="fn:44"><p>"SVNBook". Retrieved 2012-04-20. <a href="http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.repository" target="_blank">http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.repository</a> <a href="#fnref:44" class="footnote-back-ref">↩</a></p></li> <li id="fn:45"><p>"Version control concepts and best practices". 2018-03-03. Archived from the original on 2020-04-27. Retrieved 2020-07-10. <a href="https://homes.cs.washington.edu/~mernst/advice/version-control.html" target="_blank">https://homes.cs.washington.edu/~mernst/advice/version-control.html</a> <a href="#fnref:45" class="footnote-back-ref">↩</a></p></li> <li id="fn:46"><p>Wallen, Jack (2020-09-22). "GitHub to replace master with main starting in October: What developers need to do now". TechRepublic. Archived from the original on 2021-02-08. Retrieved 2022-04-24. <a href="https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/" target="_blank">https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/</a> <a href="#fnref:46" class="footnote-back-ref">↩</a></p></li> <li id="fn:47"><p>Heinze, Carolyn (2020-11-24). "Why GitHub renamed its master branch to main". TheServerSide. Archived from the original on 2022-05-26. Retrieved 2022-04-24. <a href="https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main" target="_blank">https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main</a> <a href="#fnref:47" class="footnote-back-ref">↩</a></p></li> </ol>