Versions Compared

Old Version 6

changes.mady.by.user Daniel Lipp

Saved on

compared with

New Version Current

changes.mady.by.user Daniel Lipp

Saved on

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 use the term develop branch (not integration branch)

Continuous integration (Hudson)

The following branches will have a continuous integration job running

  • master
  • release branches
  • develop

Build (maven)

  • same snapshot version (develop and master)?
    • see open Issues

Maintenance

  • no changes
  • no hot fix branches (for the moment)
  • 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
Feature branches
  • remove them after the final merge
  • list of feature branches branches 
    • --> things we are actively working on or are waiting
  • how to remove the branches?

Rules

  • central repo
    • no feature branches
    • 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

    merging at the end of the sprint (develop

    -> master)

    • scrum masters
  • on develop branch
    • revert immediately as soon it fails

    • Open Issues

    Sharing feature branches [Daniel]

    • how to share them without having them on the central repo
      • ppl could define remote repos on others computers
        • spider net! - over time every dev will work with every other...
        • no out-of-the-box backup
        • hard to track what's being worked on
      • According to Greg nothing speaks against having them in central repo!

    Version conflicts for snapshots [Daniel/Gregory]

    • do we need a special version?
    • other repository?
    • dev classifier?
    • something has to guarantee that not the wrong versions are used on the master!

    Continuous integration

    • Need frequent (daily) merge back to development branch
    • conflicts will otherwise be hit too late

    Branching effort

    Creating branches and merging is cheap in git - but if you have to touch lot's of modules it might no longer be the case

    • 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)

    As we almost have a one git-repo per module setup feature branching might involve quite an effort in maintaining branchese.g. for metadata-as-mixin we have to create (later merge then delete) branches for magnolia_main, magnolia_ui, ce-bundle, stk?, etk?, demo-project?,...

    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: