My git cheat sheet

I wrote this while I was getting the hang of using git in my current role. Over time I’ve added to it but to be honest, I rarely have to refer to it now.

If you’re wondering at the shorthand ‘g’ rather than ‘git’ it’s because I use oh-my-zsh with the git plugin (the dev VM I use at work runs Ubuntu and it also plays nice with OS X. Windows users can suck it). You can get a similar result by aliasing git commands.

Initial Setup

g clone
g pull

If you don’t know those two, stop reading now.

Given I currently work with over half a dozen repositories on a daily basis, I needed a way of pulling the latest changes quickly. The repos tend to change quickly so this script speeds things up:

find . -maxdepth 1 -type d -print -execdir git --git-dir={}/.git --work-tree=$PWD/{} pull origin master \;

Branching stuff

Creating a new branch is easy, just

g branch feature/Some-meaningful-feature-name

Add and commit changes in one hit with

g commit -a

then type your commit message. The project I’m on is using open source conventions for git commits.

How often you commit your changes will depend on your project. I commit often to prevent loss of changes, mainly because of the numerous repository problem/requirement I mentioned above.

g push

Will push your changes to github. I do this a couple times a day, usually after a

g merge master

Pulls changes that others have merged into master and merges them into the current branch you’re working on. I’ve learnt to do this at least once a day, more if there are a lot of changes that have been completed and merged in. It’ll depend on the frequency of changes and how necessary they are to your particular piece of work. Hint: Don’t leave this for a week or so and then try and do it just prior to trying to merge your own changes into master. Merge hell doesn’t begin to describe the problems.

Review Changes

When you’re notified of a pull request and you want to review changes (assuming you don’t have enough work to do already), start by making sure you have an up to date list of branches locally.

g branch -a

will pull down all branches from github.

g fetch -p

will clean up your local branch list. If you don’t do this regularly you can end up with a lot of rubbish floating around from dead branches (see Cleaning Up below).

To switch branches to review, first

g pull

to ensure you have the latest changes. Find the branch you want and check it out locally.

g checkout feature/Branch-name-to-review
g pull

Removing Changes

When I was first getting the hang of git and the functional stack for the project, I’d make the occasional change that would screw everything up. If you do the same and want to back out a change to a specific file

g checkout -- [filename-to-reverse-changes]

If you really fuck up (never done that, promise, ahem) you can always

git reset --hard origin/master

This is a last resort though; every change you’ve made after your last commit will be removed. Use judiciously.

Merge to Master

I tend to use the Github interface for the merge to master. Not all merges are smooth and can be done automatically. If your code base changes frequently you’ll likely need to do some cleaning up and merging in before you merge everything back to master.

There are a few caveats and warnings however:

  • Only merge to master if the test suite is passing
  • Don’t just run code for your tests – run ’em all and make sure you haven’t broken something in making your changes
  • Don’t merge unless someone has reviewed your work (at least for co-located teams)

Cleaning Up

Once your changes have been merged to master, don’t leave that trash sitting there cluttering up the repository. Delete that shit, starting locally

g push branch -d [branchname]

And don’t forget to do the same with the remote

g push origin :[branchname]

Or you can do the same via the Github UI.


Tab completion works for filenames assuming your local repo matches the remote. Useful for stupidly long feature names.





Leave a Reply