I've 3 branches: Dev (on which developers push their code), Qa (on which tests are done) and Master (production code).

When releasing, we merge (default merge) Qa into Master and Dev into Qa. I've also found people using rebase instead of merge.

But, what about using merge -s ours ?

This will ensure that the code of Master is exactly the one of Qa we just tested. We get rid of side effects of the default merge (like kept code of Master against Qa which shouldn't). Moreover, the automation tool can do the whole release for us because we don't get any merge conflict during the process.

Is it a good idea ? And what's the best practice ?

CodePudding user response：

Is it a good idea?

Hm, I doubt it. git merge -s ours pretends to do a merge where in fact it rather does a reset. You effectively ignore all commits that were made to master. And that is the point I would rather investigate:

How can it be that there needs to be a (non-fast-forwarding) merge on master? If the only way master ever advances is by merging from QA or making a commit that is immediatly merged back into QA then there can not be any conflicts (unless the history of QA was rewritten). If on the other hand there are some commits to master that were not merged back to QA it is probably not a good idea to just discard them, which you would do using git merge -s ours.

Edit: Mention the possibility of hotfixes to master