Git约定表示扔掉分支

Question

场景:

人员A创建一个实验分支来解决问题.B人感兴趣并且想要检查代码,由于懒惰的人A推送到他的github而不是配置他的工作站让B人直接从他那里拉.

A和B正在黑客攻击,C人看到github和克隆人的活动,急于查看最新情况.与此同时,A和B总结了一个可怕的解决方案并删除了分支.但是,C人设法将这个想法变成了一个伟大的想要分享的东西.合并地狱开始于C的分支不再与他的合并目标有共同的祖先.

---

我很高兴看到应该如何处理这种情况.

• 是否有一个可接受的分支命名约定,表明 - 即使被推 - 这个分支很可能完全被删除.A人的一种方式表明"如果你从中拉出来,我就无法保证持续的快乐".
• 或者在git中是否有一种方法(命令)可以让我将标记分支丢弃？
• 如果有人可以从中撤出,那么,无论在何种情况下,是否都不会接受改变git历史？
• A人是否应该花时间正确配置他的工作站让B人直接从他那里拉？因此,在黑暗中,不要让任何人知道他们正在做什么.
• 也许唯一可行的解​​决方案是良好的老式沟通; 跟你说同行吧.

如果一切都失败了,在这种情况下C人的正确策略是什么？在断开连接的图形中完成工作后,如何正确应用更改？

Answer 1

当 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 的 master 中提取数据并将实验合并到其中。