Re-evaluation of branching strategy

Background

Many of our repositories have merge commits in master that are not in develop, or vice-versa, the result of following the GitFlow branching scheme and the advice that's in the old DPLA Run Book. It produces distracting noise in GitHub and elsewhere. GitHub is saying, for example, that the master branch of ingestion is 21 commits ahead of develop, which can cause some alarm until you realize it's just talking about merge commits. (What if you had some real change commits that weren't on develop? This message would not flag them!)

See https://stackoverflow.com/questions/37684878/after-merge-of-release-branch-why-is-master-1-commit-ahead-of-develop, in which one respondent answers:

This is not something that you need to worry about. Normally, that commit will automatically end up in develop next time you finish a hotfix branch

The author appears to accept the fact that there's merge-commit clutter in the master branch.

We're discussing this in the Tech Team meeting of May 23rd, 2017.

Tests and verification of merge commit clutter

An abridged and commented shell session, verifying how merge commits are created:

# Preliminaries ...

$ mkdir repo-with-ff   # For testing "git merge --no-ff"
$ mkdir repo-no-ff     # For testing "git merge"

# Test 1.

# The repository has a `develop' branch that was branched off of `master'.
# `--no-ff' merges are used for release branches, into both the `master' and
# `develop' branch.

$ cd repo-with-ff/
$ echo 'test' > testfile
$ git init .
$ git add testfile 
$ git commit -m 'Initial commit'
$ git checkout -b develop master
$ vi testfile 
$ git commit -a -m 'Add a line'
$ git checkout -b release-1 develop
$ vi testfile 
$ git commit -a -m 'Prepare Release 1'
$ git checkout master
$ git merge --no-ff release-1
$ git checkout develop
$ git merge --no-ff release-1

$ git log master --not develop
commit 4d52a2b5c6f7f7c203ce279afad8617136ff45e7
Merge: 8594ac3 c65899a
Author: Mark Breedlove <mb@dp.la>
Date:   Tue May 23 11:14:06 2017 -0400

    Merge branch 'release-1'

$ git log develop --not master
commit 33e5e3b72e09f215e71c4cc3d31c5707ece96249
Merge: 8bc5a9b c65899a
Author: Mark Breedlove <mb@dp.la>
Date:   Tue May 23 11:18:34 2017 -0400

    Merge branch 'release-1' into develop

# ... Each branch has a merge commit that the other one doesn't.

$ git cherry -v develop master
$ git cherry -v master develop
# ... But neither branch has _changes_ that the other one doesn't.


# Test 2.

# The repository has a `develop' branch that was branched off of `master'.
# Merges for release branches are done without any switches, into either
# `develop' or `master'.

$ cd repo-with-ff/
$ echo 'test' > testfile
$ git init .
$ git add testfile 
$ git commit -m 'Initial commit'
$ git checkout -b develop master
$ vi testfile 
$ git commit -a -m 'Add a line'
$ git checkout -b release-1 develop
$ vi testfile 
$ git commit -a -m 'Prepare Release 1'
$ git checkout master

$ git merge release-1
Updating e42ef78..53dcd6e
Fast-forward
 testfile | 2 ++
 1 file changed, 2 insertions(+)

$ git checkout develop

$ git merge release-1
Updating 1a5a68b..53dcd6e
Fast-forward
 testfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git log master --not develop
$ git log develop --not master
# ... Neither branch is ahead of the other. Neither has commits that the other
#     one doesn't.
$ git cherry -v master develop
$ git cherry -v develop master
# ... Nothing returned from any of those commands.


# Test 3.
# Same as Test 2, but using a feature branch off of `develop' for a change,
# and merging that feature branch into `develop' with a merge commit to
# simulate GitHub merging a PR.

# ... Same result as Test 2. At least with a simple repository such as this,
# you still have fast-forwards when you merge the release branch into master
# or develop.

There's an open question regarding the tests above as to how we end up with merge commits in our repositories when we merge from the release branch in to master, if the test above lets you get away with a fast-forward for that. I don't know yet, but we know that we are guaranteed to get undesirable merge commits if we do --no-ff. When I read the resources in the section below, I find myself questioning why we have a develop and master branch. --MB

GitHub adds merge commits when pull requests are merged, as a feature. The commit contains the pull request number that generated it, which is nice because it references the code review discussion in the pull request. These merge commits are fine, but we want to stop committing the unnecessary ones that have been generated by our old --no-ff release branch merges.

An alternative to GitFlow

"Gitflow Considered Harmful" addresses the problem that we're seeing with merge commits, and which some practitioners of GitFlow probably just accept.

The author has followed up with "OneFlow," which he bills as a drop-in replacement for GitFlow.