指示丢弃分支的 Git 约定答案

【问题标题】：Git convention to indicate throw away branches指示丢弃分支的 Git 约定
【发布时间】：2010-03-05 10:23:45
【问题描述】：

场景：

A 人创建了一个实验分支来解决问题。 B 产生了兴趣并想检查代码，因为 A 懒惰地推送到他的 github，而不是配置他的工作站让 B 直接从他那里拉。

A 和 B 正在入侵，C 看到了 github 上的活动并进行了克隆，急于查看发生了什么。与此同时，A 和 B 得出了一个可怕的解决方案，并删除了分支。但是 C 人设法将这个想法变成了很棒的东西并想分享。当 C 的分支不再与他的合并目标有共同的祖先时，合并地狱就开始了。

我很想知道应该如何处理这种情况。

如果所有其他方法都失败了，那么在这种情况下，C 人的正确策略是什么？当您在断开连接的图表中完成工作时，如何正确应用更改？

【问题讨论】：

标签： git github

【解决方案1】：

目前还没有正式的约定。

一次性分支的一个很好的例子（2010 年 3 月在Git rebase 上的这篇文章中提到）是 git.git 的分支 pu。

“pu”分支通常不会快进，因为自上次拉取以来，其中的一些提交已被完全删除。

如果您想跟踪它，请在您的 .git/config 文件的正确行中添加一个加号 (+)，如下所示：

[remote "origin"]
        fetch = +refs/heads/pu:refs/remotes/origin/pu

这告诉 git 通过简单地跳过快进检查（用新的 ref 覆盖旧的 ref）为你处理问题。
或者，如果您根本不想跟踪 pu 分支，则可以完全删除该行。

可以想象，在未来的 git 版本中，我们可能希望能够显式地标记一些分支“预计会被重绕”，并让克隆操作引起注意，给你加号自动。

所以一个想法是积极地防止（通过钩子）任何推到那些被丢弃的树枝上：

【讨论】：

【解决方案2】：

合并地狱始于 C 的分支与其合并目标不再有共同祖先。

A 的主分支肯定有（在其历史中）被删除分支的祖先。

C 可以将分支推送到 A 可以再次拉取它的 github。那有什么问题？或者，C 可以在一个新分支中（在 A 的 master 之上）进行合并/变基，然后再次让 A 从他那里拉出来。

删除分支实际上并不会重写历史记录，至少不会以阻止合并的糟糕方式。

我假设 A 有这样的历史：

a--b--c--d--e--f--g    master
      |
      x--y--z   experiment

所以删除分支后，他还有从a到c的commits，大概看起来更像：

a--b--c--d--e--f--g--h--i--j--k    master

C 人大概有：

a--b--c--d--e--f--g    master
      |
      x--y--z--w--v--q   experiment

这是一个完全合理的场景，合并不应该那么糟糕。

例如，C 可以从 A 的 master 中拉取并合并实验。

【讨论】：

也许我是个胆小鬼，我自己没有在实践中尝试过。我在 git 上阅读的每个教程/介绍都明确指出“不要重写推送的历史”，这不是这里发生的事情吗？还是说它合法，甚至容易处理？
删除分支不会重写历史记录。
即使你害怕在真正的 repo 上这样做，在本地创建一个也很容易，这样你就可以尝试看看会发生什么

【解决方案3】：

每个维护者都对自己的分叉负责。你不能假设另一个提交者有提交或没有什么好东西。

如果提交者和作者不是同一个人，你可以看到信息。

如果你不想要一些补丁，你可以在你自己的 fork 中恢复它。

【讨论】：