A possible branching approach

William Boles -

For some time now I have been thinking about how best to use branching on my projects to ease my overhead and allow for all the possible states that an iOS app can be in during development. I've been using the following branching model for just over a year now and I'm finding it works very well for myself and my team.

  • master
    • Current version of the app with Apple.
    • You should NEVER develop on this branch.
    • After each merge master branch should be tagged with version name (e.g. v1.2.4).
  • gm
    • Golden master
    • Contains a version of the app which has been through the rc branch
    • This version should with Apple awaiting approval
    • Bugs reported on this version should be fixed on this branch and merged into the dev branch
    • You should NEVER develop on this branch.
    • ONLY b/[bug-fix-name] can be branched out.
  • rc
    • Release candidate
    • Contains a version of the app which has been through the tc branch
    • Bugs reported on this version should be fixed on this branch and merged into the dev branch
    • No new features should be developed/introduced on this branch
    • You should NEVER develop on this branch.
    • ONLY b/[bug-fix-name] can be branched out.
  • tc
    • Test candidate
    • Contains a version of the app which has not been through or is currently going through test
    • Non-critical bugs reported should be fixed on the dev branch
      • Critical should be retested on the RC branch (if available)
        • If reproducible on rc fixed on rc and merged to dev
        • If not reproducible on rc, it should be fixed on dev
    • You should NEVER develop on this branch.
  • dev
    • Development
    • Should be the common branch of the project that is currently under development
    • You should NEVER develop on this branch.
    • ONLY f/[feature-name] and b/[bug-fix-name] can be branched out.

As well as permanent branches we also have temporary branches:

  • f/[feature-name]
    • Feature branch.
    • You should develop on this branch.
    • f/[feature-name-smaller-task] (when you need to split into smaller tasks) and b/[bug-fix-name] (before each release) can be branched out.
    • f/[feature-name-smaller-task] and b/[bug-fix-name] can be merged into f/[feature-name].
    • Pull Request from this branch will be reviewed and merged by someone else.
    • After Pull Request from this branch is merged, it will be deleted.
  • b/[bug-fix-name]
    • Bug fix branch.
    • You should fix bugs on this branch.
    • Pull Request from this branch will be reviewed and merged by someone else.
    • After Pull Request from this branch is merged, it will be deleted.

This model is very similar to this: http://nvie.com/posts/a-successful-git-branching-model/