Branching (version control)

Last updated

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.

Contents

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. [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, 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

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

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.

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

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

Repository clones

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

Related Research Articles

Concurrent Versions System is a version control system originally developed by Dick Grune in July 1986.

In software engineering, version control is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information. Version control is a component of software configuration management.

<span class="mw-page-title-main">Apache Subversion</span> Free and open-source software versioning and revision control system

Apache Subversion is a software versioning and revision control system distributed as open source under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS).

In software engineering, software configuration management is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine the "what, when, why and who" of the change. If a configuration is working well, SCM can determine how to replicate it across many hosts.

<span class="mw-page-title-main">Code Co-op</span> Peer-to-peer revision control system

Code Co-op is the peer-to-peer revision control system made by Reliable Software.

In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software. The term often implies not merely a development branch, but also a split in the developer community; as such, it is a form of schism. Grounds for forking are varying user preferences and stagnated or discontinued development of the original software.

IBM DevOps Code ClearCase (also known as IBM Rational ClearCase) is a family of computer software tools that supports software configuration management (SCM) of source code and other software development assets. It also supports design-data management of electronic design artifacts, thus enabling hardware and software co-development. ClearCase includes revision control and forms the basis for configuration management at large and medium-sized businesses, accommodating projects with hundreds or thousands of developers. It is developed by IBM.

<span class="mw-page-title-main">Monotone (software)</span> Revision control software

Monotone is an open source software tool for distributed revision control.

<span class="mw-page-title-main">Git</span> Software for version control of files

Git is a distributed version control system that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development.

<span class="mw-page-title-main">Continuous integration</span> Software development practice based on frequent submission of granular changes

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Nowadays it is typically implemented in such a way that it triggers an automated build with testing. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

In software development, distributed version control is a form of version control in which the complete codebase, including its full history, is mirrored on every developer's computer. Compared to centralized version control, this enables automatic management branching and merging, speeds up most operations, improves the ability to work offline, and does not rely on a single location for backups. Git, the world's most popular version control system, is a distributed version control system.

<span class="mw-page-title-main">Mantis Bug Tracker</span> Bug tracking system

Mantis Bug Tracker is a free and open source, web-based bug tracking system. The most common use of MantisBT is to track software defects. However, MantisBT is often configured by users to serve as a more generic issue tracking system and project management tool.

In software development, a codebase is a collection of source code used to build a particular software system, application, or software component. Typically, a codebase includes only human-written source code system files; thus, a codebase usually does not include source code files generated by tools or binary library files, as they can be built from the human-written source code. However, it generally does include configuration and property files, as they are the data necessary for the build.

<span class="mw-page-title-main">Mercurial</span> Distributed revision-control tool for software developers

Mercurial is a distributed revision control tool for software developers. It is supported on Microsoft Windows, Linux, and other Unix-like systems, such as FreeBSD and macOS.

In software development, version control is a class of systems responsible for managing changes to computer programs or other collections of information such that revisions have a logical and consistent organization. The following tables include general and technical information on notable version control and software configuration management (SCM) software. For SCM software not suitable for source code, see Comparison of open-source configuration management software.

In FOSS development communities, a forge is a web-based collaborative software platform for both developing and sharing computer applications.

Plastic SCM is a cross-platform commercial distributed version control tool developed by Códice Software for Microsoft Windows, Mac OS X, Linux, and other operating systems. It includes a command-line tool, native GUIs, diff and merge tool and integration with a number of IDEs. It is a full version control stack not based on Git.

In version control systems, a repository is a data structure that stores metadata for a set of files or directory structure. Depending on whether the version control system in use is distributed, like Git or Mercurial, or centralized, like Subversion, CVS, or Perforce, the whole set of information in the repository may be duplicated on every user's system or may be maintained on a single server. 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 heads.

In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment and production environment are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.

References

  1. Berczuk, Steve; Appleton, Brad (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. ISBN   0-20174117-2 . Retrieved 2007-05-24.
  2. 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.
  3. Bailey, Derick (2009-07-15). "Part 1: Why". Branch-Per-Feature Source Control. Los techies. Retrieved 2009-08-12.
  4. 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.
  5. Heinze, Carolyn (2020-11-24). "Why GitHub renamed its master branch to main". TheServerSide. Retrieved 2022-04-24.