We use Git as a version control system in our development process and GitHub to host repository. Our workflow is similar to git-flow, but with some simplifications since our product doesn’t use versioning – the only actual version of our game is production. Well, it’s not completely accurate as there are also snapshots of the game on our internal servers, but production is the only version which is accepted for bug reports.
Linear vs. Non-Linear History
One of the most important criteria for us was having a linear git history letting developers traverse/bisect it easily to check for regression or bug sources. In case of non-linear git history it can be non-trivial:
Our git history for the master branch looks like:
Aside from allowing an easy git-bisect, this structure allows us to follow changes that were brought by a particular merged feature branch and revert it, if needed.
Development
For development our git workflow looks like:
Fetch a fresh copy of master:
$ git checkout master
$ git fetch -p --tags
$ get merge --ff-only origin/master
Create a branch on top of it:
$ git checkout -b forum-filtering-218
The name contains an issue number from the issue tracker.
Work on the code and commit your changes onto the feature branch. After some time hacking it’s worth refreshing the branch to make sure there are no conflicts with changes from the other devs:
$ bin/git-refresh
You can find a source of git-refresh here, but it rebases the current branch against a fresh copy of master effectively.
When the feature is ready to go public, refresh it once more and run the full test suite:
$ bin/git-refresh
$ prove -l
The latter is actually optional, because we have Jenkins hook on a pull request creation, which will perform a full run of our test suite against the published.
Publish the feature branch on GitHub:
$ git push --set-upstream origin forum-filtering-218
Create a PR and ask somebody to review it. If there are notes, fix the code and re-publish:
$ bin/git-refresh
$ git push --force-with-lease origin
When the reviewer is happy with the PR, merge it with master:
$ bin/git-merge-with-master
This script is similar to git-refresh, but in addition it creates a merge commit and pushes in on GitHub. That closes the PR automatically. Done! Another feature will be included to the next production update.
Deployment
Once a week we choose a point on the master branch, which includes recently completed features and fixes and tag it as a release and move the release branch to the same commit. Then this version gets pushed to the dev server where it is tested. Later it goes into deployment.
Conclusion
Perhaps with more developers we would need more formal rules or some extra tools, but we are very happy with our approach at the moment: it lets us spend less time figuring out git and leaves us more time for the development of new features for our game.