Skip to content

Instantly share code, notes, and snippets.

@jaddison

jaddison/branching-strategy.md

Last active January 20, 2020 17:29
Show Gist options
  • Save jaddison/c809e0b0d84774fea7b1cffe8d56c9f0 to your computer and use it in GitHub Desktop.
Save jaddison/c809e0b0d84774fea7b1cffe8d56c9f0 to your computer and use it in GitHub Desktop.
Download ZIP
Defining a git branching strategy that works well with CI/CD
Raw
branching-strategy.md

Current State

We have something like this set up at the moment; 2 repos (aws and github):

  • master (aws)
  • next (aws)
  • integation (aws)
  • master (gh)
  • next (gh)
  • integration (gh)

Proposed Changes

(for simplicity, loosely based upon https://nvie.com/posts/a-successful-git-branching-model/)

Remove the AWS repo, use Github repo as it provides a good developer experience for collaboration, without the need for developers to have AWS accounts.

  • master (gh)
  • next (gh)
  • develop (gh)

Make the pipeline react to Github pushes/pull request merges instead.

  • production site tracks master
  • beta site tracks next

Goals

  • define rigid structure and processes around how devs interact with core branches (develop, next, master)
  • any code submitted via pull request is considered accepted and deployable (it's been code reviewed, after all)
  • beta site allows us to find edge cases, bugs with the code that we can address within next, leaving develop free for next work by other devs
  • make branch management & code reviews easier, reduce merge conflicts - overall, improve developer efficiency
  • less hands on manual merging between branches (and remotes!)

Branch Overview

develop:

  • it is a 'collection point' of code-reviewed, dev-tested 'working' changes that are suitable for promoting to the beta server (via the next branch)
  • receives commits from next via merge (in the case of downstream fixes on either master or next)
  • 99% of dev branches are created from this as a base branch
  • it will be necessary for devs to regularly rebase outstanding fix/feature branches to ensure they are locally testing all other develop changes
  • those same 99% of created branches are merged into this branch via Github pull requests
  • merging a pull request means:
    • that the dev tested affected parts of the site
    • the changes have been code reviewed

next:

    • merges/commits trigger beta site update
  • receives commits from master via merge (in the case of a hotfix applied to master)
  • receives merges from develop (based on completed trello card bug fixes/features, etc) - this can be once daily, or as needed/on-demand
  • create & merge fix branches to address issues found in beta site testing

master:

    • merges/commits trigger production site update
  • receives merges from next
  • create & merge hotfix branches (urgent, emergency fixes)

Most developers focus on changes that merge into the develop branch. Occasionally, beta feedback will require devs to work on changes targeting next, which will need to be merged back into develop. Very rarely, a senior dev may need to hotfix directly against master, which will need to be merged back into both next and develop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment