This page describes the branching model we apply for development at Magnolia.

The model

The model is similar as described in a blog post.


  • We'll not use hotfix branches
  • We'll not use development/integration branches (for now -> see table under OpenIssues)


  • Rule: revert immediately as soon as it fails
  • no direct commits except minor enhancement (fixing typos & formatting etc.) 
    • make sure to inform in M5 Review chat

Feature branches

  • on central repo
  • remove them after the final merge
  • list of feature branches 
    • --> things we are actively working on or are waiting
  • frequently merge from master to feature branches to reduce last-minute conflicts


  • no changes
  • no hot fix branches (for the moment)

Merging (feature-branch -> master)

  • only after review 
  • we use  git merge --no-ff instead
    • no fastforward - avoids losing information about the historical existence of a feature branch + groups together all commits of a feature

(other option would be git merge --squash when merging from feature branch to master -> one consolidated commit with meaningful message for a feature)

Not using one of the above will result in situations where it might be very hard to figure out what commit's belong together (e.g. really bad if u have to revert a feature)

By the way: feature branching vs. continuous integration has heavily been debated - mainly because of Martin Fowler's vote to not go for feature branches. Here's a bunch of links around it:


  • No labels

1 Comment

  1. alternative to the above (considering experience from first round of QA/BK guarded sprint):

    • create QA/Review branch 
      • it's a copy of the master
      • w/o hudson build

    To do the review:

    • reviewer merges all from master into this branch
    • reviewee merge+squash his branch into QA branch
      reviewer does the review
    • if all is ok, reviewer merges this single commit from QA to master
    • if not reviewer rollback such commit from QA branch w/ comments what to improve to reviewee


    • for review you see only one single accumulated change (or couple of them if multiple repos are involved)
    • all ad-interim commits made by dev are hidden

    To consider:

    • doesn't remove responsibility from dev to merge master to their branch before requesting review
    • doesn't remove responsibility from dev to build all and make sure it works before review
    • code beautifications (formatting, etc) need to be reviewed/pushed separately and must not be done in middle of the development on branch