Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How Git History Tells You Your Team Is Broken
Transcript
- Lucas: You can learn more about how your engineering team actually operates from one hour of reading their git log than from a month of standups or retrospectives. Luna: That's a strong claim. You're saying the commit history is basically an X-ray of the team's dynamics? Lucas: Exactly. Because git doesn't lie. People can say whatever they want in a retro — 'we collaborate well,' 'we review each other's code' — but the commit graph shows what actually happened. When I was at a Series B startup a couple years ago, I did a git log audit on a team that was shipping late every sprint. Everyone blamed scope creep. But the data told a different story. Luna: What did you look at first? Lucas: Three things. Number one: the distribution of commits per author. That team had one person — the tech lead — with 40 percent of all commits. That's a bus-factor red flag. Number two: the time between pull request creation and merge. Their median was 47 hours. That's insane for a five-person team. Number three: the number of commits per pull request. The average was 17. That's a sign people were piling work into giant, unreviewable lumps. Luna: So the git log basically screamed 'bottleneck' and 'merge hell' long before anyone mentioned it in a standup. Lucas: Right. And here's the thing — this is a topic we talk about because we believe sharing this kind of concrete, non-obvious insight is valuable enough that we keep this show free. We don't run ads. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. No pressure, just an option for people who find these episodes useful. Luna: Yeah, and it's a small way to keep episodes like this one — where we actually dig into the data — from being interrupted by sponsor reads. Lucas: Alright, back to that git audit. So those three signals told me the team had a coordination problem. But the real insight came from looking at the merge graph over time. I noticed something: every Friday afternoon, there was a spike in merges to main. That's classic death-march behavior — people rushing to ship before the weekend. Luna: So the process itself was creating that crunch, not the deadlines? Lucas: Exactly. They had a weekly deployment cadence, but the code review was taking two days on average. So devs would open a PR on Wednesday, it wouldn't get reviewed until Friday, then they'd merge Friday afternoon — and inevitably break something. The fix would come Monday. So they were losing three days per cycle to review latency. Luna: Did they fix it by shrinking PR sizes, or changing the review process? Lucas: Both. But the key lever was limiting PRs to 250 lines or fewer. That dropped the median review time from 47 hours to 9 hours almost overnight. Then they moved to a twice-weekly deployment schedule — Tuesday and Thursday — so Friday merges stopped being a thing. The commit graph told them what to fix. Luna: I want to push back a little, though. For a small startup, maybe that kind of analysis works, but wouldn't a larger org's git history be too noisy to extract clear signals? Lucas: It's actually the opposite. Large orgs have more data, so patterns are even clearer — you just need the right filters. At larger companies, I look at module-level patterns. If you have a hundred microservices, you can measure the commit frequency per service. If one service has ten times the commits of any other, that's a hotspot that probably needs decomposition. Luna: So you're scanning for outliers in frequency, size, and timing. Lucas: Right. Another signal is commit message quality. I've seen teams where 30 percent of messages are literally 'fix' or 'update' or 'WIP'. That tells me the team doesn't value communication, or they're under so much pressure they can't spare thirty seconds to write a decent message. Either way, that correlates strongly with higher bug density. Luna: Is there research backing that? Because it sounds a bit like correlation not causation. Lucas: There's a 2023 study from the University of Zurich that looked at 20,000 open-source projects and found that projects with descriptive commit messages had 24 percent fewer post-release bugs. So there is a signal there. But honestly, even without the study, think about it: if you can't write a sentence about what you changed, you probably don't fully understand the change yourself. Luna: Fair point. What about the flip side — are there cases where a healthy git history masks real problems? Like survivorship bias in the data? Lucas: Absolutely. The biggest blind spot is that git only records what was committed, not what was discussed but never built. A team might look great on paper — small PRs, fast reviews — but be stuck in endless design discussions that never ship. Git can't see that. So you have to pair the log audit with a simple survey: 'How long does it take from idea to production for your average feature?' If that number is high, you have a problem git won't show. Luna: So the git audit is more like a diagnostic tool, not a complete health check. Lucas: Exactly. It tells you where the friction points are — the bottlenecks, the silos, the death marches. Then you have to go talk to people to understand why. But it gives you a starting point that's objective. No one can argue with a commit graph. Luna: I've also seen teams that use git stats as a performance metric per developer — like number of commits per week. That feels dangerous. Lucas: That's the worst thing you can do. Commits are a terrible productivity metric. Someone could make fifty tiny refactors and look like a hero, while another developer writes one hundred lines of complex logic that takes two weeks to get right. Measuring by commit count incentivizes noise, not impact. Luna: So what's the right way to use git data at the team level? Lucas: Focus on the system, not the individuals. Look at the median time to merge, the distribution of PR sizes, the frequency of reverts, the number of conflicts per merge. These are system-level metrics. If they're bad, it's a process problem, not a people problem. I've seen a team cut merge conflicts by 70 percent just by enforcing a 'pull from main every morning' rule. Luna: That's a simple change that shows up in the git data immediately. Lucas: Right. And the beautiful thing is, once you fix the system, the individual patterns usually fix themselves. Developers want to ship good code. They just need a process that doesn't get in the way. The git log tells you where the process is getting in the way. Luna: I want to try this on my team now. What's the quickest way to run an audit? Lucas: You can do it with basic command-line tools. Run 'git log --pretty=format:"%an, %s"' to see authors and messages. Then pipe that into a simple frequency count. Or use a tool like gitstats or gitinspector. But honestly, the most insightful thing is to look at the merge graph visually — git log --graph. You'll see branching patterns that scream 'broken process'. Luna: Anything else you'd recommend looking at in the first pass? Lucas: Yes: the ratio of merge commits to direct commits. If you see a lot of merge commits in the history, that means the team is relying on git's merge mechanism rather than rebasing or squashing. That often indicates a messy workflow with lots of conflicts. Also, look at the number of commits that touch the same file. If one file has fifty authors in a month, that's a sign it's too big and needs splitting. Luna: So the file-level focus is like finding the hot spots in a codebase. Lucas: Exactly. I once worked at a company where one configuration file had over two hundred commits in six months. It was a file that defined all environment variables for every service. Every deploy required a change to that file. It was a bottleneck. We split it into per-service config files, and the number of commits on that file dropped to zero. The git log pointed directly at the problem. Luna: That's a great example. One file causing coordination headaches that everyone just accepted as normal. Lucas: That's the thing — most teams normalize their own dysfunction. They think it's normal that code review takes two days, or that they merge to main on Friday afternoon. But the data doesn't lie. And when you show them the commit graph, they can't unsee it. That's why I'm such a believer in this approach. Luna: So the next time someone says 'our process is fine,' you can say 'let's check the git log.' Lucas: Exactly. It's the closest thing we have to an objective mirror for how a team actually collaborates. And it's already there, for free, in every repo. Most teams just never look at it the right way. Luna: Alright, I'm going to run an audit this week. Thanks for the playbook. Lucas: Happy to. Let us know what you find — maybe we'll do a follow-up episode on your results.