什么时候可以安全地对推送的功能分支进行基础设置

时间:2018-10-19 12:51:19

标签: git branch rebase

我读到,除非我知道后果,否则我不应该将功能分支重新建立基础(使用master的更改来更新它,以便以后进行无冲突的合并),

>

那会有什么后果?

我是该功能分支上的唯一开发人员,如果我重写它的历史记录,我也不会在乎自己。但是对其他人有什么影响?

我列出了一些我能想到的东西。请更正我,并添加更多(如果您知道)。

  1. 某人从我的分支分支/重新建立了基础:他们在下一次拉动时获得了分支的未请求的重新构建
  2. 有人将我的分支合并到他们的分支中:他们出人意料地获得了更改的合并提交,因此在下一次拉动时可能发生冲突
  3. 某人选择了提交:???
  4. 有一个打开的“合并/拉取”请求:现在指向重新设置了分支的分支???
  5. 链接到问题,MR / PR,平台降价中的提交的东西:指向更新的文件/提交吗?

1 个答案:

答案 0 :(得分:1)

后果是针对那些在重新定基之前将工作立足于您的分支机构的人们。考虑一下,如果您在功能分支上进行了3次修订,然后开发人员B从您的分支开始了一个分支,并进行了3次提交...。然后您重新设置了基础...然后最终,您的分支合并到了master中。很好……其他开发人员在3个修订版之后完成并要求合并。如果该分支直接合并,历史将是什么样?它将为您的3次提交(原始修订和重新设置基准之后的修订)提供重复的内容……不是最好的选择,对吧?在这种情况下,其他开发人员在合并后必须在您的重新设置基础的分支或主节点上重新建立基础。另一个棘手的情况是当您重新建立公共分支的基础并且不告诉任何人时。假设您更正了master的最后3个修订版,并强制其替换普通master。...如果您有已经在原始master上工作的开发人员,则当他们尝试将更改推送到该分支时,他们不会之所以可以这样做,是因为分支机构已经分叉,并且它们没有合并新的主服务器(最好不要这样做,因为您将再次得到重复的修订版本。...它们也必须重新设置基准)。