Skip to content

Instantly share code, notes, and snippets.

@kilgarenone
Last active May 5, 2018 05:23
Show Gist options
  • Save kilgarenone/10546aa4dce567393675bdcd80ec9e0a to your computer and use it in GitHub Desktop.
Save kilgarenone/10546aa4dce567393675bdcd80ec9e0a to your computer and use it in GitHub Desktop.
Proposal: Git Workflow

Git Workflow

Git workflow diagram

This doc covers the workflow among the developers with respect to development, product release, and hotfixes.

So, we have a repo which has two major branches:

  • master
  • develop

, as well as the following supporting branches:

  • Feature Branch
  • Release Branch
  • Hotfix Branch

Let's discuss every one of them and their purposes:

Master

  • Our production branch.

Develop

Reflects a state with the latest delivered development changes for the next release.

Feature Branch

  • May branch off from:     develop
  • Must merge back into:     develop
  • Branch naming convention:     anything except master, develop, release-*, or hotfix-*
  • Every major new feature for the upcoming or a distant future release — for example, the QR codes management dashboard in primebiz — will reside in its own branch (e.g. feature-primebiz-qrcode).
  • Once a feature is finished, it will be merged into the develop branch.

Release Branch

  • May branch off from:     develop
  • Must merge back into:      develop and master
  • Branch naming convention:      release-X.X      e.g. release.1.2
  • Release branch is created when the develop branch (almost) reflects the desired state of the new release.

At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time.' All features targeted at future releases may not — they must wait until after (their) release branch is branched off.

  • This branch allows for minor bug fixes.
  • Upon the creation of this branch, meta-data such as the version number or build dates are determined.

By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

  • This branch will be merged to the master for an upcoming production release.
  • To keep the changes made in the release branch — such as the bug fixes — we need to merge those back into develop.
  • Now we may remove this particular release branch.

Hotfix Branch

  • May branch off from:     master
  • Must merge back into:     develop and master
  • Branch naming convention:     hotfix-*      e.g. `hotfix-1.2.1
  • Hotfix branch is for fixing severe bugs found in production.
  • It is branched off of the master. Branching off of develop branch is most likely not an option since it's unstable at the time.
  • Merge this branch into master once the hotfixes are finished.
  • Now merge it into the develop branch too.

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

  • Finally, you may remove this hotfix branch! 🎉🚀🎉

Source: http://nvie.com/posts/a-successful-git-branching-model/

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