Editing Version control (section)

==Common terminology==
Terminology can vary from system to system, but some terms in common usage include:<ref>{{cite book | last = Wingerd | first = Laura | title = Practical Perforce | publisher = O'Reilly | year = 2005 | url = http://safari.oreilly.com/0596101856 | isbn = 0-596-10185-6 | access-date = 2006-08-27 | archive-date = 2007-12-21 | archive-url = https://web.archive.org/web/20071221132707/http://safari.oreilly.com/0596101856 | url-status = dead }}</ref>

===Baseline===
{{Main|Baseline (configuration management)}}
An approved revision of a document or source file to which subsequent changes can be made.  See [[#Baselines, labels and tags|baselines, labels and tags]].

===Blame===
A search for the author and revision that last modified a particular line.

===Branch===
{{Main|Branching (revision control)}} 
A set of files under version control may be ''branched'' or ''forked'' 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.

===Change===
A ''change'' (or ''[[diff]]'', or ''[[Delta encoding|delta]]'') represents a specific modification to a document under version control.  The granularity of the modification considered a change varies between version control systems.

===Change list===
On many version control systems with [[atomic transaction|atomic]] multi-change commits, a ''change list'' (or ''CL''), ''change set'', ''update'', or ''[[Patch (computing)|patch]]'' identifies the set of ''changes'' 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.

===Checkout===
To ''check out'' (or ''co'') 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.

===Clone===
''Cloning'' means creating a repository containing the revisions from another repository. This is equivalent to ''push''ing or ''pull''ing into an empty (newly initialized) repository. As a noun, two repositories can be said to be ''clone''s if they are kept synchronized, and contain the same revisions.

===Commit (noun)===
{{Excerpt|Changeset}}

===Commit (verb)===
{{Main|Commit (revision control)}}
To ''[[commit (revision control)|commit]]'' (''check in'', ''ci'' or, more rarely, ''install'', ''submit'' or ''record'') 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.

===Commit message===
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.

===Conflict===
A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes.  A user must ''resolve'' the conflict by combining the changes, or by selecting one change in favour of the other.

===Delta compression===
{{Main|Delta compression}}
Most revision control software uses [[delta compression]], which retains only the differences between successive versions of files. This allows for more efficient storage of many different versions of files.

===Dynamic stream===
A stream in which some or all file versions are mirrors of the parent stream's versions.

===Export===
''Exporting'' is the act of obtaining the files from the repository. It is similar to ''checking out'' 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.

===Fetch===
See ''pull''.

===Forward integration===
The process of merging changes made in the main ''trunk'' into a development (feature or team) branch.

===Head===
Also sometimes called ''tip'', 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.<ref>{{cite web |url= http://garygregory.wordpress.com/2011/02/03/trunk-vs-head-in-version-control-systems/ |title= Trunk vs. HEAD in Version Control Systems |date= February 3, 2011 |first= Gary |last= Gregory |work= Java, Eclipse, and other tech tidbits |access-date= 2012-12-16 |archive-date= 2020-09-20 |archive-url= https://web.archive.org/web/20200920130412/https://garygregory.wordpress.com/2011/02/03/trunk-vs-head-in-version-control-systems/ |url-status= live }}</ref>

===Import===
''Importing'' is the act of copying a local directory tree (that is not currently a working copy) into the repository for the first time.

===Initialize===
To create a new, empty repository.

===Interleaved deltas===
Some revision control software uses [[Interleaved deltas]], a method that allows storing the history of text based files in a more efficient way than by using [[Delta compression]].
 
===Label===
See ''tag''.

===Locking===
{{Main|File locking}}
When a developer ''[[file locking|locks]]'' 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 ''social locking'').

===Mainline===
Similar to ''trunk'', but there can be a mainline for each branch.

===Merge===
{{Main|Merge (revision control)}}

A ''merge'' or ''integration'' is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows:
* A user, working on a set of files, ''updates'' or ''syncs'' their working copy with changes made, and checked into the repository, by other users.{{Sfn | Collins-Sussman | Fitzpatrick | Pilato | 2004 | loc = [http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve  1.5: SVN tour cycle resolve] | ps =: ‘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.’}}
* A user tries to ''check in'' files that have been updated by others since the files were ''checked out'', and the ''revision control software'' 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).
* A ''branch'' is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified ''trunk''.
* A set of files is ''branched'', 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 ''cherry pick'' to distinguish it from the complete merge in the previous case.)
===Promote===
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.<ref>{{cite book | title = Concepts Manual | edition = Version 4.7 | publisher = Accurev | date = July 2008}}</ref>
===Pull, push===
Copy revisions from one repository into another. ''Pull'' is initiated by the receiving repository, while ''push'' is initiated by the source. ''Fetch'' is sometimes used as a synonym for ''pull'', or to mean a ''pull'' followed by an ''update''.

===Pull request===
{{Excerpt|Distributed version control|Pull requests}}

===Repository===
{{Excerpt|Repository (version control)|paragraph=1}}

===Resolve===
The act of user intervention to address a conflict between different changes to the same document.

===Reverse integration===
The process of merging different team branches into the main trunk of the versioning system.

===Revision and version===
A [[Software versioning|version]] is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository.

===Share===
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.

===Stream===
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.

===Tag===
{{Main|Revision tag}} A ''[[revision tag|tag]]'' or ''label'' 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|baselines, labels and tags]].

===Trunk===
{{Main|Trunk (software)}}
The [[trunk (software)|trunk]] is the unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master<ref>{{Cite web|url=https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/|title=GitHub to replace master with main starting in October: What developers need to do now|last=Wallen|first=Jack|date=2020-09-22|website=TechRepublic|access-date=2022-04-24|archive-date=2021-02-08|archive-url=https://web.archive.org/web/20210208011318/https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/|url-status=live}}</ref><ref>{{Cite web|url=https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main|title=Why GitHub renamed its master branch to main|last=Heinze|first=Carolyn|date=2020-11-24|website=TheServerSide|access-date=2022-04-24|archive-date=2022-05-26|archive-url=https://web.archive.org/web/20220526125637/https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main|url-status=live}}</ref>)

===Update===
An ''update'' (or ''sync'', but ''sync'' can also mean a combined ''push'' and ''pull'') merges changes made in the repository (by other people, for example) into the local ''working copy''.  ''Update'' is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see ''changelist''). Synonymous with ''checkout'' in revision control systems that require each repository to have exactly one working copy (common in distributed systems)

===Unlocking===
Releasing a lock.

===Working copy===
The ''working copy'' 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 ''[[Sandbox (software development)|sandbox]]''.