Source-control-policies.md

@@ -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