使用不带“--rebase”标签的“git pull”命令来合并分支

Question

类似的问题还有很多，但我还是搞不懂。

在我们的团队中，我们使用“git pull”来合并分支，而不是“git fetch”+“git merge”。当我尝试在网络上搜索时，如果它是正确的流程 - 有各种主题，例如“好吧，您可以使用 git pull --rebase 代替，但它有风险”。我可以理解这一点 - 但在我们的团队中我们不使用 rebase。

例如，当我们需要合并branch1和branch2然后将其发送到devbranch时，我们只需这样做：

1. git pull originbranch1（来自devbranch）
2. git pull originbranch2（来自devbranch）*解决冲突（如果有）
3. 检查本地是否一切正常
4. git Push 起源 devbranch
5. 使用branch1和branch2从devbranch提取最新（合并）的代码

我们现在使用这个工作流程没有任何问题，但我只是想知道 - 这个流程是否正常并且有任何问题吗？

Answer 1

我想将其添加为评论，但随后所需的字数超出了我的预期，因此我将其作为答案发布。

我们使用“git pull”来合并分支，而不是“git fetch”+“git merge”。

实际上，当您运行 git pull 时，它会在后台运行 fetch 和 merge / rebase 命令，具体取决于您使用的参数。

在默认模式下，git pull 是 git fetch 后跟 git merge FETCH_HEAD 的简写。

更准确地说， git pull 使用给定的参数运行 git fetch 并调用 git merge 将检索到的分支头合并到当前分支中。使用 --rebase，它运行 git rebase 而不是 git merge。

https://git-scm.com/docs/git-pull

=================================================== =============

“好吧，你可以使用 git pull --rebase 代替，但这有风险”。这个我能理解..

我认为这有点误导。只要你不重写公共分支的历史，Rebase 就没有风险。（这会引起很多混乱）。

但举个例子，如果您正在开发一个功能分支，并且想要保持远程开发分支的最新状态，那么您可以进行变基以使分支的历史记录保持最新，同时保持干净。定期使用 rebase 的优点之一是，您将在早期阶段解决大量合并冲突，并且您的提交历史记录将是线性的（因为您可以避免所有不需要的合并提交）。

希望它有帮助:) 如果您有任何疑问，请随时询问。