Useful git commands and quirks
Things I’ve learned from my first git experiences. First of all, git is inconsistent as hell. Every command has its own quirks and syntax, so I’m attempting to catalog some of them here. We’ve been using git svn at Planypus as a way to maintain local developer branches and still push to our svn as a central place which then triggers our integration server rebuild, cruise control, and so on.
First, make it look nice
$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global color.interactive auto
via tpope
Onwards to the commands…
If you’re using git svn and you want to see changes that you have comitted locally but have not yet dcomitted
git svn dcommit -n
This might give you output that looks like this
diff-tree e784cfa... e784cfa...
BUT, if you want to actually see the changes, what you want is apparently the ‘patch’ output:
git diff-tree -p e784cfa... e784cfa...
If you have uncomitted changes, it’s easy to see them
git diff
BUT, if you’ve already created your commit set (git add) but not comitted, you how have to use
git diff --cached
If you’ve accidentally added some files to your commit set and want to remove them from the index (untrack them), but leave the changes in your working tree
git reset HEAD [file/dir]
To undo local changes (revert in the svn sense)
git checkout [files]
Note that this works as long as the file is not yet in your index. If you’re already tracking it for commit, you’ll need to untrack it first using git reset HEAD [file] before you’re able to check it out.
You can also use this command to check out files from the past by specifying any commit hash:
git checkout [hash] [files]
It’s just that when you don’t specify the hash, it assumes HEAD.
If you’ve got changes you want to just throw away permanently, you can just reset:
git reset --hard
But reset is a powerful command that can also take you back in time. Let’s say you messed up the last commit, you can take yourself back to the way things were right before you comitted:
git reset HEAD^
Notice I didn’t use --hard because that throws away the changes. Instead, this form of the command throws away the commit by taking you to HEAD^ (one commit before HEAD), but it leaves the changes in your working tree. If you want the changes also to be left in your index (ready to be comitted) you can use
git reset --soft HEAD^
If you’re working on something and you decide you want to scrap it or work on it later
git stash
There are lots of fun things you can do with stashes but they’ve been covered on other blogs.
on merging…
If you’ve done a git merge and have some conflicts, launch git mergetool which will take you through the conflicted files one by one using your default merging tool (FileMerge, usually, on OSX) and let you merge them. However be careful. Either because of a misconfig on my end or some other quirk, FileMerge shows the file I pulled from svn as “LOCAL” while my file with changes is “REMOTE” which is counterintuitive to me and caused me to fubar a merge the first time I tried.
Take note that after the merge, you will have files ending with .orig left on your system so you’ll have to manually delete them, unless you have the config mergetool. set, but I haven’t tried this yet. Also, after the merge I was getting error messages about having a .git/MERGE_HEAD file, which I couldn’t find enough docs online for, so I just deleted it..and hopefully that did not fubar me.
Well that’s all for now. More might come as I learn to stop worrying and love the git.
P.P.S Many of these commands are not necessary if you use The Git Textmate Bundle and GitNub which integrate together and work very well!
8 Comments