editione1.0.1
Updated August 7, 2023While 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.
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.