Using Code Commits as Clues

Everyone’s busy. Code is committed every day. Yet the feature fails to ship. Have you ever had this happen on your team? No doubt. But how can you figure out what’s holding the team back? Code commits.

Yep, you can use your version control logs to uncover information about your team’s process and daily work habits. Let’s see how. I’m using Git in this exercise, but the technique should apply to any version control system.

Generating commit logs

The first step in the process is to grab the commit messages for the time period that you want to analyze. The git log command provides several parameters to customize the output and set of commits returned.

git log --pretty=format:'%s' --after=02/01/2020 > commit_messages.log

In the above command, we’re limiting the range of commits from the first of February to the current date. We’re able to achieve that with the --after option. The result is a file named, commit_messages.log, which contains a list of the desired commit messages.

Installing Kotlin

Our log file contains tons of commit messages like this:

Merge pull request #4742 from meetup/blah-blah-blah
Merge pull request #4756 from meetup/blah-blah-blah
Merge pull request #4888 from meetup/blah-blah-blah

These messages impact the resulting word cloud and I decided to strip them out. To avoid doing it manually I created a simple Kotlin script.

If you don’t already have Kotlin installed, you can do so with the Homebrew package manager. This is the command, brew install kotlin. You’ll now be able to run your scripts from the command line.

Cleaning up logs

I wrote a simple script that does the following:

1. Creates a new file that ends in “_clean”
2. Loops through each line of the provided file
3. Checks if it starts with “Merge pull request”
4. If it doesn’t, then it adds that line to the new file

How to run the script on your log file:

kotlinc -script commit_message_clean_up.kts -- -f commit_messages.log

That will result in a cleaned-up log file that strips out the pull request information.

Let’s use the contents to create our word cloud.

Installing Wordle

You can find Wordle here. Wordle generates word clouds from text that you provide. The clouds give greater prominence to words that appear more frequently in the source text. You can tweak your clouds with different fonts, layouts, and color schemes.

Analyzing the results

Now that you have your word cloud you want to look for the words that stand out. Although not scientific, LARGER words can tell you where you spend your time.

Words that stood out:

• Add
• Update
• Fix
• Test
• Event
• Search

What you want to see are words that relate to the in-progress feature development. In our case, we’re currently focused on the following tasks:

• Event screen updates
• Adding a new search flow
• Adding end-to-end tests

What you don’t want to see are words that indicate problems in your code or process. For instance, we see Fix, Refactoring, and Move also dominating our word cloud. This could mean that we’re spending a significant amount of time on bug fixes or technical debt tasks unrelated to the current feature work.

Next steps

Now that you’re empowered with some data, sit down and chat with the team. Share what you’ve learned and ask questions to uncover any potential issues in your team’s process.

I had a lot of fun looking at this data. I compared different time periods of commit messages. I looked at different repositories. Each time I learned something new. I would love to see what word clouds come out of your team’s Git logs.

For even more fun with commit logs, check out the book, Your Code as a Crime Scene. You’ll never look at commit logs the same again.