... | ... | @@ -21,39 +21,24 @@ Many projects use only a single master code line and don't maintain release bran |
|
|
The following is quoted from http://nvie.com/posts/a-successful-git-branching-model/, Published: January 05, 2010
|
|
|
|
|
|
#### At a glance
|
|
|
From http://nvie.com/
|
|
|
|
|
|
![](http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png)
|
|
|
http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png
|
|
|
|
|
|
|
|
|
#### Decentralized but centralized
|
|
|
|
|
|
The repository setup that we use and that works well with this branching
|
|
|
model, is that with a central “truth” repo, https://github.com/mathjax/MathJax/. Note that this repo is only
|
|
|
*considered* to be the central one (since Git is a DVCS, there is no
|
|
|
such thing as a central repo at a technical level). We will refer to
|
|
|
this repo as `origin`, since this name is familiar to all Git users.
|
|
|
|
|
|
![](http://nvie.com/img/2010/01/centr-decentr.png)
|
|
|
model, is that with a central “truth” repo, https://github.com/mathjax/MathJax/.
|
|
|
|
|
|
Each developer pulls and pushes to origin. But besides the centralized
|
|
|
push-pull relationships, each developer may also pull changes from other
|
|
|
peers to form sub teams. For example, this might be useful to work
|
|
|
together with two or more developers on a big new feature, before
|
|
|
pushing the work in progress to `origin` prematurely. In the figure
|
|
|
above, there are subteams of Alice and Bob, Alice and David, and Clair
|
|
|
and David.
|
|
|
|
|
|
Technically, this means nothing more than that Alice has defined a Git
|
|
|
remote, named `bob`, pointing to Bob’s repository, and vice versa.
|
|
|
pushing the work in progress to `origin` prematurely. .
|
|
|
|
|
|
#### The main branches
|
|
|
|
|
|
|
|
|
![](http://nvie.com/img/2009/12/bm002.png)
|
|
|
|
|
|
At the core, the development model is greatly inspired by existing
|
|
|
models out there. The central repo holds two main branches with an
|
|
|
The central repo holds two main branches with an
|
|
|
infinite lifetime:
|
|
|
|
|
|
- `master`
|
... | ... | @@ -78,8 +63,8 @@ in detail will be discussed further on. |
|
|
Therefore, each time when changes are merged back into `master`, this is
|
|
|
a new production release *by definition*. We tend to be very strict at
|
|
|
this, so that theoretically, we could use a Git hook script to
|
|
|
automatically build and roll-out our software to our production servers
|
|
|
everytime there was a commit on `master`.
|
|
|
automatically build and roll-out our software to production servers
|
|
|
every time there was a commit on `master`.
|
|
|
|
|
|
####### Supporting branches
|
|
|
|
... | ... | @@ -108,8 +93,6 @@ course plain old Git branches. |
|
|
|
|
|
####### Feature branches
|
|
|
|
|
|
![](http://nvie.com/img/2009/12/fb.png)
|
|
|
|
|
|
May branch off from: `develop`\
|
|
|
Must merge back into: `develop`\
|
|
|
Branch naming convention: anything except `master`, `develop`,
|
... | ... | @@ -153,15 +136,7 @@ The `--no-ff` flag causes the merge to always create a new commit |
|
|
object, even if the merge could be performed with a fast-forward. This
|
|
|
avoids losing information about the historical existence of a feature
|
|
|
branch and groups together all commits that together added the feature.
|
|
|
Compare:
|
|
|
|
|
|
![](http://nvie.com//img/2010/01/merge-without-ff.png)
|
|
|
|
|
|
In the latter case, it is impossible to see from the Git history which
|
|
|
of the commit objects together have implemented a feature—you would have
|
|
|
to manually read all the log messages. Reverting a whole feature (i.e. a
|
|
|
group of commits), is a true headache in the latter situation, whereas
|
|
|
it is easily done if the `--no-ff` flag was used.
|
|
|
|
|
|
####### Release branches
|
|
|
|
... | ... | @@ -180,16 +155,9 @@ The key moment to branch off a new release branch from `develop` is when |
|
|
develop (almost) reflects the desired state of the new release. At least
|
|
|
all features that are targeted for the release-to-be-built must be
|
|
|
merged in to `develop` at this point in time. All features targeted at
|
|
|
future releases may not—they must wait until after the release branch is
|
|
|
future releases may not — they must wait until after the release branch is
|
|
|
branched off.
|
|
|
|
|
|
It is exactly at the start of a release branch that the upcoming release
|
|
|
gets assigned a version number—not any earlier. Up until that moment,
|
|
|
the `develop` branch reflected changes for the “next release”, but it is
|
|
|
unclear whether that “next release” will eventually become 0.3 or 1.0,
|
|
|
until the release branch is started. That decision is made on the start
|
|
|
of the release branch and is carried out by the project’s rules on
|
|
|
version number bumping.
|
|
|
|
|
|
######## Creating a release branch
|
|
|
|
... | ... | @@ -211,7 +179,7 @@ reflecting the new version number: |
|
|
After creating a new branch and switching to it, we bump the version
|
|
|
number. Here, `bump-version.sh` is a fictional shell script that changes
|
|
|
some files in the working copy to reflect the new version. (This can of
|
|
|
course be a manual change—the point being that *some* files change.)
|
|
|
course be a manual change — the point being that *some* files change.)
|
|
|
Then, the bumped version number is committed.
|
|
|
|
|
|
This new branch may exist there for a while, until the release may be
|
... | ... | |