Git Workflow

Git

If you have never used git before please try to learn the basics first. We can recommend the Git Community Book or the Pro Git Book.
Both are free to read.

Overview

TODO replace master with develop? (why)

The general process for working on Catacomb-Snatch is:

1. Fork on GitHub
2. Clone your fork locally
3. Create a local branch git checkout -b myBranch
4. Work on your feature, spiking/prototyping as required
5. Rebase if required (see below)
6. Push the branch up to GitHub git push origin myBranch
7. Send a Pull Request on GitHub

You should never work on a clone of master, and you should never send a pull request from master - always from a branch. TODO explain reasons

Please do not include hidden gems (i.e. updated libs, different framework version, etc.) in your pull requests. Our time is just as limited as yours, so we shouldn't have to pick out the relevant pieces.

Handling Updates from Upstream/Master

While you're working away in your branch it's quite possible that your upstream master may be updated. If this happens you should:

1. Add upstream to remotes - only needed once git remote add upstream git://github.com/Maescool/Catacomb-Snatch.git

2. Stash any un-committed changes you need to

3. Switch to the master branch git checkout master

4. Pull latest changes from upstream git pull upstream master

5. Switch back to feature branch git checkout myBranch

6. Rebase from current master git rebase master myBranch

7. Push latest changes to your remote master git push origin master - (optional) this makes sure your own remote master is up to date

   This ensures that your history is "clean" i.e. you have one branch off from master followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, master.

   If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line.

Sending a Pull Request

While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it.

Please do NOT include several unrelated improvements into one pull request.

When you're ready to go you should confirm that you are up to date and rebased with upstream/master (see "Handling Updates from Upstream/Master" above), and then:

1. Push your feature branch to origin git push origin myBranch
2. Send a descriptive Pull Request on GitHub - making sure you have selected the correct branch in the GitHub UI!
3. Watch for comments on your pull request. You can always add commits to your branch to improve your request.