【My Study Note】Blame
Blame
One day you might be overseeing a big team of developers. Can you imagine how complex it gets to keep track of everyone to changes and updates to files?
Fortunately, git has a very helpful command for keeping track of who did what and when. It’s called git blame.
One of the core functions of git is its ability to track and record the full history of changes for every file in the repository. In order to view and verify those changes, git provides a set of tools to allow users to step through the history and view the edits made to each file.
The git blame command is used to look at changes in a specific file and show the dates, times, and users who made the changes.
Git Blame
git blame Feature.jsAfter pressing Enter, git returns a list of all changes on the file. To understand what is happening, let’s break down the blame messages and go through it line by line.
Brake down of blame messages
Firstly, let me guide you through the format of each line. Every line will start with the ID and then the author, the date and time when the change was made, and the exact line number where the change occurred. Then the actual change or content is also returned.
The ID is a reference ID of the commit. The same ID might appear in several lines. This happens when a single commit has been made by the same developer. The author is the person who created the commit. The timestamp is the date and time when the changes were committed. Line number represents the location in the file or the exact line where the changes were made. The content is the code that was added to the file.
If you want to exit out from this blame message, you can do that by clicking on Q.
Tips
Tips 1
In a lot of cases, you will work with very large files and then you need a way to abbreviate the output or chop it down based on, say, line numbers. Fortunately, git blame offers a flag for that.
git blame -L 5, 15 fileNameTo do this, you can type git blame and pass in the flag of -l and specify the starting line number and the end line number, and also the file name. This time, a smaller subset is returned that only starts at line 5 and ends on line 15.
Tips 2
You can change the format of how the list is displayed. This is similar to what you can do with the ls command on the Unix commands. You can also pass in a -l flag for changing the output itself.
git blame -l fileNameThis time, there are a few changes to the output. For instance, the hash dash ID is in its full length form. It’s not in the shortened version. The output is now a bit more detailed. You can also control if you want to show email addresses or change the date format. These are the examples of the various things that you can do.
Tips 3
You can see detail changes or the actual commit changes of a specific hash dash ID.
// ad7df639 is a short version of hash id
git log -p ad7df639This gives you the actual change that occurred.
Difference between git blame and git log
Just to clarify, git blame will display to you the point where it was changed, git log will give you the detail of the change. I always use the two in conjunction to get more details about what changes occurred.