This post is part of my Git for Writers series, which I started 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 presented, since you can’t cram everything on such a large subject into one 45-minute workshop.
**For some more of the reasons why I think writers need Git, read this post.**
In this post, I’m using the concepts from my git log, git blame, and git diff commands to show how you might develop your own Git workflow. Of course, the exact workflow that’s most useful to you is going to depend on a lot of external factors (most importantly, the way in which your Agile team uses Git).
Before you can successfully start developing your own workflow, you’re going to need:
- Access to your team’s Git repositories and branches.
- Information about your team’s current project’s status.
- A basic understanding of how your team intends to work in Git.
Hopefully, in Agile development, most or all of this will be part of your team agreement. If not, the developers on your team should be able to give you this information pretty easily.
In a perfect world, you know the commit ID that you last looked at, or which commit was the first before your team started development. This is probably not a realistic expectation, though. It’s probably fairly reasonable, though, to assume that you know the date after which you want to look at commits.
If you want to see commits since March 1st, 2015, git log’s –after option gives me everything that you need. The oldest commit in the list is the commit to reference when running git diff to see the list of changes. (This is an excellent moment, too, to glance through the commit message for each commit.)
Get the list of changes…
To run git diff, you only need the short form of the commit ID, which consists of the first seven characters in the long form of the SHA.
What you do next depends on what you’re looking for… If you know for sure that you need to take a look at all of the changes, git diff dd53f32..HEAD will give me the long version of the diff:
If you have enough project knowledge, though, you may be lucky enough to only need the list of files from –name-only:
If you only document user interfaces, you might be able to safely ignore changes made, for example, to CSS files, and will only need to look closer at the other files. (In many cases, the commit messages that you read earlier will tell you what you need to know about backend-centric functionality changes.)
Checking the details…
Once you have the list of files to check, git diff and the filename should give you the details you need, with git blame as a backup if something you see in the diff doesn’t make sense. (You can always pull the commit ID from each line of the blame output, if you need to go back to that commit message for more information.)
This post only scratches the surface of the options that you can incorporate into your Git habits. If you want to go into further depth, I highly recommend Pro Git (it’s free!).