我正在尝试发布我的 NPM 包的更新版本。以前的版本和现在的版本没有太多相似之处。我们想要覆盖分支但又不想丢失它的历史。我们如何才能做到这一点？
【问题讨论】：
我认为你可以创建一个新分支作为你最后一个分支或哈希的一部分（当然，你最后一个分支）。
git checkout old-branch
git checkout -b new-branch
【讨论】：
checkout -b而不是branch -b？
历史，在任何 Git 存储库中，只是 存储库中的一组提交。每个提交都有编号，带有一个大而难看的哈希 ID。运行git log，为它提供一个原始的提交哈希ID，Git 会告诉你：
等等。提交的“家谱”是历史。
分支名称，在 Git 中，只是一种记录特定提交哈希 ID 的方法，这样您就不必记住大而丑陋的随机外观该特定提交的哈希 ID。标记名称具有相同的目的：它们存储一个特定提交的哈希 ID。 branch 名称和 tag 名称之间的主要区别在于，branch 名称 旨在移动，并且事实上，会自动移动，通过您检查分支，然后进行 新的提交。
当您在分支 B 上并进行 new 提交时，新提交的 parent 提交会自动成为任何提交 B 用来命名的。新的提交就是分支 B 命名的提交。
这意味着如果您想要从 B 开始的“历史”，并通过家谱向后工作，以包括之前在 B 上的提交，您必须在 B 上的当前最后一次提交之后进行 new 提交。
同时，请注意，每个提交——每个看起来很丑的随机散列 ID——不仅代表从该点开始的历史记录，而且还向后工作。它还存储每个文件的完整快照。当您使用git log -p 查看更改 时，您看到的是 Git 比较 相邻快照的结果：此提交的父级和此提交之间的快照以这种方式改变。
您是否希望一个特定的 new 提交将与其他一些现有提交具有的相同快照存储为它的完整快照，但作为其父提交，与某个特定 相同的提交分店名 已经存储了，这很容易实现。有多种方法可以做到这一点。然而，想要是一件非常不寻常的事情。
如果您希望保留从名为 B 的某个分支开始的所有提交并向后工作，但为这些提交使用其他一些 name，您可以简单地更改名称。分支名称并非一成不变：任何分支都可以随时重命名。
这里需要注意的一点是，每个 Git 存储库都有自己的分支名称。这些名称根本不共享。当您克隆一个存储库时，您将获得所有其他存储库的提交，并且没有它的分支。然后，您的 Git 在您的克隆中创建一个 new 分支名称，以便您拥有一个实际的分支名称。您的 Git 使用您的 远程跟踪名称，例如 origin/master 或origin/main、origin/develop 等等。这些名称的存在是因为 您的 Git 创建 它们是通过重命名 其他 Git 的 分支 名称。每次您的 Git 与原始 (origin) Git 联系以获取更新时，您的 Git 将创建或更新您自己的远程跟踪名称，以对应于他们对其 分支 名称所做的任何更新。
所有这一切的意思是，如果您更改某个存储库中的分支名称，则该存储库的克隆中的远程跟踪名称将会更改——但是该存储库的克隆中的 branch 名称不会。每个用户都需要进行自己的分支名称重命名，如果他们正在使用该分支名称。
因此，重命名分支是一件好事，但您必须告诉您的所有用户/同事此更改，以便他们可以进行如果他们愿意，对他们的 Git 进行同样的更改。 （他们必须这样做——例如，他们没有理由不能使用名称zorg 而不是develop——但大多数人确实喜欢拥有自己的分支名称匹配一些其他 Git 的分支名称，以便它们的 zorg 匹配它们的 origin/zorg，而不是它们的 origin/develop。）
另请参阅Making two branches identical、How to make branch B exactly like branch A?、git command for making one branch like another、How do I 'overwrite', rather than 'merge', a branch on another branch in Git? 以及此类一般问题的许多其他实例。
【讨论】：
除了torek's great answer，我想提一下，这个问题似乎表明对 Git 所做的事情存在根本性的误解。版本一旦发布就应该有标签，而不是分支。版本分支有助于准备发布，但应合并到主干分支并标记。
此外，新版本的标签应包含所有先前版本的历史记录。如果正确使用 Git，这会自动发生。但是，旧版本的标签应该对新版本的历史一无所知。这就是“历史”的意义所在。它只让您了解过去，而不是未来。
【讨论】：