This post is part of my Git for Writers series, which I’m posting as an accompaniment to my Git Started: Git for Agile Writers workshop at the STC 2015 Summit in Columbus, OH. These posts expand on some of the ideas I’ll be presenting, since you can’t cram everything on such a large subject into one 45-minute workshop.
If you’ll be at the Summit, I look forward to seeing you there!
One of the most important reasons for Agile TechComm professionals to use Git is Git’s extensive set of archaeological commands. (For some more of the reasons why I think writers need Git, read this post.)
This post covers the somewhat-passive-aggressively named “git blame” command. This command gives a line-by-line accounting of who last made changes to each line in a file. It’s extremely useful for those pesky situations when you find places in documentation that should have been updated with some change, but weren’t. (Not that this ever actually happens to any of us, of course!) You can find the source of the change, and from there trace any other changes that happened that the same time that might also have been missed, and figure out who your best resource is for questions.
If I know that I need to update documentation because the page title for index.html changed, I can run “git blame” to see the specific commit information for that file.
I can see that the change occurred on March 9th, who made the change, and I can use the commit ID to find out more information about the commit, including what other files it might have changed. (A post about how to do that with git log is coming soon!)
Like most git commands, git blame some options that make it even more useful.
Adding -C to git blame is helpful if the code in your project has recently been refactored. It retrieves the “blame” information from whenever that code was really last updated, and not just the information on when it moved to its current file. (Of course, if the code was updated at the same time that it was moved, this won’t be helpful.)
This post only scratches the surface of the options for this command, listing some of the uses that I’ve found to be most useful in an Agile environment. If you want to go into further depth, I highly recommend Pro Git (it’s free!). Of course, you can also run “git diff –help” to view the Git Manual for the command.