What is the difference between "renaming git branch to master" and "merging branch to master with -s ours option"?

Question

We have ported 9 yr old CVS repo to Git using cvs2git. Over the period of time we ended up leaving trunk (in the cvs world) behind and made one of the branches as production (prod_br). Not many people like this but past is past :)

Now that we have converted it to Git we have two options (based on previous responses on stackoverflow):

1. Move changes in the production branch (prod_br) to master and start fresh with the new master and continue. (git checkout prod_br, git merge -s ours master, git checkout master, git merge prod_br)

2. Rename prod_br as master and continue from here. (git branch -m prod_br master)

What is the difference between the above two approaches? Any pros / cons.

We have a third option in mind too: Keep the current master as it is and continue building on top of prod_br. This is kind of live on a repo with a master which would never be used in future. This is also as if prod_br is "our logical master". Is there any disadvantage of having a repo with a master which would never be used as a master?

Any help / guidance is appreciated.

Answer 1

What is the difference between the above two approaches?

The first approach would likely create a merge-commit which would be good from a history perspective, as it will be clear when the move to master occurred.

When you do the merge back to master, as a best-practice to ensure the merge-commit you may want to use the --no-ff (no fast-forward) option:

git merge --no-ff prod_br

As for the second option, renaming the branch would work but would not self-document like the merge-commit and more importantly would cause you to need to force-push the change which could disrupt other users. (they would need to do a rebase or other operation to get their version of the branch to be reachable again with the remote)

Is there any disadvantage of having a repo with a master which would never be used as a master?

Not really any true disadvantage but in Git the convention is to have your main, production branch be master. So if you use master your repository will seem more standard to others joining the project. Also, when they clone by default they will be put right on master (barring the --branch option) so it will be one less step to remember (switching to the ad-hoc production branch).

IMO an important operation like this calls for a self-documenting merge-commit so I think option 1 is the best approach.