如何归档 git 分支？

How can I archive git branches?

提问by dan-manges

I have some old branches in my git repository that are no longer under active development. I would like to archive the branches so that they don't show up by default when running git branch -l -r. I don't want to delete them, because I want to keep the history. How can I do this?

我的 git 存储库中有一些不再处于活跃开发状态的旧分支。我想存档分支，以便它们在运行时默认不显示git branch -l -r。我不想删除它们，因为我想保留历史记录。我怎样才能做到这一点？

I know that it's possible to create a ref outside of refs/heads. For example, refs/archive/old_branch. Are there any consequences of doing that?

我知道可以在 refs/heads 之外创建一个 ref。例如，refs/archive/old_branch。这样做有什么后果吗？

回答by Jeremy Wall

I believe the proper way to do this is to tag the branch. If you delete the branch after you have tagged it then you've effectively kept the branch around but it won't clutter your branch list.

我相信正确的方法是标记分支。如果您在标记分支后删除它，那么您已经有效地保留了该分支，但它不会使您的分支列表变得混乱。

If you need to go back to the branch just check out the tag. It will effectively restore the branch from the tag.

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

To archive and delete the branch:

要存档和删除分支：

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

To restore the branch some time later:

稍后恢复分支：

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

The history of the branch will be preserved exactly as it was when you tagged it.

分支的历史记录将完全保留为您标记它时的状态。

回答by Steve

Jeremy's answer is correct in principle, but IMHO the commands he specifies are not quite right.

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

Here's how to archive a branch to a tag without having to checkout the branch (and, therefore, without having to checkout to another branch before you can delete that branch):

以下是如何将分支存档到标记而无需签出该分支（因此，在删除该分支之前不必签出到另一个分支）：

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

And here's how to restore a branch:

以下是恢复分支的方法：

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

回答by snipsnipsnip

Yes, you can create a ref with some non-standard prefix using git update-ref. e.g.

是的，您可以使用git update-ref. 例如

• Archive the branch: git update-ref refs/archive/old-topic topic && git branch -D topic
• Restore the branch (if needed): git branch topic refs/archive/old-topic

• 归档分支： git update-ref refs/archive/old-topic topic && git branch -D topic
• 恢复分支（如果需要）： git branch topic refs/archive/old-topic

Refs with non-standard prefix (here refs/archive) won't show up on usual git branch, git lognor git tag. Still, you can list them with git for-each-ref.

带有非标准前缀的引用（此处refs/archive）不会出现在通常的git branch，git log也不会出现在git tag. 不过，您可以使用git for-each-ref.

I'm using following aliases:

我正在使用以下别名：

[alias]
    add-archive = "!git update-ref refs/archive/$(date '+%Y%m%d-%s')"
    list-archive = for-each-ref --sort=-authordate --format='%(refname) %(objectname:short) %(contents:subject)' refs/archive/
    rem = !git add-archive
    lsrem = !git list-archive

Also, you may want to configure remoteslike push = +refs/archive/*:refs/archive/*to push archived branches automatically (or git push origin refs/archive/*:refs/archive/*for one-shot).

此外，您可能希望配置遥控器，例如push = +refs/archive/*:refs/archive/*自动推送存档分支（或git push origin refs/archive/*:refs/archive/*一次性推送）。

Another way is to writing down SHA1 somewhere before deleting branch, but it has limitations. Commits without any ref will be GC'd after 3 months (or a couple of weeks without reflog), let alone manual git gc --prune. Commits pointed by refs are safe from GC.

另一种方法是在删除分支之前在某处写下 SHA1，但它有局限性。没有任何 ref 的提交将在 3 个月（或没有 reflog 的几周）后被 GC 处理，更不用说手动了git gc --prune。由 refs 指向的提交在 GC 中是安全的。

Edit:Found a perl implementation of the same idea by @ap: git-attic

编辑：通过@ap找到了相同想法的 perl 实现：git-attic

Edit^2:Found a blog postwhere Gitster himself using the same technique.

编辑^2：找到了一篇博客文章，其中 Gitster 自己使用了相同的技术。

回答by Liam

Extending Steve's answerto reflect the changes on the remote, I did

扩展史蒂夫的回答以反映遥控器上的变化，我做到了

 git tag archive/<branchname> <branchname>
 git branch -D <branchname>
 git branch -d -r origin/<branchname>
 git push --tags
 git push origin :<branchname>

To restore from the remote, see this question.

要从远程恢复，请参阅此问题。

回答by August Lilleaas

You could archive the branches in another repository. Not quite as elegant, but I'd say it's a viable alternative.

您可以将分支存档在另一个存储库中。不太优雅，但我会说这是一个可行的选择。

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

回答by Alexey

Here is an alias for that:

这是一个别名：

arc    = "! f() { git tag archive/  && git branch -D ;}; f"

Add it like this:

像这样添加它：

git config --global alias.arc '! f() { git tag archive/  && git branch -D ;}; f'

Bear in mind there is git archivecommand already so you cannot use archiveas an alias name.

请记住，已有git archive命令，因此您不能将其archive用作别名。

Also you can define alias to view the list of the 'archived' branches:

您也可以定义别名以查看“归档”分支列表：

arcl   = "! f() { git tag | grep '^archive/';}; f"

about adding aliases

关于添加别名

回答by Pitr

I am using following aliases to hide archived branches:

我使用以下别名来隐藏归档分支：

[alias]
    br = branch --no-merge master # show only branches not merged into master
    bra = branch                  # show all branches

So git brto show actively developed branches and git brato show all branches including "archived"ones.

因此，git br要显示积极开发的分支并git bra显示所有分支，包括“存档”分支。

回答by Schwern

I would not archive branches. Put another way, branches archive themselves. What you want is to ensure the information relevant to archeologists can be found by reliable means. Reliable in that they aid daily development and doesn't add an extra step to the process of getting work done. That is, I don't believe people will remember to add a tag once they're done with a branch.

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

Here's two simple steps that will greatly help archeology anddevelopment.

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

1. Link each task branch with an associated issue in the issue tracker using a simple naming convention.
2. Always use git merge --no-ffto merge task branches; you want that merge commit and history bubble, even for just one commit.

1. 使用简单的命名约定将每个任务分支与问题跟踪器中的相关问题联系起来。
2. 总是git merge --no-ff用来合并任务分支；你想要合并提交和历史泡沫，即使只有一次提交。

That's it. Why? Because as a code archeologist, rarely do I start with wanting to know what work was done on a branch. Far more often it's why in all the screaming nine hells is the code written this way?!I need to change code, but it has some odd features, and I need to puzzle them out to avoid breaking something important.

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

The next step is git blameto find the associated commits and then hope the log message is explanatory. If I need to dig deeper, I'll find out if the work was done in a branch and read the branch as a whole (along with its commentary in the issue tracker).

下一步是git blame找到相关的提交，然后希望日志消息是解释性的。如果我需要更深入地挖掘，我会找出工作是否在一个分支中完成并阅读整个分支（以及它在问题跟踪器中的评论）。

Let's say git blamepoints at commit XYZ. I open up a Git history browser (gitk, GitX, git log --decorate --graph, etc...), find commit XYZ and see...

假设git blame提交 XYZ的点数。我打开一个 Git 历史浏览器（gitk、GitX git log --decorate --graph、等等...），找到 commit XYZ 并查看...

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

There's my branch! I know QQ, UU, XYZ, JJ and MM are all part of the same branch and I should look at their log messages for details. I know GG will be a merge commit and have the name of the branch which hopefully is associated with an issue in the tracker.

有我的分店！我知道 QQ、UU、XYZ、JJ 和 MM 都属于同一个分支，我应该查看他们的日志消息以获取详细信息。我知道 GG 将是一个合并提交，并且具有希望与跟踪器中的问题相关联的分支的名称。

If, for some reason, I want to find an old branch I can run git logand search for the branch name in the merge commit. It is fast enough even on very large repositories.

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

That is what I mean when I say that branches archives themselves.

这就是我所说的分支归档本身的意思。

Tagging every branch adds unnecessary work to getting things done (a critical process which should be ruthlessly streamlined), gums up the tag list (not speaking of performance, but human readability) with hundreds of tags that are only very occasionally useful, and isn't even very useful for archeology.

标记每个分支为完成工作增加了不必要的工作（一个应该无情地简化的关键过程），用数百个标签填充标签列表（不是说性能，而是人类可读性），这些标签只是偶尔有用，而且不是甚至对考古学非常有用。

回答by Sridhar Sarnobat

My approach is to rename all branches I don't care about with a "trash_" prefix, then use:

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

git branch | grep -v trash

(with a shell key binding)

（使用shell键绑定）

To retain the coloring of the active branch, one would need:

要保留活动分支的颜色，需要：

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

回答by Banezaka

You can use a script that will archive the branch for you

您可以使用一个脚本来为您归档分支

archbranch

总支

It creates a tag for you with the prefix archive/ and then deletes the branch. But check the code before you use it.

它为您创建一个带有前缀 archive/ 的标签，然后删除该分支。但是在使用之前请检查代码。

---

---

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

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

If you want to run the script without writing the location to it add it to your path

如果您想在不写入位置的情况下运行脚本，请将其添加到您的路径中

Then you can call it by

然后你可以调用它

$ archbranch [branchname] [defaultbranch]

The [defaultbranch]is the branch that it will go to when the archiving is done. There are some issues with the color coding but other then that it should work. I've been using it in projects for a long time, but it is still under development.

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