I'm working on a Kafka platform development project, the team is keeping all the code in master with no branches, next moving to QA, Stg, Prod. If in between these stages if they don't need any changes to move to next stage, they then revert all the unwanted changes and deploy the code and then put the unwanted changes back again in master. It's hard to go over every commit and check manually to revert the changes.

Is there any other way to avoid these reverts by creating any branches or any other strategies (CI/CD new structure plan)?

1 Answer 1


There are a few ways of avoiding those reverts.

If it is relatively rare that changes need to be made when moving between QA, Stg and Prod, then the easiest change to introduce in your workflow is to use tags. Tags are essentially named labels that you hang on a particular commit.
When moving the HEAD of master to QA, you add a tag to it. That same tag can then be used to deploy the exact same revision to Stg or Prod without it being affected by changes that are later applied to master.

If changes do have to be made after QA or Stg, then you should introduce a branching model that uses multiple branches. If you have a lengthy process between start of QA and the software entering Prod, I would recommend a branching strategy based on gitflow, where Prod tracks the latest status of master, the current development happens on develop, and the code that is at QA or Stg is on a release/X branch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.