Branching
-
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 (contain the latest stable version at all times)
-
When to commit on it:Never. Only merge the release branch when releasing a new version.
-
-
vanilla: special branch for the vanilla version (independant from the rest)
-
When to commit on it:When you work on the vanilla version.
-
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!
One of the reasons is to avoid letting release and develop differ too much ; otherwise we can't easily bring back any hotfix to develop. It's better to use specific branches for such features, that will be merged to develop at the right moment (hopefully where no more release bugfixes are to be expected).
Also, more obviously, adding something like "campaign mode" can't be done in one commit, so better let the devs do their mess in their own branch and notify the others when it's ready.