我认为正确的方法是标记分支。如果你在标记了分支之后删除了它，那么你就有效地保留了这个分支，但它不会使你的分支列表变得混乱。

如果您需要返回分支，只需检查标签。它将有效地从标记中恢复分支。

归档并删除分支:

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并在合并提交中搜索分支名称。即使在非常大的存储库上，它也足够快。

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

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

您可以使用为您存档分支的脚本

archbranch

它为您创建一个带有前缀archive/的标记，然后删除分支。在使用它之前，请确保您了解它的功能=)

使用- $/your/location/of/script/archbranch [branchname] [defaultbranch]

如果希望运行脚本而不向其写入位置，则将其添加到路径中

那你可以顺便来看看

$ archbranch [branchname] [defaultbranch]

[defaultbranch]是归档完成后它将转到的分支。有一些问题与颜色编码，但除此之外，它的工作。我已经在项目中使用它很长时间了。

我有时会这样归档分支:

生成补丁文件，例如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

我的方法是用“trash_”前缀重命名所有我不关心的分支，然后使用:

git branch | grep -v trash

(带壳键绑定)

为了保持活跃分支的颜色，我们需要:

git branch --color=always | grep --color=never --invert-match trash