Firstly, Git Blame's name is a bit silly. I propose renaming it git who-what-where-when-why or git 5w for short.

From the command-line, it outputs the file you specify, but each line is annotated with who changed it last, the commit message, and when it was changed.

That's not the most convenient use of it though. If you use VSCode, the GitLens extension has the best blame features. This feature is also available in other IDEs but GitLens is the best example I've seen.

• Who - Shown at the end of the current line and available on hover over the commits in the sidebar
• What - Shown in the commit message and the actual code
• Where - Shown in the code
• When - Shown in the commit dates
• Why - Shown in the commit message. Your commit messages may even have references to tickets/issues for you to quickly look up why.

Why was this useful for me?

I recently started my first full-time role that wasn't for my university. It's my first experience working on projects that have been created years ago. Our squad owns a lot of business-critical systems. Many code files in some of our critical systems have been modified by over ten people. Many of those people aren't in our squad anymore. They may have moved squads, moved tribes, or left the company.

Why is this useful, especially for new starters?

Firstly, as a new starter, you don't even know your team yet, let alone all of the people that have touched the projects your team owns. Sure, you can ask people what they have experience with, but you can't ask that question in detail - commit-by-commit, line-by-line. They won't even know anyway, no one can possibly keep track of who remembers the details of every file. By looking at who changed the code last, you can see who has most recently got parts of the code you need to change in their recent memory. At this point, if you are stuck, you may be able to ask the person, or ask if anyone knew them. People that didn't last change the code may not remember that exact change, but they likely will remember the person who changed it and their intentions. This is especially true if they are working in an agile way with daily standups, code review, squad code ownership and pair programming.

You can also begin to understand the history of the code. On an old codebase, there's tech debt. But you can't just go in and fix it all, it will be too much work. When you begin to understand the history of the changes, you can begin to understand why code was written in that way in the past. What would be the wrong decision now may have been right then. It may be that a decision was made then that have to stick with it for consistency. If there's parts that you can reasonably refactor, understanding the history will help you to understand the effects of your so-called "minor" changes. The changes in most recent months will help you to get clued in to the conversations you may overhear in standups or otherwise. After all, everyone else was around when those changes were made, they have them in some way in their memory. If you keep reading about these changes - you can begin to gain some context in your mind about what people are talking about - without having to ask.

It's low effort. As a new starter, you're already overwhelmed with information and unanswered questions. If you can quickly answer random questions about bits of code so you can free up others' time for more important or critical questions. You will be a quicker learner overall, having intuition rather than having to be told and taught everything.

Don't blame your teammates for your unanswered questions, just use git blame to ask honest questions of who, what, where, when and why.