Skip to content

Instantly share code, notes, and snippets.

@twoism-dev
Last active March 13, 2019 18:57
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save twoism-dev/9929426 to your computer and use it in GitHub Desktop.
Save twoism-dev/9929426 to your computer and use it in GitHub Desktop.
Hybrid Git Flow

Our Git Flow

We are using a simple git flow based on git flow and github flow. We have two branches develop and master.

develop is a representation of staging

master is a representation of production

The Rules

  • Master is always deployable.
  • All tests must pass on Master at all times.
  • Do not commit directly to develop or master, only merge in feature/fix branches.
  • As soon as a feature/fix is merged into develop it should be deployed to staging.
  • As soon as a feature/fix is merged into master it should be deployed to production.
  • Feature branches should be pushed to origin, for code review and so others can see what is being worked on.
  • Use --no-ff when merging your feature branch into develop or master, this forces creation of a merge commit, making it easier to see what was merged and when.

Working on a new feature

  • Create a new branch from master called 'feature/[trello-card-id]'
$ git checkout -b feature/160-add-picture-of-cat master
  • Work on feature
  • Push feature to origin regularly
$ git push -u origin feature/160-add-picture-of-cat
  • Submit for code review (if required) (e.g. move trello card to code review)
  • Merge feature into develop
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature/160-add-picture-of-cat
$ git push origin
  • Deploy to staging
$ git push staging develop:master
  • Submit for QA (e.g. move trello card to QA)
  • Merge feature into master
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature/160-add-picture-of-cat
$ git push origin
  • Deploy master to production
$ git push production master
  • Delete feature branch
Copy link

ghost commented Dec 11, 2017

We are about to use this exactly, with one minor variation. We will be deleting the develop branch each night, then recreating it from master, as an extra safeguard that develop doesn't get out of sync with master.

@tayeke
Copy link

tayeke commented Mar 13, 2019

I'm trying to do something similar, but we have an issue with long open branches of code like refactors. So we have to use PR comments and JIRA to be clear about blockers and requirements.

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