Recommended Free Tools
A hotfix shipped across three repositories can fail in ways a successful merge alone will not catch. In an account of a Git Flow release, tool author Çağatay Uncu describes four surprises: configuration-dependent tag ordering, a hotfix based on stale code, a build command that appeared to succeed without producing a build, and a second client pushing commits while local merges were still being verified. His response was gitdoctor, a checker intended to make release state and unfinished steps visible. Its features and the incident are the author’s account, not independent test findings.
How one hotfix became four surprises
The author says the team used classic Git Flow: main and develop as long-lived branches, with short-lived release/* and hotfix/* branches for customer releases. The example hotfix, hotfix/2.0.0-hotfix.12, had to ship in lockstep across one backend and two frontend repositories. Four open hotfix branches were in progress at once, without a clear rule for which should finish first.
Tag order was not self-evident
The author found that the first tag returned by a command using git tag --merged ... --sort=-version:refname changed after adding a versionsort.suffix configuration. Git’s tag documentation confirms that version:refname ordering can be affected by versionsort.suffix, and that the default ordering can depend on tag.sort. Automation that assumes “latest” means the first result should therefore define and test its ordering configuration rather than rely on an implicit default.
A hotfix started from a stale base
According to the author, hotfix.12 was opened before hotfix.11 had merged. In web.config, one change removed a comment block while the later hotfix inserted a rule above it. The author reports that merging the later hotfix to both master and develop then produced conflicts. The practical issue was not simply that Git reported a conflict: simultaneous hotfix work meant a branch could be based on a state that no longer represented the intended release line.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsA successful command did not mean a build existed
The author reports that Git Bash rewrote the MSBuild argument /t:Build into a file path. MSBuild returned status 0, but no build was produced. This is a specific environment incident in the author’s article, not a generally verified behavior of Git Bash. It illustrates why a release check should verify the expected output artifact, not just trust a zero exit code or a clean merge.
A second client pushed during verification
The author says a GUI Git client on the same machine pushed the same local commits while merges were being checked. The identical commits were harmless in that instance; different commits could have published code before verification or left the three repositories at different points in the release. The account highlights a coordination risk: multiple clients can act on shared repository state even when one operator believes a release is still being reviewed.
Rank #2
What the author says gitdoctor checks
Uncu describes gitdoctor as a Bash 3.2+ script with no jq dependency. The article says its only mutation is git fetch, and that it runs 51 checks, each with findings, explanations, proposed fixes, and recipe references. The count and capabilities are product claims reported by the author, not independently validated results.
- Repository state, including missing back-merges, tags not on
main, stale branches, and branches behindmain. - Release process and hosting signals, including release tags without a GitHub Release, pull requests against the wrong base, and missing branch protection.
The author says JSON is the default output and also lists text, Markdown, and SARIF formats. The article describes --explain as a way to show a check’s recipe. These formats and options may suit local review or CI integration, but the article does not establish independent compatibility testing across environments.
Can it forecast conflicts or recover an interrupted finish?
Conflict forecasting is not a build test
Git’s official documentation for git merge-tree says the modern command can perform a merge without making a commit or reading or writing the working tree or index. It reports conflict information and status. That makes it useful for forecasting conflicts between particular branch tips without changing the checkout. A clean simulated merge says nothing by itself about whether the project builds, whether tests pass, or what remote branches will contain later.
The finish-hotfix probe
The author describes --probe finish-hotfix as reporting whether steps such as merge, tag, push, back-merge, branch deletion, and GitHub Release are already complete. The tool is said to infer this from repository history and related GitHub information instead of maintaining a separate state file, so a finish workflow can be rerun after interruption. This recovery behavior is also the author’s description; it has not been independently tested here.
Coordinating three repositories
For multi-repository work, the article describes a workspace mode configured with .gitflow-workspace.json. It checks repositories together, offers one readiness gate before pushing, and compares tag type and message across repositories. The author also says gitdoctor can be used in CI or a pre-push hook.
These checks address coordination and repository-state visibility, but they should not be treated as proof that every repository built the intended artifact or that no other client can change remote state after a check. A practical release gate still needs explicit verification commands and expected outputs for each project, plus a clear owner for the push sequence.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What a release doctor should make explicit
The incidents suggest evaluating a release checker by the gaps it closes, not just its number of checks:
- Repository state: Does it identify missed back-merges, stale branches, misplaced tags, and incomplete release steps?
- Conflict forecasting: Can it test the specific branch tips to be merged without altering the working tree?
- Build evidence: Does the workflow confirm that expected artifacts exist, rather than infer success from an exit code alone?
- Cross-repository coordination: Can it compare release state and tag metadata across all repositories involved?
- Recovery: Can operators safely determine which steps are already complete after an interruption?
Uncu’s account presents gitdoctor as one approach to these problems; it does not evaluate competing tools. The article lists Homebrew, a GitHub Action at cagatayuncu/gitdoctor@v0.4.0, a Claude Code plugin, and an MIT-licensed GitHub source repository. These are time-sensitive availability and version details, so confirm the current package and integration information in the project’s own documentation before adopting them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
