git safe rebase或“尝试rebase，fallback to merge”

Question

我正在考虑将我的 merge 工作流转换为更频繁地使用 rebase 。在这种特殊情况下，我是唯一的开发人员，但我在多个平台上工作，通常为特定于平台的部分编辑相同的文件，通常具有非冲突的更改。但我对此有点不确定，因为关于git merge vs git rebase的辩论及其安全性（例如见this与this，{{3}的两个最佳答案}）。

问题：如何执行以下操作，目标是“安全”，但仍尽可能干净拉/ rebase / merge：

• 如果有未推送的提交，则git pull --rebase直到第一次合并操作与本地历史记录冲突。
• 然后git pull --no-rebase合并其余部分并进行冲突解决。
• 可能会切换回基础以进行最后一次非冲突的更改，以保持历史记录的并行部分尽可能短。

因此，如果没有冲突，最终结果将是带有rebase和良好的线性历史。如果存在冲突，则可以看到合并，但并行历史记录将尽可能短。

这是否可以使用简单的普通git命令或两个，使用正确的开关（我可以写入拉动脚本或别名）？如果没有，是否可以使用现有的工具？

另一种看待这个问题的方法：我想自动决定选择 rebase 或 merge ，所以在做的时候我不需要考虑这个细节拉

此外，这甚至没有任何意义吗？ ：）

Answer 1

我按照你的建议行事。首先，我尝试一个rebase，如果没有冲突，那么它只是有效，你的历史更清洁。如果发生冲突，我会合并。

唯一的区别是我不会尝试在你的第三个要点中建议的一次拉动的提交之间拆分合并和rebase。事实上，我不确定这是否有意义。这似乎与解决冲突时处理冲突并执行rebase continue相同。结果与带冲突的rebase相同。

如果您需要推送更改。要么做一个rebase，要么在有冲突的情况下进行合并。