Hi everyone,
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)
The development, staging and 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 ondevelopment, and completes it over time - They rebase it to
developmentand merge it todevelopmentandstaging - After that a new feature development starts named
feature/add-footer-menu. This branch is based ondevelopmenttoo and once completed, they merge it todevelopment,stagingandmaster, 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 staging and 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 development and staging will have the same commits, but only specific features need to go to master.
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!