git blame is about where you have been, not who did this (╯°□°）╯︵ ┻━┻.
When building a feature or fixing a bug, you will be reading the code that
exists. One thing I do often is ask, “Why was this done this way?”
Programming is not a binary profession. Fuzzy logic would be a better way to
explain how problems get solved. Just as programmers’ experiences vary, you can
find many solutions to get from 0 to 1. So, when I want to answer my initial
question, I leverage
git blame. Note: I am a vim user and use
from the fugitive VIM plugin.
From there, I’m able to see the SHA of the commit, along with the Author and Date. More often than not, I’ll plug that SHA into GitHub. From there, I can quickly get to the Pull Request (PR) where the specific code was introduced. This allows me to grab as much context, for the code in question, as possible. I, then, can either answer any questions about the code myself or reach out to whomever wrote it in the first place to gain a better understanding.
One thing I’ve noticed when doing this during pairing is the developer
not wanting to know who had written the code. Whether it comes from a self-blaming mentality, imposter syndrome, or any other negative thoughts, I feel as
though the name
blame is taken negatively. I’ve never focused on the aspect of
fault, intentional mischief, or wrongdoing inherent to the word blame. When acting
with empathy, one can understand the code works or was working, and insight into
how it got there can help you know where to take the code. I understand the name,
but maybe something like
git history would have less of a negative connotation.
Let’s look at
git blame in action.
Below, we have a Rails controller for admin functionality. We only have two authors on this particular section of code.
$ git blame app/controller/admin_controller.rb 98056642 (Author 1 2014-08-17 16:09:20 -0700 1) class AdminController < ApplicationController 14fcfdf1 (AUthor 2 2016-09-23 15:36:12 -0500 2) include AccountExporter 14fcfdf1 (AUthor 2 2016-09-23 15:36:12 -0500 3) 98056642 (Author 1 2014-08-17 16:09:20 -0700 4) before_filter :require_super_user, :except => [:index, :logout] 1f11be76 (Author 1 2014-08-19 00:34:38 -0700 5) layout 'admin', :except => [:stats, :show_stats] 305219cb (Author 1 2015-03-16 17:10:47 -0700 6) helper_method :sort_column, :sort_direction 98056642 (Author 1 2014-08-17 16:09:20 -0700 7) 98056642 (Author 1 2014-08-17 16:09:20 -0700 8) def index 98056642 (Author 1 2014-08-17 16:09:20 -0700 9) end
Not much has changed about this code in quite some time, but the layout is rather specific.
$ git log 1f11be76 commit 1f11be764b0e0a604102faed250a45fb6223a741 Author: Author 1 <email@example.com> Date: Thu Aug 19 00:34:38 2014 -0700 added more stats capabilities
In looking at what newer capabilities were added, let’s look at the diff from that commit and the one before it.
$ git diff 1f11be764b0e0a604102faed250a45fb6223a741^ 1f11be764b0e0a604102faed250a45fb6223a741 diff --git a/app/controllers/admin_controller.rb b/app/controllers/admin_controller.rb index 9840cd7..eda30b7 100644 --- a/app/controllers/admin_controller.rb +++ b/app/controllers/admin_controller.rb @@ -1,6 +1,6 @@ class AdminController < ApplicationController before_filter :require_super_user, :except => [:index, :logout] - layout 'admin', :except => [:daily_stats] + layout 'admin', :except => [:stats, :show_stats] def index @@ -35,15 +35,19 @@ class AdminController < ApplicationController session[:super_user] = nil end - def daily_stats + def stats + @stats = false + render :layout => 'plain' + end + def show_stats render :layout => 'plain' end
We can clearly see we renamed
AdminController#show_stats and added an
AdminController#stats method with
the same layout. So skipping setting the layout at the top of the Controller
As you can see,
git blame doesn’t have to be a bad thing. If you’ve never used it before, I hope you’ll consider starting. But remember to act with empathy. That’s key. If you have thoughts on how I use it or questions about using it
yourself, let me know. Leave a comment below.