The Wiert Corner – irregular stream of stuff

When joining or assessing a team or taking up a codebase, be sure to run these five git commands to get a quick overview on the state of affairs: [Wayback/Archive] The Git Commands I Run Before Reading Any Code

These five commands take a couple minutes to run. They won’t tell you everything. But you’ll know which code to read first, and what to look for when you get there. That’s the difference between spending your first day reading the codebase methodically and spending it wandering.

This is the first hour of what I do in a codebase audit. Here’s what the rest of the week looks like.

Via [Wayback/Archive] Jocelynephiliac :reclaimer:: “This all really good, love thi…” – Twipped Social (Private):

This all really good, love this. It’s all analyzing social behaviors, not code at all.

“Five git commands that tell you where a codebase hurts before you open a single file. Churn hotspots, bus factor, bug clusters, and crisis patterns.”

The commands:

The Git Commands I Run Before Reading Any Code

Command	Aim
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20	The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.”
git shortlog -sn --no-merges	Every contributor ranked by commit count. If one person accounts for 60% or more, that’s your bus factor. If they left six months ago, it’s a crisis.
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20	Same shape as the churn command, … Files that appear on both are your highest-risk code
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c	Commit count by month, for the entire history of the repo. I scan the output looking for shapes. A steady rhythm is healthy.
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'	Revert and hotfix frequency. A handful over a year is normal. Reverts every couple of weeks means the team doesn’t trust its deploy process.

--jeroen