I need help understanding a seemingly broken Git release flow

Question

First some context. Working in teams which use a CI environment, many people will know the typical Gitflow release process.

Without going into too much political detail, the company I currently work for has decided to "release features more often", up from a 2 week cycle where develop branch was merged upwards step-by-step all the way to main. The solution is to replace Gitflow with a weird variant I cannot seem to find anything about on the Internet. There are some influential zealots advocating against trunk-based workflow for CI/CD because feature toggles are "too much work".

So as a compromise, someone somewhere up the chain decided to force all teams to switch to a new shiny release workflow. I struggle to understand how to make it work with as little overhead as possible compared to Gitflow. And coworkers seem to struggle as well, as pull requests are now full of merge issues, conflicts and messy workarounds.

Here is the flow:

1. We still have main, preprod, staging and develop branches.
2. Feature branches (FB) are not created from develop anymore. They are branched off of staging.
3. When the feature is developed, the FB is now supposed to be merged into develop (!) after typical pull request reviews etc. This is where usually a lot of errors and merge conflicts now happen - I suppose due to what happens next.
4. The FB may not be deleted after merging.
5. A second merge request is created from the same FB to now be merged back into staging where it originated from.
6. The FB is deleted after this second merge and now staging is supposed to be downmerged into develop.

Essentially, the problem is that merge conflicts and git issues are now all over the place, cause massive overhead and lead to unsynchronized branches between develop and staging branches (e.g. code is exactly the same but git reports diffs).

Is this flow just really bad? Am I missing a step to properly work with it? Are we abusing git (it feels like it)?

Answer 1

Merging the feature branch into develop and staging as separate merges is definitely causing problems. Typically when I see branch names like "develop", "staging" and "preprod" the team is repurposing version control as a means to track what code is deployed in each application environment — this is not a problem version control was meant to solve.

Each feature needs to be integrated with the other changes that will be deployed to production. We want to treat code changes as some sort of conveyor belt where we can indiscriminately pull one feature off the conveyor belt if there are problems. This is ideal, but not reality.

At some point the team just needs to decide that something will be delivered to production. If QA finds problems, developers need to fix it — not revert the change. The team should not commit to delivering something at the QA testing stage unless they believe QA testing and bug squashing can be completed before the next release.

Changing how you use version control is only part of the fix. Some of these issues are workflow problems that must be addressed with the team. For example, merging into develop, another merge into staging, and then a merge from staging into develop forces the team to deal with 3 merges. Each time you merge, you can run into problems:

• Forcing developers to re-solve the same merge conflicts (once in the merge from feature into develop, and the second time from merging feature into staging).
• Each merge invalidates QA testing done on a different branch. This invalidates QA testing for the feature branch as well as integration testing for staging and develop.

Developers will experience the most pain from the first bullet point. From a quality perspective, the second bullet point is more worrisome. If you did QA testing in develop, but then merge the feature branch again into staging, you invalidate all of the QA testing you did on develop. Merging the same branch into two branches is really the cause of your version control problems, and is possibly the reason why features need to get pulled from a release.

There is nothing wrong with basing feature branches on a stable branch. It seems the staging branch serves that purpose on your team. To support frequent releases, your team needs:

1. A branch to integrate all work going into the next release.
2. A way to accurately pull a feature out of a release.
3. A way to track what has been deployed, and to which application environment.
4. Good automated test coverage. If the team primarily does manual testing, then the testing effort is simply too labor intensive to support frequent releases.
5. Coordination between developers and testers.
   • This implies defining a cutoff date and time for new features moving into QA testing.

Even when your process is Kanban, the team needs to plan work. You cannot expect a feature branch merged into develop a day before the release to be fully QA tested, bug squashed and acceptance tested. When I see teams constantly "pulling features out" of a release, it indicates problems with planning and coordinating work. Git cannot fix this.

Work with your team on some of the process problems. Fixing these problems will involve more than changing how you use version control. Even so, consider some of the suggestions below as a part of the solution:

1. Create one branch per release based on main.
2. Don't merge a feature branch into a release branch until the team can commit to getting it done.
   • Work with your team to define what is "ready for production" if this has not been identified.
3. Squash commits from a feature branch when merging into the release branch.
   • This makes easier to "pull a feature out of a release" because you only need to revert one commit, but you need to retest, so this isn't free. There is still a cost to doing this.
   • Note that "pulling a feature out of a release" invalidates all QA testing for that feature up to the present time.
4. Adding automated test coverage so regression testing requires less effort.
   • This makes it easier to pull a feature out of a release.
5. Once a release has been deployed, merge the release branch into main.
6. Base all feature branches off of main.

The best place to start is addressing process issues with the team. Tools can only fix so much.