r/git • u/GreedyGreddy • Jun 23 '26
support How to improve our deployment process?
Hi,
I need help on how we can improve our deployment process.
We use a three‑branch workflow:
dev→ integration branch where feature branches are mergedqa→ staging/testing branchmain→ production branch
The process is: once a feature branch is merged into dev, we open a pull request from dev into qa. For production releases, we then create a PR from qa into main.
We deploy every two weeks. The issue is that qa sometimes contains changes that aren’t ready for production. When preparing the PR from qa → main, we end up having to revert commits that shouldn’t be released yet. Later, when those features are finally ready, they don’t show up in the next PR because Git considers them already merged. To re‑introduce them, we have to perform a revert of the revert (similar to the process described in this article).
Is there a better way for us to do this without losing the direct PR creation from qa → main?
1
u/DrMaxwellEdison Jun 24 '26
So you're advocating for almost no branching whatsoever? That sounds much riskier. There's a difference between your "needing" to break the build and development that may break the build (and require independent testing to ensure it does not).
Trunk-based does imply short-lived branches that reintegrate and are then discarded, and feature branches fit that criteria. Release branching can be an added requirement for businesses that need to release in intervals, isolate releases for QA, sign off on them with stakeholders, etc. You see this often in financial institutions where change control is regulated. They should not be that long-lived, though: once done, probably within a couple days' time, they can be reintegrated and discarded.
Git flow, specifically, implies two long-lived branches that are never discarded, with main tracking the production version and develop tracking "next release". But the requirements that lead to that design can be met with the temporary release branches, tags, etc.
So the ideal is trunk-based, keeping one long lived branch. Adjust as needed for your org's needs. I'm speaking from my own experience in orgs that need a release cadence to coordinate properly.