5

我正在考虑将仅合并的工作流程转变为更频繁地使用变基。在这种特殊情况下，我是唯一的开发人员，但我在多个平台上工作，经常为特定于平台的部分编辑相同的文件，通常进行不冲突的更改。但我对此有点不确定，因为关于 git merge 与 git rebase 以及它们的安全性的争论（例如，参见this与this ，一个问题的两个最佳答案）。

问题：如何执行以下操作，以“安全”为目标，但仍尽可能干净地拉/变基/合并：

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

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

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

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

另外，这有什么意义吗？:)

4

1 回答 1

2

我遵循你的建议。首先，我尝试进行变基，如果没有冲突，那么它就可以工作，并且您的历史记录要干净得多。如果有冲突，我会合并。

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

如果您有需要推送的更改。要么做一个变基，要么，如果有冲突，做一个合并。

于 2013-10-09T13:30:57.100 回答