They're a workflow architecture problem — and it's largely GitHub's fault, not yours.
Your developers are acquiring locks on each other without knowing it.
The pre-release crunch where everyone's fighting merges isn't bad luck or weak git skills. It's a deterministic output of a workflow pattern that GitHub nudges every team toward — and that git was specifically designed to avoid.
The correct workflow is documented in gitworkflows(7), which ships with git. It's written for mailing-list-based open-source maintainers, so most teams have never seen it translated into GitHub terms. I've done that translation and applied it to working engineering teams.
Not a branded methodology or a certification.
About a week of expert intervention, and you're free.
How much is the current workflow costing you in engineering time?
A typical engagement costs $8k-$15k — that's a 1583% ROI over year one.
What an engagement doesn't look like: courses and certifications, mandatory tools, more external dependencies. You can be done in a week, forever.
git bisect starts giving useful answers againI'm a contributor to git and have studied the git.git development process closely. The workflow I teach is adapted from the methodology Junio Hamano uses to maintain git itself — the same approach documented in gitworkflows(7) — translated for teams working on GitHub, GitLab, or similar platforms.
I've successfully applied it to engineering teams who previously had a single person handling everyone's version control problems — starting with times when that person was me. The goal is that that person gets their time back, and the rest of the team stops needing them.