2017-01-14
My picks for mind-blowing Git features
It started on Twitter:
@tobyhede: What git feature would you show someone who has used source control (but not git) that would blow their mind?
@thatcks: Sysadmins: git bisect. People w/ local changes: rebase. Devs: partial/selective commits & commit reordering.
Given that at different times I fall into all three of these groups, I kind of cheated in my answer. But I'll stand by it anyways, and since Twitter forces a distinct terseness on things, I'm going to expand on why these things are mind-blowing.
If you use some open source package and you can compile it, git
bisect (plus some time and work) generally gives you the superpower
of being able to tell the developers 'this specific change broke a
thing that matters to me', instead of having to tell them just 'it
broke somewhere between vN and vN+1'. Being able to be this specific
to developers drastically increases the chances that your bug will
actually get fixed. You don't have to know how to program to narrow
down your bug report, just be able to use git bisect, compile the
package, and run it to test it.
(If what broke is 'it doesn't compile any more', you can even automate this.)
If you carry local modifications in your copy of an upstream project,
changes that will never be integrated and that you have no intention
of feeding upstream, git rebase is so much your friend that I
wrote an entire entry about how and
why. In the pre-git world, at best you wound up with a messy tangle
of branches and merges that left the history of your local repository
increasingly different from the upstream one; at worst your local
changes weren't even committed to version control, just thrown on
top of the upstream as patches and changes that tools like svn
attempted to automatically merge into new upstream commits when you
did svn up.
If you're developing changes, well, in theory you're disciplined and you use feature branches and do one thing at a time and your diffs are always pure. In practice I think that a lot of the time this is not true, and at that point git's ability to do selective commits, reorder commits, and so on will come along and save your bacon; you can use them to sort out the mess and create a series of clean commits. In the pre-git, pre-selective-commit era things were at least a bunch more work and perhaps more messy. Certainly for casual development people probably just made big commits with random additional changes in them; I know that I certainly did (and I kept doing it even in git until recently because I didn't have the right tools to make this easy).
(Of course this wasn't necessarily important for keeping track of your local changes, because before git you probably weren't committing them in the first place.)
PS: There is one git feature that blows my mind on a technical level because it is just so neat and so clever. But that's going to be another entry, and also it's technically not an official git feature.
(My line between 'official git feature' and 'neat addon hack' is whether the hack in question ships with git releases as an official command.)