Branching (version control): Difference between revisions
m References details, removal of redundancy. |
|||
| Line 1: | Line 1: | ||
'''Branching''', in [[revision control]] and [[software configuration management]], is the duplication of an object under revision control (such as a [[source code]] file, or a [[directory tree]]) so that modifications can happen in parallel along both branches. |
'''Branching''', in [[revision control]] and [[software configuration management]], is the duplication of an object under revision control (such as a [[source code]] file, or a [[directory tree]]) so that modifications can happen in parallel along both branches. |
||
Branches are also known as ''trees'', ''streams'' or ''codelines''. The originating branch is sometimes called the ''parent branch'', the ''upstream branch'' (or simply ''upstream'', especially if the branches are maintained by different organizations or individuals), or the ''backing stream''. ''Child branches'' are branches that have a parent; a branch without a parent is referred to as the ''[[Trunk (software)|trunk]]'' or the ''mainline''.<ref> |
Branches are also known as ''trees'', ''streams'' or ''codelines''. The originating branch is sometimes called the ''parent branch'', the ''upstream branch'' (or simply ''upstream'', especially if the branches are maintained by different organizations or individuals), or the ''backing stream''. ''Child branches'' are branches that have a parent; a branch without a parent is referred to as the ''[[Trunk (software)|trunk]]'' or the ''mainline''.<ref>{{cite book |url= http://www.scmpatterns.com/book|title= Software Configuration Management Patterns: Effective Teamwork, Practical Integration |first1 =Steve |last1 =Berczuk | first2 =Brad | last2 = Appleton | ISBN = 0‐20174117‐2|year=2003|publisher=[[Addison-Wesley]]|accessdate= 2007-05-24}}</ref> |
||
{{cite book |
|||
|url=http://www.scmpatterns.com/book|title=Software Configuration Management Patterns: Effective Teamwork, Practical Integration |
|||
|first=Steve |
|||
|last=Berczuk |
|||
|coauthors=Brad Appleton |
|||
|id=ISBN 0201741172|year=2003|publisher=[[Addison-Wesley]]|accessdate=2007-05-24}} |
|||
</ref> |
|||
In some [[Revision control#Distributed version control|distributed revision control systems]], such as [[Darcs]], there is no distinction made between [[Repository (version control)|repositories]] and branches; in these systems, fetching a copy of a repository is equivalent to branching. |
In some [[Revision control#Distributed version control|distributed revision control systems]], such as [[Darcs]], there is no distinction made between [[Repository (version control)|repositories]] and branches; in these systems, fetching a copy of a repository is equivalent to branching. |
||
| Line 15: | Line 8: | ||
== Motivations for branching == |
== Motivations for branching == |
||
Branches allow for parts of software to be developed in parallel.<ref>{{cite web | url=http://www.hillside.net/plop/plop98/final_submissions/P37.pdf | first1 =Brad | last1 = Appleton | first2 = Stephen | last2 = Berczuk | first3 = Ralph | last3 = Cabrera | first4 = Robert | last4 = Orenstein | title=Streamed Lines: Branching Patterns for Parallel Software Development | date=1998-02-08 | publisher= Hillside | format = [[PDF]] | accessdate =2009-08-12}}</ref> Large projects require many roles to be filled, including developers, build managers, and [[Software quality assurance|quality assurance]] personnel. Further, multiple releases on different operating system platforms may have to be maintained. Branches allow contributors to isolate changes without destabilizing the codebase, for example, [[Patch (computing)|fixes]] for bugs, new [[Feature (software design)|features]],<ref>{{cite web | url=http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-part-1-why.aspx | first =Derick | last = Bailey | work =Branch-Per-Feature Source Control | title = Part 1: Why | date=2009-07-15 | publisher= Los techies | accessdate=2009-08-12}}</ref> and [[Software versioning|version]]s [[System integration|integration]]. These changes may be later [[merge (revision control)|merged]] (resynchronized) after testing. |
|||
Branches allow for parts of software to be developed in parallel.<ref>{{cite web |
|||
| url=http://www.hillside.net/plop/plop98/final_submissions/P37.pdf |
|||
| author=Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein |
|||
| title=Streamed Lines: Branching Patterns for Parallel Software Development |
|||
| date=1998-02-08 |
|||
| publisher=hillside.net |
|||
| accessdate=2009-08-12}}</ref> Large projects require many roles to be filled, including developers, build managers, and [[Software quality assurance|quality assurance]] personnel. Further, multiple releases on different operating system platforms may have to be maintained. Branches allow contributors to isolate changes without destabilizing the codebase, for example, [[Patch (computing)|fixes]] for bugs, new [[Feature (software design)|features]],<ref>{{cite web |
|||
| url=http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-part-1-why.aspx |
|||
| author=Derick Bailey |
|||
| title=Branch-Per-Feature Source Control. Part 1: Why |
|||
| date=2009-07-15 |
|||
| publisher=lostechies.com |
|||
| accessdate=2009-08-12}}</ref> and [[Software versioning|version]]s [[System integration|integration]]. These changes may be later [[merge (revision control)|merged]] (resynchronized) after testing. |
|||
== Development branch ==<!-- This section is linked from [[Development]] --> |
== Development branch ==<!-- This section is linked from [[Development]] --> |
||
| ⚫ | A ''development branch'' or ''development tree'' of a piece of software is a version that is under [[software development|development]], and has not yet been officially [[Software release|released]]. In the [[open source]] community, the notion of release is typically metaphorical, since anyone can usually check out any desired version, whether it be in the development branch or not. Often, the version that will eventually become the next ''major'' version is called ''the'' development branch. However, there is often more than one subsequent version of the software under development at a given time. |
||
| ⚫ | A ''development branch'' or ''development tree'' of a piece of software is a version that is under [[software development|development]], and has not yet been officially [[Software release|released]]. In the [[open source]] community, the notion of release is typically metaphorical, since anyone can usually check out any desired version, whether it be in the development branch or not. Often, the version that will eventually become the next ''major'' version is called ''the'' development branch. However, there is often more than one subsequent version of the software under development at a given time. |
||
Some revision control systems have specific jargon for the main development branch; for example, in [[Concurrent Version System|CVS]], it is called the "MAIN". A more generic term is "mainline". |
Some revision control systems have specific jargon for the main development branch; for example, in [[Concurrent Version System|CVS]], it is called the "MAIN". A more generic term is "mainline". |
||
== Shadow or magic branches == |
== Shadow or magic branches == |
||
In [[cvc system|cvc]] and [[CVSNT]], a ''shadow'' or ''magic'' branch "shadows" changes made in the upstream branch, to make it easier to maintain small changes. (cvc is an open-source package building system{{Citation needed|date=November 2010}} incorporating a revision-control system for packages produced by [[rPath]].) |
In [[cvc system|cvc]] and [[CVSNT]], a ''shadow'' or ''magic'' branch "shadows" changes made in the upstream branch, to make it easier to maintain small changes. (cvc is an open-source package building system{{Citation needed|date=November 2010}} incorporating a revision-control system for packages produced by [[rPath]].) |
||
| Line 44: | Line 23: | ||
==References== |
==References== |
||
{{reflist| |
{{reflist |32em}} |
||
==External links== |
|||
*[http://www.hillside.net/plop/plop98/final_submissions/P37.pdf Streamed Lines: Branching Patterns for Parallel Software Development] |
|||
{{Revision control software}} |
{{Revision control software}} |
||
Revision as of 20:04, 13 May 2013
Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches.
Branches are also known as trees, streams or codelines. The originating branch is sometimes called the parent branch, the upstream branch (or simply upstream, especially if the branches are maintained by different organizations or individuals), or the backing stream. Child branches are branches that have a parent; a branch without a parent is referred to as the trunk or the mainline.[1]
In some distributed revision control systems, such as Darcs, there is no distinction made between repositories and branches; in these systems, fetching a copy of a repository is equivalent to branching.
Branching also generally implies the ability to later merge or integrate changes back onto the parent branch. Often the changes are merged back to the trunk, even if this is not the parent branch. A branch not intended to be merged (e.g. because it has been relicensed under an incompatible license by a third party, or it attempts to serve a different purpose) is usually called a fork.
Motivations for branching
Branches allow for parts of software to be developed in parallel.[2] Large projects require many roles to be filled, including developers, build managers, and quality assurance personnel. Further, multiple releases on different operating system platforms may have to be maintained. Branches allow contributors to isolate changes without destabilizing the codebase, for example, fixes for bugs, new features,[3] and versions integration. These changes may be later merged (resynchronized) after testing.
Development branch
A development branch or development tree of a piece of software is a version that is under development, and has not yet been officially released. In the open source community, the notion of release is typically metaphorical, since anyone can usually check out any desired version, whether it be in the development branch or not. Often, the version that will eventually become the next major version is called the development branch. However, there is often more than one subsequent version of the software under development at a given time.
Some revision control systems have specific jargon for the main development branch; for example, in CVS, it is called the "MAIN". A more generic term is "mainline".
Shadow or magic branches
In cvc and CVSNT, a shadow or magic branch "shadows" changes made in the upstream branch, to make it easier to maintain small changes. (cvc is an open-source package building system[citation needed] incorporating a revision-control system for packages produced by rPath.)
See also
References
- ^ Berczuk, Steve; Appleton, Brad (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. ISBN 0‐20174117‐2. Retrieved 2007-05-24.
{{cite book}}: Check|isbn=value: invalid character (help) - ^ Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (1998-02-08). "Streamed Lines: Branching Patterns for Parallel Software Development" (PDF). Hillside. Retrieved 2009-08-12.
- ^ Bailey, Derick (2009-07-15). "Part 1: Why". Branch-Per-Feature Source Control. Los techies. Retrieved 2009-08-12.
Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates. | ||||||
| Local only |
|  | ||||
| Client–server |
| |||||
| Distributed |
| |||||
| Concepts | ||||||
 | This computer-programming-related article is a stub. You can help Wikipedia by expanding it. |