Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

The model

The model is basically the same similar as described in a blog post.

...

  • We'll not use hotfix branches
  • We'll try to go without not use development/integration branch branches (for now
VCS (git
  • -> see table under OpenIssues)

Master

  • Rule: revert immediately as soon as it fails
  • no direct commits except minor enhancement (fixing typos 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 by the Black Knights
  • 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)

Open Issues

how to remove feature branches?
Decision Table
aspectlocal feature branchesremote feature branches
collaborate- more effort - map other users repo+
remove branch+ just delete it locally- all (or at least some) devs need permission
see what's worked on- hidding locally+ easily visible
?  

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: