Unpacking a Risky Git Workflow: Why Clear Git Metrics Matter

The world of software development is constantly evolving, and with it, the strategies teams employ to manage their codebase. While established Git workflows like Git Flow or GitHub Flow provide clear guidelines, sometimes teams explore non-standard approaches. A recent discussion on the GitHub Community highlighted one such workflow, sparking an important conversation about its potential pitfalls and the critical role of understanding your team's unique git metrics.

A Workflow Under Scrutiny

The discussion, initiated by zhoj02, presented a workflow that raised eyebrows:

1. Checkout main and create a feature branch off main instead of develop
2. Implement the feature on the feature branch
3. Merge feature branch into develop and resolve conflicts
4. Deploy develop to the dev Kubernetes cluster for testing
5. Merge feature branch directly into main bypassing develop → main promotion path

At first glance, this might seem like a way to accelerate feature delivery to main. However, as community expert CalderMatt09 quickly pointed out, such a workflow carries significant, often hidden, risks.

The Hidden Dangers: Divergence and Debugging Nightmares

CalderMatt09's response cut to the core of the issue: "Not crazy, but it's the kind of workflow that works fine until it doesn't and then it really doesn't." The primary concern lies in step 5, where the feature branch merges directly into main after having already been merged into develop and potentially resolving conflicts there. This creates a dangerous divergence:

• Inconsistent Conflict Resolution: When the feature branch is merged into develop, conflicts are resolved. If these resolutions involve logic changes, and the same feature branch is then merged directly into main without reapplying those specific conflict resolutions, main and develop can quietly diverge.
• Untested Production Code: The version of the code deployed to the dev Kubernetes cluster (from develop) has undergone conflict resolution. The version eventually merged into main (and subsequently to production) might not include those same resolutions, leading to a different codebase in production than what was thoroughly tested. This gap is a breeding ground for subtle, hard-to-diagnose bugs.
• Erosion of Trust: Such discrepancies can erode trust in the testing process and lead to increased debugging time, impacting overall developer productivity and team morale.

Why Clear Git Metrics and Process Understanding are Crucial

While this workflow might appeal to smaller teams looking to reduce "unnecessary ceremony," CalderMatt09 emphasizes that if adopted, it requires extreme caution. "If you're going to do it this way you at minimum need a solid pre-merge checklist and someone who understands exactly what was resolved in that develop conflict before main gets touched."

This discussion underscores the importance of understanding your team's specific git metrics. Metrics like merge conflict rates, branch divergence over time, and deployment success rates can highlight the hidden costs and risks of non-standard workflows. Without clear visibility into these metrics, teams might unknowingly introduce vulnerabilities into their release pipeline.

For engineering teams, prioritizing a robust and predictable branching strategy is paramount for maintaining code quality and ensuring what's tested is what's deployed. While flexibility is valuable, it should never come at the expense of consistency and reliability. Evaluating your team's workflow against key kpis for engineering teams, such as defect escape rates or mean time to recovery, can help identify if your branching strategy is truly serving your productivity goals or inadvertently creating technical debt.

Ultimately, the "best" workflow is one that your team understands, trusts, and can consistently execute, backed by clear communication and a commitment to quality. Before adopting any non-standard approach, consider the long-term implications and how you will measure its impact on your team's efficiency and the stability of your product.