My question is a theoretical/procedural one. I am trying to figure out/build a custom Git Workflow (not to be confused with Git Flow) that works well for our organization.
We’re using GitLab and have the following 3 long-living branches:
development(latest stable codebase)
staging(auto deploys to staging server)
master(auto deploys to production server)
master branches are protected, meaning that the developers can only merge to them, but can’t push. Also, during the merging, rebase (only FF) and squash-merge are enforced for a cleaner Git log.
For every feature/bugfix, a new feature-branch gets created, based on
development and merged back to the respective branches when ready.
But here is the problem, we want to have good control of what gets merged into the 3 long-living branches. For example, just because some functionality is developed and merged with
development, doesn’t mean we want it in
master, which turns out to be hard to achieve, at least from my perspective.
Here is an example scenario:
- A developer creates a
feature/storebranch, based on
development, and completes it over time
- They rebase it to
developmentand merge it to
- After that a new feature development starts named
feature/add-footer-menu. This branch is based on
developmenttoo and once completed, they merge it to
master, because it needs to go live immediately
The tricky part is that this way the changes from
feature/store go live too, and we don’t want that. The only workaround to this is to work exclusively with cherry-picks and cherry-pick only the commits we want to merge with
master. This probably will work, but is an overkill in my opinion. Is there an easier flow to achieve this?
The main goal is to have good control over what goes live. Usually
staging will have the same commits, but only specific features need to go to
Also, one more thing. If we do the above, this means that if we want to have a feature branch merged into the 3 long living branches, this means we need to have the respective feature branches, so we could rebase and merge them. 3 long-living branches = 3 short-lived feature branches, just for the merging. Without being a Git expert, this just doesn’t look right.
Please share your thoughts and suggestions. Thank you!