Branching (version control): Difference between revisions
m →References: More narrow columns |
→Trunk: Expanding article |
||
| (44 intermediate revisions by 36 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Duplication of an object under version control}} |
|||
'''Branching''', in [[ |
'''Branching''', in [[version control]] and [[software configuration management]], is the duplication of an object under version control (such as a [[source code]] file or a [[directory tree]]). Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are called '''branches'''. The users of the version control system can branch any branch. |
||
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''. |
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''. |
||
==Trunk== |
|||
| ⚫ | |||
''Child branches'' are branches that have a parent; a branch without a parent is referred to as the '''''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]]|access-date= 2007-05-24}}</ref> The trunk is also sometimes loosely referred to as HEAD, but properly head refers not to a branch, but to the most recent commit on a given branch, and both the trunk and each named branch has its own head. The trunk is usually meant to be the base of a project on which development progresses. If developers are working exclusively on the trunk (so called '''trunk-based development'''), it always contains the latest [[State of_the_art|cutting-edge]] version of the project, but therefore may also be the most unstable version. Another approach is to split a branch off the trunk, implement changes in that branch and merge the changes back into the trunk when the branch has proven to be stable and working. Depending on development mode and [[Commit (data management)|commit]] policy the trunk may contain the most stable or the least stable or something-in-between version. Other terms for trunk include ''baseline,'' ''mainline,'' and ''master,'' though in some cases these are used with similar but distinct senses – see {{section link|version control|Common terminology}}. Often main developer work takes place in the trunk and stable versions are branched, and occasional bug-fixes are merged from branches to the trunk. When development of future versions is done in non-trunk branches, it is usually done for projects that do not change often, or where a change is expected to take a long time to develop until it will be ready for incorporating in the trunk. |
|||
==Merging== |
|||
| ⚫ | Branching |
||
{{Main|Merge (revision control)}} |
|||
| ⚫ | Branching generally implies the ability to later [[merge (revision control)|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 [[relicensing|relicensed]] under an incompatible license by a third party, or it attempts to serve a different purpose) is usually called a ''[[Fork (software development)|fork]]''. |
||
== 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]] | |
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]] | access-date =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 | access-date=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 model|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. |
||
Often, the development branch is the [[#Trunk|trunk]]. Some revision control systems have specific jargon for the main development branch. For example, in [[Concurrent Version System|CVS]], it is called the "MAIN" branch. [[Git]] uses "master" by default, although [[GitHub]]<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}}</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}}</ref> and [[GitLab]] switched to "main" [[Reactions to the murder of George Floyd|after the murder of George Floyd]]. |
|||
Some revision control systems have specific jargon for the main development branch; for example, in [[Concurrent Version System|CVS]], it is called the "MAIN"; in [[Git (software)|Git]] it is called the "master". A more generic term is "mainline". |
|||
== Shadow or magic branches == |
== Shadow or magic branches == |
||
In |
In [[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]].) |
||
==Distributed revision control== |
|||
===Repository clones === |
|||
In [[distributed revision control]], the entire repository, with branches, may be copied and worked on further. [[monotone (software)|Monotone]] (mtn), [[Mercurial]] (hg) and [[git]] call it "clone"; [[GNU Bazaar|Bazaar]] calls it "branch".{{citation needed|date=October 2019}} |
|||
| ⚫ | |||
== See also == |
== See also == |
||
* [[Trunk (software)]] |
|||
* [[Revision tag]] |
* [[Revision tag]] |
||
| Line 25: | Line 36: | ||
{{Reflist|30em}} |
{{Reflist|30em}} |
||
{{ |
{{Version control software}} |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
{{Compu-prog-stub}} |
|||
| ⚫ | |||
Latest revision as of 07:27, 4 November 2024
Branching, in version control and software configuration management, is the duplication of an object under version control (such as a source code file or a directory tree). Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are called branches. The users of the version control system can branch any branch.
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.
Trunk
[edit]Child branches are branches that have a parent; a branch without a parent is referred to as the trunk or the mainline.[1] The trunk is also sometimes loosely referred to as HEAD, but properly head refers not to a branch, but to the most recent commit on a given branch, and both the trunk and each named branch has its own head. The trunk is usually meant to be the base of a project on which development progresses. If developers are working exclusively on the trunk (so called trunk-based development), it always contains the latest cutting-edge version of the project, but therefore may also be the most unstable version. Another approach is to split a branch off the trunk, implement changes in that branch and merge the changes back into the trunk when the branch has proven to be stable and working. Depending on development mode and commit policy the trunk may contain the most stable or the least stable or something-in-between version. Other terms for trunk include baseline, mainline, and master, though in some cases these are used with similar but distinct senses – see version control § Common terminology. Often main developer work takes place in the trunk and stable versions are branched, and occasional bug-fixes are merged from branches to the trunk. When development of future versions is done in non-trunk branches, it is usually done for projects that do not change often, or where a change is expected to take a long time to develop until it will be ready for incorporating in the trunk.
Merging
[edit]Branching 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
[edit]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
[edit]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.
Often, the development branch is the trunk. Some revision control systems have specific jargon for the main development branch. For example, in CVS, it is called the "MAIN" branch. Git uses "master" by default, although GitHub[4][5] and GitLab switched to "main" after the murder of George Floyd.
Shadow or magic branches
[edit]In 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.)
Distributed revision control
[edit]Repository clones
[edit]In distributed revision control, the entire repository, with branches, may be copied and worked on further. Monotone (mtn), Mercurial (hg) and git call it "clone"; Bazaar calls it "branch".[citation needed]
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.
See also
[edit]References
[edit]- ^ Berczuk, Steve; Appleton, Brad (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. ISBN 0-20174117-2. Retrieved 2007-05-24.
- ^ 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.
- ^ Wallen, Jack (2020-09-22). "GitHub to replace master with main starting in October: What developers need to do now". TechRepublic. Retrieved 2022-04-24.
- ^ Heinze, Carolyn (2020-11-24). "Why GitHub renamed its master branch to main". TheServerSide. Retrieved 2022-04-24.
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 | ||||||
