当前位置：文江博客话题详情

何时删除 Git 中的分支？

发布于 2024-10-23 21:15:25 字数 370 浏览 8 评论 0原文

假设我们有一个稳定的应用程序。

明天，有人报告了一个大错误，我们决定立即修复。因此，我们为“master”的修补程序创建了一个分支，将其命名为“2011_Hotfix”，并将其向上推送，以便所有开发人员都可以协作修复它。

我们修复了该错误，并将“2011_Hotfix”合并到“master”以及当前的开发分支中。并按“主人”。

现在我们如何处理“2011_Hotfix”？它应该作为一个分支永远坐在那里直到时间结束，还是我们现在应该删除它，因为它已经达到了它的目的？将分支随处可见似乎是不干净的，因为分支列表可能会变得很长，其中大多数甚至不再需要。

如果它应该被删除，它的历史会发生什么？即使实际的分支不再可用，这种情况是否会得到维护？另外，如何删除远程分支？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

如歌彻婉言 2024-10-30 21:15:25

您可以使用 gitbranch -d yourbranch 安全地删除分支。如果它包含未合并的更改（即，您将通过删除分支而丢失提交），git 会告诉您并且不会删除它。

因此，删除合并分支的成本很低，并且不会丢失任何历史记录。

要删除远程分支，请使用 git push origin :mybranch ，假设您的远程名称是 origin 并且您要删除的远程分支名为 mybranch。

回复收藏 0 原文

无畏 2024-10-30 21:15:25

您需要做的是标记您发布的任何内容。当你积极开发时，保留分支。

删除旧分支，

git branch -d branch_name

使用“从服务器删除它们”

git push origin --delete branch_name

或旧语法

git push origin :branch_name

，其读作“在原点将任何内容推送到branch_name”。

也就是说，只要 DAG（有向无环图）可以指向它，提交就会记录在历史中。

谷歌“git-flow”，这可能会让您对发布管理、分支和标记有更多的了解。

What you need to do is tag anything that you release. Keep branches around for when you are actively developing.

Delete old branches with

git branch -d branch_name

Delete them from the server with

git push origin --delete branch_name

or the old syntax

git push origin :branch_name

which reads as "push nothing into branch_name at origin".

That said, as long as the DAG (directed acyclic graph) can point to it, the commits will be there in history.

Google "git-flow" and that may give some more insight on release management, branching and tagging.

回复收藏 0 原文

记忆消瘦 2024-10-30 21:15:25

由于问题有“github”标签，我还要添加以下内容：特别是在 Github 中，如果您 pull-request 一个分支并且它会被合并（通过 UI 或通过合并拉取请求的分支），您不会丢失拉取请求数据（包括注释），即使您删除了分支。

这样做的结果是：如果您将拉取请求作为工作流程的一部分（与代码审查完美地融合在一起），那么您可以在分支合并后立即安全地删除它们。这太常见了，以至于最近 Github 添加了一个（甜蜜的）功能，可以在合并拉取请求后立即弹出一个“删除分支”按钮。

但值得注意的是，每个小组都应该采用最适合自己的工作流程（并且可能会也可能不会导致删除此类分支）。例如，我当前的工作团队一旦拉取请求合并，就会修剪所有与主或部署无关的分支（例如，生产、暂存等），并且我们仍然可以完整跟踪相关提交的形成方式每个产品的每一次增量改进。

当然，没有历史管理（拉取请求或其他）可以取代版本的正确标记（您最好使用部署/打包版本的相同工具/脚本来自动化），因此您始终可以快速切换到用户碰巧使用的任何内容在某一特定时刻。标记也是解决原始问题的关键：如果您确定合并到“工作”分支的任何分支都可以而且应该被删除，并且任何合并到版本标记、“生产”等的分支都不应该删除，您将始终拥有修补程序，直到它们集成到未来版本中。

回复收藏 0 原文

十六岁半 2024-10-30 21:15:25

我想补充一点，删除分支的缺点是你将破坏 GitHub 上这些分支的任何超链接（这个问题被标记为 github）。对于这些链接，您将收到 404 Not Found 错误。这就是为什么我在删除 GitHub 上的分支后将链接更改为指向提交或标签的原因。

由于某些链接无法更改，例如电子邮件中的链接，因此我现在完全避免超链接到 GitHub 分支，并从第一天起链接到提交或标签。

我更喜欢在合并分支后将其删除。这可以防止存储库中一长串分支的视觉混乱。这些分支也会传播到存储库的所有分支。

首先我删除我的本地分支。这可以防止稍后被意外推送。

git branch -d branchName

然后我删除远程跟踪分支

git branch -dr remoteName\branchName

然后我删除 GitHub 上的分支。我使用网络界面，但等效命令如下。

git push remoteName :branchName

即使分支永远不会合并，通常我仍然希望为后代保留提交。不过我还是喜欢删除分支。为了分散提交并防止它们被垃圾收集器吞噬，我创建了一个带注释的标签，指向与已删除分支相同的提交。

git tag -a tagName commitOrBranchName

然后我将标签推送到github

git push remoteName tagName

I would add that the disadvantage of deleting branches is that you will break any hyperlinks to those branches on GitHub (this question is tagged github). You'll get a 404 Not Found error for those links. This is why I change my links to point to a commit or tag after I delete a branch on GitHub.

Because some links can't be changed, such as in email, I now avoid hyperlinking to GitHub branches entirely and link to a commit or tag from day one.

I prefer to delete branches after they're merged in. This prevents the visual clutter of a long list of branches in your repository. These branches also get propagated to all of the repository's forks.

First I delete my local branch. This prevents it from being accidentally pushed later.

git branch -d branchName

Then I delete the remote tracking branch

git branch -dr remoteName\branchName

Then I delete the branch on GitHub. I use the web interface, but the equivalent command is below.

git push remoteName :branchName

Even if the branch is never merged, typically I would still like to keep the commits around for posterity. However I still like to delete the branch. To spread the commits around and to keep them from being eaten by the garbage collector, I make an annotated tag pointing to the same commit as the deleted branch.

git tag -a tagName commitOrBranchName

Then I push the tag to github

git push remoteName tagName

回复收藏 0 原文

愿得七秒忆 2024-10-30 21:15:25

如果它已成功合并回来，甚至可能被标记，那么我会说它不再有用了。所以你可以安全地执行gitbranch -dbranchname。

回复收藏 0 原文

怪我鬧 2024-10-30 21:15:25

您似乎想删除 2011_Hotfix 分支而不丢失其历史记录。我将首先讨论删除，然后讨论历史。

上面已经描述了常用的 git 分支删除方法，并且它们按预期工作。 git 没有一个或两个单词的命令来表示“嘿 git，删除本地和远程分支。”但这种行为可以通过 shell 脚本来模仿。例如，采用 Zach Holman 的 shell 脚本 'git-nuke'。这非常简单：

#!/bin/sh
git branch -D $1
git push origin :$1

将其放入 $PATH 目录之一的可执行文件（例如，git-nuke）中。如果您不在 2011_Hotfix 分支上，只需运行 git-nuke 2011_Hotfix 即可删除本地和远程分支。这要快得多比标准 git 命令更简单，但可能更危险。

您对保存历史的关注是一件好事。在这种情况下，您不必担心。将 2011_Hotfix 合并到 master 后，2011_Hotfix 中的所有提交都将添加到 master 的提交历史记录中。简而言之，您不会因简单的合并而丢失历史记录。

我还要补充一句，这可能超出了您的问题范围，但仍然相关。假设 2011_Hotfix 上有 20 个微小的“正在进行的工作”提交；但是，您只希望将 2011_Hotfix 的一次完整提交添加到 master 的历史记录中。如何将所有 20 个小提交合并为一个大提交？幸运的是，git 允许您使用 git-rebase 将多个提交合并为一个提交。我不会在这里解释它是如何工作的；不过，如果您有兴趣，git-rebase< /a> 非常好。请注意，git rebase 会重写历史记录，因此应谨慎使用它，特别是如果您是新手的话。最后，您的 2011_Hotfix 场景是关于开发团队的，而不是单独开发的。如果项目团队成员使用 git rebase，那么团队明智的做法是制定关于使用 git rebase 的明确指南，这样团队中的某些牛仔开发人员就不会使用 git rebase。无意中损坏项目的 git 历史记录。

It seems that you want to delete the 2011_Hotfix branch without losing its history. I will discuss deletion first and history second.

The usual git branch deletion methods have already been described above, and they work as expected. git does not have a one or two word command that means, "Hey git, delete both the local and remote branch." But this behavior can be mimicked via shell script. For example, take Zach Holman's shell script 'git-nuke'. It is very simple:

#!/bin/sh
git branch -D $1
git push origin :$1

Put this in an executable file (e.g., git-nuke) in one of your $PATH directories. If you're not on the 2011_Hotfix branch, you simply running git-nuke 2011_Hotfix will delete both the local and remote branches. This is much faster & simpler--though perhaps more dangerous--than the standard git commands.

Your concern about preserving history is a good one. In this case, you needn't be worried. Once you merge 2011_Hotfix onto master, all commits from 2011_Hotfix will be added to master's commit history. In short, you will not lose history from a simple merge.

I have one more word to add that is perhaps beyond the scope of your question, but is relevant nonetheless. Let's imagine that there are 20 tiny, "work-in-progress" commits on 2011_Hotfix; however, you want only one complete commit for 2011_Hotfix to be added to master's history. How do you combine all 20 small commits into one big commit? Fortunately, git allows you to consolidate multiple commits into one commit by using git-rebase. I won't explain here how that works; though, if you're interested, the documentation for git-rebase is excellent. Do note that git rebase rewrites history, so it should be used judiciously, especially if you are new to it. Finally, your 2011_Hotfix scenario is about a dev team, not a solo dev. If project team members use git rebase, it is wise for the team to have explicit guidelines on the use of git rebase in order that some cowboy dev on the team doesn't unwittingly damage a project's git's history.