Git Cheat Sheet

Few days ago I tweeted, and Google plus-ed (is that a word?) this neat little Git guide. I really liked it, because it was simple, kept things basic, and condensed all the commonly used commands in one place. Unfortunately the presentation style format meant that while the information it contained was very useful, looking up commands required a lot of scrolling or Ctrl+F’ing. In other words, it was a nice learning guide, but not a good reference material.

What I really needed was a one page sheet I could pin to the cubicle wall on my desk, and consult the next time I forget how to tag a specific commit, drop all local changes and etc.. So for my own convenience, I have decided to distill and your enjoyment I have decided to distil that guide into a bare bones, “most commonly used git commands” cheat sheet. Here is the result:

Click to download pdf version

Click to download pdf version

Bear in mind that this is not supposed to be a comprehensive or completionist reference material. Git is a complex beast, and people have filled entire volumes explaining all of it’s capabilities and use cases. I wanted to include only the commands that a new user would need for regular, day to day work – nothing special, no difficult circumstances. Just basic stuff.

The cheat sheet is naturally a work in progress. I have been toying around with a rough draft version of it here for a few days now. I know that several of my readers here have been using Git much longer, and are much more proficient at it. So here is a question to you: what else should I add there? Am I missing anything useful?

Also, what are your favorite git tricks that you would like to share with people just getting into it, or jumping over from Subversion or Mercurial for example? Let me know in the comments.

This entry was posted in programming and tagged . Bookmark the permalink.

2 Responses to Git Cheat Sheet

  1. Rebase. Twice.
    (ps. you can use git rebase to destroy stuff.)

    1) I work in feature branches, and so there comes a time when your development /master branch is changed (pull someone else’s changes, do a bugfix or something). You then do a “git rebase master” from your feature branch to get up to date, moving the base of your branch along the timeline.

    2) Make commits nicer. You do a commit “fix issue 2715”, then minutes later do a commit “fix issue 2715 + added missing file”. Now you want to push this, but that looks… not nice. Do “git rebase -i” (interactive), select which commits to squash, edit commit message and there you have only one commit for that fix. Nice and easy. Don’t do this after pushing to a public repo/branch, as it might cause a space/time anomality.

    Also stuff I need to have written down (or needed to have written down):

    Removing deleted files from the repository

    To find files that are deleted on disk, but exist in the repo – git ls-files –deleted.
    To mark those files as deleted in the index – git ls-files –deleted | xargs git rm #remember to commit.
    To add all changed (modified + deleted) files to the index – git add -u #this does not add untracked files.

    Finding branches that are not merged back to master

    git branch -a –no-merged master #shows branches that are not done.

    These “tricks” are picked up different places a long time ago. I don’t remember where, other than “google”. Their usage are colored by how I use(d) git – I create branches for features, bugfixes, testing, other peoples public repos. I never do work directly on a project’s master branch, but merge into it when done.

    Oh, and “git stash” puts your non-commited changes in a temporary holding stack – nice to do before rebasing or switching around. You can do “git stash apply” or “git stash pop” to get your changes back again.

    Reply  |  Quote
  2. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    @ Tormod Haugen:

    Uh, nice stuff. I like the stash trick.

    Oh, another neat thing is:

    git rm --cached filename

    It removes tracked files from the index and if you commit and push it will purge them from the remote as well. I had to do this for two of my python repos when I realized I was tracking the .pyc files which change at each run.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *