我正在考虑将仅合并工作流转换为更频繁地使用变基。在这种特殊情况下，我是唯一的开发人员，但我在多个平台上工作，经常为特定于平台的部分编辑相同的文件，通常具有不冲突的更改。但我对此有点不确定，因为关于 git merge 与 git rebase 以及它们的安全性的争论(例如，请参阅这个与这个，一个问题的两个最高答案(。
问题：如何做类似下面的事情，目标是"安全"，但仍然尽可能干净 拉/变基/合并：
- 如果有未推送的提交，则
git pull --rebase直到与本地历史记录冲突的第一个合并操作。 - 然后
git pull --no-rebase合并其余部分并解决冲突。 - 可以切换回变基以进行最后的非冲突更改，以使历史记录的并行部分尽可能短。
因此，如果没有冲突，最终结果将是变基和漂亮的线性历史记录。如果存在冲突，则合并将可见，但并行历史记录将尽可能短。
这是否可以通过简单的普通 git 命令或两个正确的开关(我可以将其写入拉取脚本或别名(？如果没有，是否可以使用某些现有工具？
看待这个问题的另一种方式是：我想自动决定选择变基或合并，所以我在拉动时不需要考虑这个细节。
另外，这有什么意义吗？ :)
我遵循您的建议。首先，我尝试变基，如果没有冲突，那么它就可以工作，并且您的历史记录要干净得多。如果有冲突，我会进行合并。
唯一的区别是我不会尝试在一次拉取的提交之间拆分合并和变基，就像您在第三个要点中建议的那样。事实上，我不确定这是否有意义。这似乎与解决冲突并在解决冲突时执行rebase continue相同。结果将与冲突的变基相同。
如果您有需要推送的更改。要么变基，要么，如果存在冲突，则进行合并。