代码之家 › 专栏 › 技术社区 › Mizipzor

指示丢弃分支的Git约定

github git

Mizipzor · 技术社区 · 15 年前

脚本:

人A创建一个实验分支来解决问题。由于懒惰,个人B对代码感兴趣并想检查代码,因此个人A将推到他的Github,而不是配置他的工作站让个人B直接从他那里拉出来。

A和B正在进行黑客攻击,C个人看到了Github和克隆上的活动,急切地想看看发生了什么。同时,A和B得出了一个可怕的解决方案,并且 删除分支 . 但是,C人设法把这个想法变成了伟大的东西,并且想要分享。合并地狱开始于C的分支不再有一个与他的合并目标相同的祖先。

我好奇地想看看这种情况应该如何处理。

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

3 回复 | 直到 15 年前

hasen 15 年前

合并地狱开始于C的分支不再有一个与他的合并目标相同的祖先。

当然,A的主分支(在其历史中)与已删除的分支有一个祖先。

C可以将分支推到Github,然后A可以再次拉动它。怎么了?或者,C可以在一个新的分支(在A的主分支之上)中进行合并/重新平衡,然后再次从A中拉出一个分支。

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

我假设人A有这样的历史:

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

所以在删除了分支之后,他仍然有从a到c的提交,可能看起来更像:

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的主人那里拉出来,并将实验合并到其中。

VonC 15 年前

目前还没有正式的惯例。

扔掉分支的一个好例子(在本文中提到 Git rebase 从2010年3月起) git.git的pu分支 .

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

如果要跟踪它,请在您的 .git/config 文件,如下所示:

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

它告诉Git通过跳过快进检查为您处理问题( 用新裁判覆盖你的旧裁判 )
或者,如果您根本不想跟踪pu分支,可以完全删除该行。

可以想象,在未来的Git版本中,我们可能希望能够明确地标记一些分支“这将被重绕”。 并进行克隆操作以引起注意,自动为您提供加号。

因此,一个想法是积极地(通过钩子)防止推送那些扔掉的树枝,使它们:

shingara 15 年前

每个维护人员都要对自己的叉子负责。你不能假定另一个提交者有承诺或者没有什么好的事情。

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

如果你不想要一些补丁,你可以在你自己的叉子里恢复它。