git workflow: merging and fixing conflicts once
-
13-12-2019 - |
Question
We have a simple workflow with three main branches
staging
i.e the test environment
master
i.e the production environment
dev/XXX
where XXX is the ticket number
- Clients log tickets
- we create a branch e.g
dev/2332
- we work + commit + push
- we merge the work when ready into
staging
- client approves the work on
staging
- we merge the work into
master
and ticket is deployed on production
The problem:
If multiple developers are working on their respective dev/XXX
branches;
when they merge into staging
, sometimes, they create conflicts. They fix those conflicts on staging and push.
The problem is when the client approves those specific tickets and we merge the work into master
, we have to fix the conflicts again
Important:
- we cannot merge staging into master -- because of unapproved tickets
- all branches by default are created from the latest master
- multiple tickets are being developed simultaneously but are deployed when approved
- rebasing from master to avoid conflicts is only an option if the work has been approved + deployed already
- rebasing from staging is not an option -- because of unapproved tickets
Any ideas on how to fix this issue? Is our workflow flawed? Are we missing some git hack?
Basically, I do not want the team to repeat the same thing twice
Thank you
Solution
Look at branch per feature. You should get my post about this very subject. I also answered a question here about Sharing rerere cache
OTHER TIPS
You need to keep master
and staging
as close to each other as possible. You could try handling it the way git itself the pu
branch. That is when a new task is completed, the branch is deleted, recreated from master
and all features pending approval merged in. The advantage of that is that the branches don't diverge and that there are no issues for unmerging rejected features. Disadvantage is that you can't base any work on it, but you don't anyway.
When conflict arises, you either tweak the dev branches to merge cleanly and run the "octopus" merge (merge with more than 2 parents) creating staging
again, or you wait for any dependencies or conflicting features to be approved before trying to stage the dependent one.
In any case, the feature branches should be rebased on (or merged with) latest master
just before trying to stage them. They were made from master when created, so rebasing them on later master is like they were started later and developed faster which obviously wouldn't be wrong.