git workflow: merging and fixing conflicts once

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

Answer 1

Look at branch per feature. You should get my post about this very subject. I also answered a question here about Sharing rerere cache

Answer 2

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.