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

Question

与此问题有很多类似的问题，但我仍然无法理解。

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

例如，当我们需要合并branch1和branch2并将其发送到devbranch时，我们只需执行以下操作：

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

现在使用此工作流程没有问题，但是我只是想知道-此流程是否正常，是否有任何问题？

Answer 1

我考虑将其添加为评论，但随后花费了比我预期更多的单词，因此我将其发布为答案。

  

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

实际上，当您运行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，但这有风险”。我可以   明白这一点。

我认为这有点误导。只要您不重写公共分支机构的历史记录，重新设置基础就不会有风险。 （这会引起很多混乱）。

但是举个例子，如果您正在使用功能分支，并且希望与远程dev分支保持最新，则可以重新设置基础以保持分支的历史记录最新并进行清理时间。定期使用rebase的优点之一是，您将在早期解决很多合并冲突，并且提交历史记录是线性的（因为您可以避免所有不必要的合并提交）。

希望它会有所帮助:)随时询问您是否有任何疑问。

Answer 2

您的流程很好，当所有使用存储库的人对定义的git流程有基本了解时，您的develop和可能的master分支将保持干净在它们之间合并时只是快速转发。

现在我想说git pull --rebase对于git的新手来说就像是救命稻草，主要是因为克隆后，他们对“分支”一无所知，直接开始编辑到master分支中而不是创建自己的分支等，因此，当他们想更新自己的本地存储库git pull但又想保留其更改而不创建新分支时，--rebase选项就很方便了。