Gitlab flow Long lived environment branches in Mono Repo keeps growing commit log on Pull Request in Azure repos

Question

We have moved from IBM RTC to Git recently and facing a problem with branching strategy. We use to have three streams in RTC Jazz, Development flows to Staging & Staging flows in Production. While moving to Git(Azure Repos) we placed RTC component(multiple Web Service projects) in one big mono repo & opted for GitLab Flow branching strategy due to it's emphasis on long lived environment branches(three branches, one for each environment). As we have three environments & we want to keep track of what code is deployed to which environment and there can be different versions of same web service on three environments.

The workflow we decided was for developer to branch out feature branch from production branch and start working and then sequentially merge his/her feature branch to development , staging and finally production.

This was working good initially but later when we raise PR to merge feature branch into one of development and staging branch then unwanted commits become part of PR as the feature branch also contains commits which we merged into production after the branch out of development and staging branch. PR Commits, Green wanted, Red unwanted

I don't know that we're not following the GitLab flow correctly or there is some problem in our workflow?

Constraints:

1. We can not fallow linear flow by merging development to staging & staging to production as we have mono repo and we don't wanna move everything at once.
2. We want to retain the code of each environment on each branch.

Answer 1

If you want to push changes to a target branch via PR, it is generally recommended to create the source branch based on the target branch. Then make changes on the source branch and raise PR to merge the changes to the target branch. During the process, avoid as possible pushing some other changes to the target branch from other processes. This could ensure the source branch is up to date with the latest target branch and avoid conflicts and unexpected changes.

---

For your case, since you create the feature branch based on the production branch, you can try to use cherry-pick to copy the wanted changes from feature to development or staging branch.

1. Raise a temporary PR from feature to production.

   • By this way, the PR should only contain changes made on feature branch that should be the wanted changes.
   • Do not complete merge on this PR.
   • You can ignore any conflict reported on this PR.

2. Ensure there is no conflict between feature and the target branch (development or staging branch for your case) that you want to merge the wanted changes to. If conflict exists, resolve it at first.

3. On the menu of the temporary PR, select 'Cherry-pick' option. On the pop-up window, select the target branch (e.g, development) that you want to merge the wanted changes to. Then click 'Cherry-pick' button.

   

4. After clicking 'Cherry-pick' button, the system will do the following things.

   • Automatically create a branch named 'feature-on-development' if you selected to cherry-pick changes from feature to development.
   • Automatically promote a PR creation page to let you raise a PR from feature-on-development to development.
   • From this new PR, you can see it only contains the changes same as that on the previous temporary PR. All the contained changes should be what you want.

5. Complete the PR created by step #4. Then you can delete any temporary branches and close/abandon any temporary PR.

---

Answer 2

The workflow we decided was for developer to branch out feature branch from production branch and start working and then sequentially merge his/her feature branch to development , staging and finally production.

It sounds like you want to merge your feature branches into development, staging, and production individually without (necessarily) merging the rest of development into staging or staging into production.

That's a pretty heavy touch approach, to merge every feature branch into a variety of different targets. But also it's error prone, as the components in development may or may not be available in staging or production. Finally, should any in flight features conflict, those conflicts will have to be resolved in each branch.

Edit: As others pointed out in the comments, this isn't as simple as a merge. Sounds more like a cherry-pick, and that will be by commit. Now you're doing the job of Git manually.

Those are some of the reasons nobody does it that way.

GitLab Flow appears to be a trunk based, linear model that implements continuous integration. This means all users integrate changes into a shared branch and the shared branch is itself promoted.

we placed RTC component(multiple Web Service projects) in one big mono repo ...

... We can not fallow linear flow by merging development to staging & staging to production as we have mono repo and we don't wanna move everything at once.

In my mind this is the root of your issue. You put everything in one repo, but you don't want it to be versioned together. Split your projects into separate repos. It may seem like more work, but it will be a lot more straightforward than trying to merge feature branches into different branches with diverging histories.