问题描述
我有一个典型的情况，我们都在 master 分支上工作，而当我们不得不执行并行流水线过程时，我们从这个 master 上切断了分支并创建了一个新的分支 say 功能，现在这个功能分支开始有来自全体人员的提交，并且没有提交落在 master 中。
现在在将近 7 个月后，我们在功能分支上工作，现在我们希望将其合并到 master 而不丢失 master 分支的历史记录。我们在功能分支中有将近 2000 次提交，所以 rebase 只是一个危险的操作。
我们正在考虑的方法：
- 将分支功能重命名为 master 并将 master 重命名为 xxxxx（但我不知道如何保留 master 分支的历史记录）
- 通过首先对 master 分支进行 MR 并删除 master 中的所有内容，然后强制合并功能到 master 来执行硬合并。
- 只需进行 rebase（可能不那么痛苦，但在发生冲突时可能是灾难性的）。
感谢准确执行此操作的步骤。我们使用 Gitlab。
解决方法
没有分支的历史。1在分支中有历史，因为分支名称标识了一个特定的提交，并且该提交标识了一个或多个先前的提交，每个提交也标识了更早的提交等等。然后我们说这些提交在（包含在）那个分支中。它们也可能包含在其他分支中。
Git 存储库中的历史是提交。提交是历史。如果你有提交，你就有历史。它们是同一回事，因此无需担心将它们分开。这里的棘手部分是 提交 是通过它们的哈希 ID 找到的。哈希 ID 又大又丑，人类不可能在任何类型的长期基础上正确处理。所以我们甚至不尝试：我们使用分支名称来查找最新提交，从中我们可以找到所有较早的提交。
这对您来说意味着最简单的方法，即在重命名可能位于方法第一，大概是要走的路。如果稍后您希望找到只能通过从以前称为 feature 的任何内容向后搜索才能找到的提交，那么现在称为 master,2 你会运行 main 或 master 来找到它。
一个分支名称——或者像 history-from-1927 这样的远程跟踪名称，它是 Git 在克隆中创建的，以便克隆3 的用户可以看到原始存储库可以看到的内容——允许作为克隆的用户，您可以查找和查看提交，而无需记住它们的哈希 ID。 （它还保护那些提交不被垃圾收集，这是一个单独的问题。）
1这并不完全正确，因为 Git 为分支名称和其他引用保留了所谓的 reflogs。然而，这不是你的意思。 Reflogs 也特定于一个特定的存储库：此历史记录不会通过克隆传输。
2显然 1927 年是不现实的；甚至 1972 年也会在 Git 出现之前。它只是意味着你用过的任何名字，而不是暗示你使用这个名字，这是一个可怕的名字。使用更好的。
3制作者获得他或她自己的分支名称在那个克隆中，以他/她/他们看到的方式使用合身。这就是为什么他们的 Git 重命名 origin-al (git log history-from-1927) 分支名称：如果他们想创建自己的 git log origin/history-from-1927 和/或 origin/whatever 和/或其他任何其他名称，它们不会受到 origin 存储库中名称的影响。相反，它们的 main 名称将受到这些名称的影响。这就是我们有远程跟踪名称的原因：它们跟踪远程 Git 中的分支名称。我们运行 feature 以获取他们拥有的任何新提交，而我们还没有；这会更新我们的远程跟踪名称以记住这些新提交，就像他们更新他们 分支名称以记住这些新提交一样。