My Git cheatsheet

“Good judgement comes from experience, and often experience comes from bad judgement.”

~Rita Mae Brown

I am pretty sure Rita Mae was talking about Git when she said that. Git is complicated and I don’t think you can really feel comfortable with it until you have created a few disasters with it and hopefully recovered from them using it. I’m no git guru, but I am starting to know a thing or two and I thought I would write down a few of the things that have come up a few times for me. I’ll be adding to this as new ones come up for me. Corrections or suggestions are welcome.

Seeing uncommitted modifications.

Quite a few times I have seen a file listed in git status as modified and thought “What changed in there?”. Essentialy what you are asking is whats the difference between the file pointed to by HEAD and the file.

mike@sleepycat:~/projects/myapp$ git diff — HEAD app/controllers/ceo_controller.rb

diff –git a/app/controllers/ceo_controller.rb b/app/controllers/ceo_controller.rb

index 927112d..3efc1fa 100755

— a/app/controllers/ceo_controller.rb

+++ b/app/controllers/ceo_controller.rb

@@ -26,6 +26,11 @@ class CeoController < ApplicationController


+ def claimed_reward

+ @claimed_reward = @member.claimed_rewards.find(params[:id])

+ show_image

+ end

def gm_preferences


git diff will show all changes in all files.

Adding something to your last commit.

Inevitably after triumphantly committing a piece of code there will end up being some other thing you need to do. Perhaps its suddenly realizing the debugger statement is still in there, or realising that some comments would be a good idea.

…make changes…

git add -u

git commit

Oops! Forgot something

…make changes…

git add -u

git commit –amend

Undoing a commit –amend

Sometimes my last commit doesn’t end up being what I thought it was. Accidentally tacking a minor bug fix onto a merge commit with –amend is kind of goofy, so to undo it:

git reset –soft HEAD@{1}

For more info on the HEAD@{1} or related syntax like HEAD^, you want to look up treeishes.

Step back one commit.

git reset –hard HEAD^

The command above moves the head pointer back one commit and gets rid of the changes.

git reset –soft HEAD^

This would also move the head pointer back one commit but the files you changed would be visible as “modified” when you run git status.

If you are using Heroku to host your project there is an additional consideration. Stepping back one commit means that your remote master on the server at Heroku is further ahead than your local repo. When you try to push you are going to get this:

! [rejected] master -> master (non-fast forward)

The answer is; force it.

git push heroku master –force

Deleting merged branches.

Working with branches is great but it won’t take long before you end up with a pretty long list of branches. Prune your branches with

git branch -d name_of_branch

This will only delete the branch if it has been merged into the current branch. So:

git checkout master

git branch -d facebook_stuff

would only delete the facebook_stuff branch if it had been merged into the master branch already.

Adding a remote.

Out of a general sense of paranoia I periodically have a need to clone the main repository. I’ll try some experiment, fix something… whatever. and then ocaisionally I will want to send the results to staging which I have set up as a remote. The problem is that my staging remote is set up on the original project not the clone so I have to create it again. Since I have had to look this up a few times. This command will show the details for the repo I have titled “staging”:

git remote show staging

Doing that on my original project shows me the address of the repo which I copy to the clipboard and, switching to the newly cloned copy repo, can recreate my link to staging there. This will create a new remote titled staging pointing to an app on

git remote add staging<my_app_name>.git

Ignoring files and directories with .gitignore

Create a file in the root of your project called .gitignore. Add whatever rules you need. What you see below will ignore everything in the log directory and the tmp/sass-cache/ directory as well as any file with a .orig extension.


Somewhat counter-intuitively you need to add the .gitignore file to your repo. For some reason my instinct is that is should somehow be ignored as well but my understanding is that you want it under revision control as well so add it and away you go.


2 thoughts on “My Git cheatsheet”

  1. staging is a poor name to use for a remote repository. It is easily confused for the staging area (index) by newbees to Git.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s