Prevent unchecked changes from merging into main branch


We have a PL/SQL (Oracle DB procedural language, but it doesn’t really matter) git project. We have develop branch that holds all changes and appears to be PRO current state (though it should’ve been better to use master instead but it’s been for years). We usually create branches from develop, do some changes to this branch (assume, it’s feature/JIRA-1234). Then we have env-branches that represent state of QA, Integration, UAT testing envs (assume, it’s one of them and it’s env/qa). We merge ready-to-be-tested features into desired env branches. After testing we create release branch that collects all the features which are ready to be deployed in PRO. We check deployment on stage env, fix installation problems if any and then tag the latest commit of this branch with release tag and pass it to OPS team which takes care of deployment process.

A problem we’re facing now with such approach is that feature/JIRA-1234 branch remains "unprotected" after merging to env/qa, env/uat, etc up to the moment of merging to a release branch. So I can pass a branch to a QA team after having 6 commits there and push something new to this branch and then pass it to env/uat, for instance, and later even make changes before it will be merged into release branch. So after some time QA engineer can’t really say that he/she tested the latest version of the branch.

I thought of maybe somehow "locking" the feature branch from merging before some event happens (like "QA passed"). Or maybe change development process. Sometimes developers want to improve their code by adding a small little fix that really shouldn’t be tested but later it turns out to be a bug in PRO.

We are using gitlab as a tool for reviewing and managing merge requests. So possibly it has some tools for solving this puzzle but I haven’t managed to find it so far.

Any suggestions are appreciated! Or maybe you can share links with articles that cover such situations.


I’m aware of git flow approach. I don’t think that it works for us as we can’t merge features back to develop as a scope of the upcoming release is uncertain till some moment in time. So my tested feature couldn’t get into a release just because biz team doesn’t want to see it in PRO by now. That’s why we don’t have develop branch in terms of git flow approach.


Thanks to @JoelFan I finally got understanding of working with branches.

Also after some googling I found out that except git-flow process there exists github-flow and gitlab-flow.

The first one is quite simple and applicable for a small and quick-to-roll-out releases while the second one offers an approach for SAAS-like products which have env-dependent branches. I think it will be useful for our releasing model with some additional tweaks.

Answered By – Roman

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published