(Or: "How to avoid making Bede cry")

Key point one: master is always a working demo. This is really important to remember... we don't know what might happen with illness, missing meetings etc. so it's really important that even if only one person turns up, we can pull from master and get a working game.

Key point two: we never push to master. This is because we can't test our code on one machine and be sure that it works for everyone. We've had enough problems switching between machines in the past!

Key point three: branch off development. I'll get into this in more detail further down, but development is the branch that we should be putting all our changes into -- so it makes sense that it's also the branch we should be basing all our changes on.

Key point four: use feature branches. Again, this will make more sense a bit further down. But here's the long and short of it: if you want to make changes, you make a new branch based on development, and then merge those changes back into development.

So how do you actually do it?

I'll try and explain using a couple of common scenarios:

  • Example 1: you want to write some new code: a new feature or a bugfix.
    Here's the steps you'll take to make a new Feature Branch:
    • Checkout (change branch) onto development
    • Make a new branch with a good name
    • Write your code on this new branch!
    • Push everything on this new branch to GitHub
    • Make a Pull Request on GitHub to merge this branch BACK into development
    • Get someone else to accept the Pull Request.

On the command line, here's what it looks like:

git pull --all  # Make sure we have the latest code to start.
git checkout development  # Change branch to development.
git checkout -b add-fairy-sprinkles  # Create our new Feature Branch and change to it -- two jobs in one!

# Make our changes to the code.

# If we haven't already, commit all our changes:
git add .
git commit -m "Added some fairy sprinkles."

# Push our new branch, complete with changes, to GitHub.
git push --set-upstream origin display-text

Now that we've got our new Feature Branch pushed to GitHub, we can make a Pull Request to ask if our changes can be put into the development branch.

Go to the main repository page and click New pull request to start. Then, make sure development is the "base" and your Feature Branch is the "compare" branch. This is because our code is based on the development branch, and we want GitHub to compare the changes we've made to the development branch.

Now talk someone else through the code you've written, and if you're both happy with it, they can accept the pull request! Congratulations -- you've now got your code in the development branch.

  • Example 2: You made some changes (and didn't add/commit them), but they're not on a Feature Branch

This is pretty easy to fix! Just do this:

git stash  # <-- Store your changes for later!

# Create a feature branch (skip this if you've already got one):
git checkout development
git checkout -b your-feature-branch


git checkout your-feature-branch
git stash apply  # <-- "Pop" your changes back.
git add .
git commit -m "Move changes onto feature branch"
  • Example 3: You made a feature branch based on development, but someone else merged their changes in the meantime. You want to use those changes in your code.

This is pretty common, and unfortunately a bit tricky to fix if you're not too comfortable with git. If we're unlucky, it'll involve merge conflicts (and you should call me!). But if we're lucky, you should be able to type this:

git pull --all
git rebase development

The rebase command rewrites history: it tells git that the changes we've made should be based on the latest version of the development branch -- rather than the one we originally started writing code on top of.

If all goes well with this command, you should be able to make any more changes you need and merge your feature branch into development where necessary just like normal.