Skip to content

Merge strategy

Janek Bevendorff edited this page Jan 28, 2017 · 14 revisions

Our general Git worflow is inspired by Git flow.

We have two historical (long-lived) branches master and develop. The top revision of the master branch always represents the latest released version whereas develop points to the latest development version. Both branches must always be in a compilable and in a usable state and all tests must pass.

Additionally to these two branches, there are several short-lived branches with different prefixes:

  • feature/<issue#-description>: new features or non-critical fixes
    Branch from: develop
    Merge back into: develop
  • release/<x.y.z>: release preparation branch for version <x.y.z>, marks beginning of feature freeze
    Branch from: develop
    Merge back into: develop, master
  • hotfix/<issue#-description>: maintenance branch for bugfixes in released versions
    Branch from: release/<x.y.z>
    Merge back into: release/<x.y.z>, develop
  • meta/<description>: patches that don't directly affect the application (documentation, build organization etc.)
    Branch from: develop
    Merge back into: develop

Merging from a short-lived branch into a historical should be done using git merge --no-ff to preserve the origin of those commits. For instance, if a feature/* branch is merged into develop it should be done with a merge commit.

Merging from historical branches into short-lived branches cannot be done without a merge commit, so it is preferred to keep to short-lived branch rebased on top of the long-lived branch (i.e., rebase your feature onto the develop branch). If that is not possible because the branch is used by multiple contributors, a normal merge commit is acceptable.

Merging a hotfix into the release branch should be done using git merge --ff-only or git rebase (--onto) and then git merge --ff-only to avoid creating a merge commit. The same applies when merging between other short-lived branches. Avoid merge commits where possible. The exception is when the merged branch contains a significant number of commits and preserving the two branches in the history makes sense (significant is subjective).

Merging a release branch into master and develop should be done using git merge --no-ff.