Read the History

1 link
From

editione1.0.1

Updated August 7, 2023

While git-blame shows you who made the most recent changes to each line in a file, sometimes you might be more interested in the history of a single file and how it’s changed over time. Git offers a useful tool called git-log that lets you inspect the commit logs for a given file.

Use the following command to view a reverse chronological list of commits where changes were made to a file:

$ git log <file_path>

This will give you a full history of all commits to the file so you’ll be able to see who made changes to it and, more importantly, when they made those changes. Just as with git-blame, you can use git-log to find the developers who made the most recent changes to a file, because they should be the ones you reach out to first.

If you suspect a bug is located in a certain file, use git-log to view when a file was changed and by whom. It’s extremely helpful if you know when a bug was first reported or when an error started popping up in your logs. You can use git-log to line up errors with changes made to specific files, which may help you pinpoint when bugs may have been introduced into the codebase.

​resources​

Log Some Data

As you’re reading through code, you will need to hold a mental model of the data in the system and how it is manipulated as the business logic is applied. Some code may be easy to follow, but you may find yourself deep in the codebase without any idea what the data looks like when it reaches a certain function. In these situations, it’s sometimes useful to lean on your logging system to print some data to your log files so that you can inspect it.

Add a few log statements with data you’re interested in. This could be certain values of variables or object properties, or it could be an arbitrary text string that will give you some useful information if you see it in your logs. Either way, setting log statements throughout your code is a quick and easy way to get a snapshot of what your data structures look like at a point in time when the code is executing. Sometimes, a well-placed log statement can reveal a bug you’ve been tracking down, or it can expose certain things that help you understand what the code is doing.

All programmers rely on logging to gain insight into what their code is doing, so don’t feel like it’s the wrong way to debug your code. Even the most experienced engineers rely on logging when they’re developing new features or tracking down a hard-to-find bug.

If you found this post worthwhile, please share!