杰里米的回答原则上是正确的，但恕我直言，他指定的命令不太正确。

下面是如何在不签出分支的情况下将一个分支归档到一个标签中(因此，在删除该分支之前，不必签出到另一个分支):

> git tag archive/<branchname> <branchname>
> git branch -D <branchname>

下面是如何恢复一个分支:

> git checkout -b <branchname> archive/<branchname>

我不会归档分支。换句话说，分支将自己存档。你想要的是确保考古学家的相关信息可以通过可靠的方法找到。可靠之处在于它们有助于日常开发，并且不会在完成工作的过程中增加额外的步骤。也就是说，我不相信人们在使用完分支之后还会记得添加标签。

这里有两个简单的步骤，将极大地帮助考古和发展。

使用简单的命名约定将每个任务分支与问题跟踪器中的关联问题链接起来。 总是使用git merge——no-ff来合并任务分支;你需要合并提交和历史记录气泡，即使只是一次提交。

就是这样。为什么?因为作为代码考古学家，我很少一开始就想知道在一个分支上做了什么工作。更常见的是，为什么在所有尖叫的九个地狱代码是这样写的?!我需要更改代码，但它有一些奇怪的功能，我需要把它们弄清楚，以避免破坏一些重要的东西。

下一步是git责备找到相关的提交，然后希望日志消息是解释性的。如果我需要深入挖掘，我将找出工作是否在一个分支中完成，并从整体上阅读该分支(以及问题跟踪器中的注释)。

我们说git责备点在提交XYZ。我打开一个Git历史浏览器(gitk, GitX, Git log -装饰-图形，等等…)，找到提交XYZ，然后看到…

AA - BB - CC - DD - EE - FF - GG - II ...
     \                       /
      QQ - UU - XYZ - JJ - MM

这是我的树枝!我知道QQ, UU, XYZ, JJ和MM都是同一个分支的一部分，我应该查看他们的日志消息以了解详细信息。我知道GG将是一个合并提交，并有分支的名称，希望与跟踪器中的问题相关联。

如果，出于某种原因，我想找到一个旧的分支，我可以运行git log并在合并提交中搜索分支名称。即使在非常大的存储库上，它也足够快。

这就是我所说的分支自己归档的意思。

给每个分支加标签会给完成工作增加不必要的工作(这是一个应该被无情地简化的关键过程)，用数百个偶尔有用的标签混淆标签列表(不是说性能，而是人类的可读性)，甚至对考古学都没有多大用处。

步骤0。检查以确保工作树是干净的，以免 失去工作:

git status

步骤1。从本地存储库的根签出分支和 然后将其标记为存档:

git checkout <branch_name> && git tag archive/<branch_name>

步骤2。上传标签到远程，并确保在另一个分支之前 继续，例如main:

git push origin --tags && git checkout main

步骤3。从本地和远程存储库中删除分支:

git branch -D <branch_name> && git push origin -d <branch_name>

在哪里您应该替换<branch_name>与分支的名称 要存档，并将原点与远程存储库的名称联系起来 如果不是原点。

评论:

在第1步之前和之后，你可能想要运行git标记来注意 添加标签。 在第三步之前和之后，你可能想要观看 https://github.com/ < github-username > / < github-repository-name > /分支 和/或运行git branch -a来注意这个分支是如何被删除的。 恢复一个分支:

git checkout -b <branch_name> archive/<branch_name>

紧随其后的是

git push --set-upstream origin <branch_name>

引用: https://gist.github.com/zkiraly/c378a1a43d8be9c9a8f9 https://dev.to/clsource/archiving-git-branches-3k70

杰里米的回答原则上是正确的，但恕我直言，他指定的命令不太正确。

下面是如何在不签出分支的情况下将一个分支归档到一个标签中(因此，在删除该分支之前，不必签出到另一个分支):

> git tag archive/<branchname> <branchname>
> git branch -D <branchname>

下面是如何恢复一个分支:

> git checkout -b <branchname> archive/<branchname>

我有时会这样归档分支:

生成补丁文件，例如format-patch <branchName> < firstthash >^..<lastHash>(使用git日志获取firstthash和lastHash) 将生成的补丁文件移动到文件服务器的目录下。 删除分支，例如git分支-D <branchName>

当你需要再次使用分支时，“应用”补丁;然而，根据目标分支的状态，应用补丁文件(参见git am)可能具有挑战性。从好的方面来看，这种方法的好处是允许分支的提交被垃圾收集，并节省了repo中的空间。

您可以将分支归档到另一个存储库中。虽然没那么优雅，但我觉得这是个可行的选择。

git push git://yourthing.com/myproject-archive-branches.git yourbranch
git branch -d yourbranch