git safe rebase或"尝试rebase,fallback to merge"

Question

我正在考虑将我的仅合并工作流转换为更频繁地使用rebase.在这种特殊情况下,我是唯一的开发人员,但我在多个平台上工作,通常为特定于平台的部分编辑相同的文件,通常具有非冲突的更改.但是我对此有点不确定,因为关于git merge vs git rebase以及它们的安全性的争论(例如看到这个与此相关,这是问题的两个最佳答案).

问题:如何做以下的事情,目标是"安全",但仍尽可能干净拉/ rebase/merge:

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

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

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

另一种看待这个问题的方法:我想自动决定选择rebase还是合并,所以在做pull时我不需要考虑这个细节.

此外,这甚至有意义吗？:)

Answer 1

我遵循你的建议。首先，我尝试重新设置基准，如果没有冲突，那么它就会起作用，并且您的历史记录会干净得多。如果有冲突我会进行合并。

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

如果您有需要推送的更改。要么进行变基，要么如果存在冲突，进行合并。