Git tricks


Posted on 19 May 2014 by jose

I've been using Git at work exclusively for a while now (like on Hackwater, we've finally moved off of Subversion), and I just want to leave a note to myself outlining some of the useful things I've come across.

Starting with git config, I like to enable color and credentials (for temporary passwordless Github auth). Also, with nearly 40 git repos, having a global ignore list is incredibly useful. I'm still trying to decide on git aliases that I like; I'll maybe do another post when I've definitively come down on those.

I can't express my love for Git's cheap branching model enough. With tools like the (hopefully seldom used) git cherry-pick and git rebase (and the scary interactive rebase), my local branch garden is well-kept. git reset is great at reverting un-pushed but committed changes, as well as letting you set HEAD to a particular point in time (more history manipulation).

I'm still deciding on a workflow I like, and it's possible that I may use more than one depending on a project. I initially liked the git-flow workflow I saw on nvie.com, but I'm also a fan of Github's workflow. As a Drupal consumer and occasional contributor, I've also read and enjoyed Randy Fay's thoughts on a rebase workflow.

For miscellaneous commands, I like git add --patch (or -p) for when I'm working two different issues in one file. git clean keeps my working copy neat. git filter-branch is another one of those history re-writing tools (for me, anyway) that I've mostly used to remove large binary files from the repo/index; if you have a lot of medium-to-large binaries in version control (a bad thing in my opinion), and you have the opportunity to move them to a CDN or at a minimum, outside of the repo, it makes code deployments much faster if you can filter those large files out of the repo as if they had not existed in the first place. Use carefully (and like the filter-branch manual says, take a look at the BFG for mass cleans).

git filter-branch works best on a clone of a repo, as it gives you a chance not to trash your main working copy until you push and pull. Be absolutely certain you're ready to push, and then take advantage of the --prune=now and other git gc options, and to expire your reflog first.

Latest poll

Which do you favor?

Choices

Twitter