1

有很多类似的问题，但我仍然无法得到它。

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

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

  1. git pull origin branch1（来自devbranch）
  2. git pull origin branch2 (from devbranch) *解决冲突，如果有的话
  3. 检查本地是否一切正常
  4. git push origin 开发分支
  5. 使用 branch1 和 branch2 从 devbranch 提取最新（合并）代码

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

4

2 回答 2

2

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

我们使用“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 的一个优点是您将在早期阶段解决许多合并冲突，并且您的提交历史将是线性的（因为您可以避免所有不需要的合并提交）。

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

于 2018-07-23T09:18:42.320 回答
0

当所有使用存储库的人都对定义的流程有基本的了解时，您的流程很好并且工作得很好git，事实上，您develop和可能master的分支将通过在它们之间合并时快速转发来保持干净的历史记录。

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

于 2018-07-23T10:51:44.083 回答