Page tree
Skip to end of metadata
Go to start of metadata

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

The model

The model is similar as described in a blog post.

Differences

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

Master

  • 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

Maintenance

  • 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

    Benefits:

    • 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