git - "renaming git branch to master"和 "merging branch to master with -s ours option"有什么区别？

Question

我们已经使用 cvs2git 将 9 年前的 CVS 存储库移植到 Git。在一段时间内，我们最终将主干(在 cvs 世界中)抛在脑后，并将其中一个分支作为生产(prod_br)。像这样的人不多，但过去已经过去了:)

现在我们已经将它转换为 Git，我们有两个选择(基于之前对 stackoverflow 的回复):

1. 将生产分支 (prod_br) 中的更改移至 master 并从新的 master 重新开始并继续。 (git checkout prod_br, git merge -s ours master, git checkout master, git merge prod_br)

2. 将 prod_br 重命名为 master 并从此处继续。 (git branch -m prod_br master)

以上两种方法有什么区别？任何优点/缺点。

我们还有第三种选择:保持当前 master 不变，并继续在 prod_br 之上构建。这是一种与主人一起生活在 repo 协议(protocol)中，将来永远不会使用。这也好像 prod_br 是“我们的逻辑主人”。拥有一个永远不会被用作主人的主人的 repo 有什么缺点吗？

感谢任何帮助/指导。

Answer 1

What is the difference between the above two approaches?

第一种方法可能会创建一个 merge 提交，从历史的角度来看这会很好，因为当移动到 master 时会很清楚。

当您执行 merge 时回到 master，作为确保 merge 提交的最佳实践，您可能需要使用 --no-ff(无快进)选项:

git merge --no-ff prod_br

至于第二种选择，重命名分支会起作用，但不会像 merge 提交那样 self 记录，更重要的是会导致您需要强制推送更改，这可能会扰乱其他用户。(他们需要做一个 rebase 或其他操作来让他们的分支版本可以再次通过远程访问)

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

确实没有任何真正的缺点，但在 Git 中，约定是让您的主要生产分支成为 master。因此，如果您使用 master，您的存储库对于加入该项目的其他人来说似乎更标准。此外，当它们默认克隆时，它们将直接放在 master 上(除非 --branch 选项)因此记住这将少一步(切换到临时生产分支)。

IMO 像这样的重要操作需要 self 记录的 merge 提交，所以我认为选项 1 是最好的方法。