Skip to content

Git branching model

mkalam-alami edited this page Feb 26, 2012 · 16 revisions

Branches list

  • develop: development version (and also the default Github branch)
    • When to commit on it: Most of the time.
  • feature/xxx: specific branches for all big refactorings & big changes/additions to the game
    • When to commit on it: When you work on feature xxx.
  • release: push bugfixes only to make the game stable and produce releases
    • When to commit on it: For hotfixes.
  • master: contains only releases
    • When to commit on it: Never. Only merge the release branch when releasing a new version.

Release workflow

Let's say a release has just been made:

  • We develop things on develop
  • Once we want to polish develop to make a release, we merge it with release

At this point, release will be unstable, but we can start fixing bugs there AND let people continue to add features on develop.

  • As we find bugs on the future release, we change them on release, but also merge them with develop to keep it up-to-date
  • Once we decide the release is ready, we merge it to master, and tag it to the right version number. If we find bugs, we commit them to release until we have a new minor version ready. Again, each finished minor version is merged to master and tagged.
  • Once the release is made, it's the right time to merge to develop any feature/xxx branch we want to integrate to the next major version
  • Loop!

Why "feature/xxx" branches?

The only trick is to avoid letting release and develop differ too much ; otherwise we can't easily bring back any hotfix to develop. That's why it's better not to push big refactorings/new big features in the "develop" branch, but on other specific ones.

Clone this wiki locally