Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Branching (version control)

From Wikipedia, the free encyclopedia
Duplication of an object under version control

Branching, inversion control andsoftware configuration management, is the duplication of an object under version control (such as asource code file or adirectory tree). Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are calledbranches. The users of the version control system can branch any branch.

Branches are also known astrees,streams orcodelines. The originating branch is sometimes called theparent branch, theupstream branch (or simplyupstream, especially if the branches are maintained by different organizations or individuals), or thebacking stream.

Trunk

[edit]

Child branches are branches that have a parent; a branch without a parent is referred to as thetrunk or themainline.[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 calledtrunk-based development), it always contains the latestcutting-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 andcommit policy the trunk may contain the most stable or the least stable or something-in-between version. Other terms for trunk includebaseline,mainline, andmaster, though in some cases these are used with similar but distinct senses – seeversion 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]
Main article:Merge (revision control)

Branching generally implies the ability to latermerge orintegrate 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 beenrelicensed under an incompatible license by a third party, or it attempts to serve a different purpose) is usually called afork.

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, andquality 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, newfeatures,[3] andversionsintegration. These changes may be latermerged (resynchronized) after testing.

Branches can also be used to implementvendor branching, a strategy to use, track and optionally modify source code that is published by external "upstream" parties ("vendors"). With this approach, fairly common since theCVS times, a separate branch is created to keep the vendor-provided code. This branch is updated with new upstream releases and merged into the main codebase when necessary.[4]

Development branch

[edit]

Adevelopment branch ordevelopment tree of a piece of software is a version that is underdevelopment, and has not yet been officiallyreleased. In theopen 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 nextmajor version is calledthe 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 thetrunk. Some revision control systems have specific jargon for the main development branch. For example, inCVS, it is called the "MAIN" branch.Git uses "master" by default, althoughGitHub[5][6] andGitLab switched to "main"after the murder of George Floyd.

Shadow or magic branches

[edit]

InCVSNT, ashadow ormagic 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 byrPath.)

Distributed revision control

[edit]

Repository clones

[edit]

Indistributed revision control, the entire repository, with branches, may be copied and worked on further.Monotone (mtn),Mercurial (hg) andgit call it "clone";Bazaar calls it "branch".[citation needed]

In somedistributed revision control systems, such asDarcs, there is no distinction made betweenrepositories and branches; in these systems, fetching a copy of a repository is equivalent to branching.

See also

[edit]

References

[edit]
  1. ^Berczuk, Steve; Appleton, Brad (2003).Software Configuration Management Patterns: Effective Teamwork, Practical Integration.Addison-Wesley.ISBN 0-20174117-2. Retrieved2007-05-24.
  2. ^Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (1998-02-08)."Streamed Lines: Branching Patterns for Parallel Software Development"(PDF). Hillside. Retrieved2009-08-12.
  3. ^Bailey, Derick (2009-07-15)."Part 1: Why".Branch-Per-Feature Source Control. Los techies. Retrieved2009-08-12.
  4. ^Nelson-Smith, Stephen (2013-10-11).Test-Driven Infrastructure with Chef: Bring Behavior-Driven Development to Infrastructure as Code. "O'Reilly Media, Inc.".ISBN 978-1-4493-7260-6. Retrieved2025-05-26.
  5. ^Wallen, Jack (2020-09-22)."GitHub to replace master with main starting in October: What developers need to do now".TechRepublic. Retrieved2022-04-24.
  6. ^Heinze, Carolyn (2020-11-24)."Why GitHub renamed its master branch to main".TheServerSide. Retrieved2022-04-24.
Years, where available, indicate the date of first stable release. Systems with namesin italics are no longer maintained or have planned end-of-life dates.
Local only
Free/open-source
Proprietary
Client–server
Free/open-source
Proprietary
Distributed
Free/open-source
Proprietary
Concepts
Retrieved from "https://en.wikipedia.org/w/index.php?title=Branching_(version_control)&oldid=1304384667"
Category:
Hidden categories:

[8]ページ先頭

©2009-2025 Movatter.jp