如何在拉取/合并请求之前更新（拉取）分支？

Question

例如，假设我有一个名为 develop 的分支，我的所有功能都是从 develop 创建的分支，稍后我将需要执行合并请求（在 GitLab 中， GitHub 将是一个拉取请求）。

如果我需要在将新分支推送到 origin 之前更新它并执行合并/拉取请求，“git pull origin develop”是否也会更新我的新分支？
如果没有，我该怎么做？

Answer 1

正确的命令是：

git fetch
git switch myNewBranch
git rebase origin/develop
git push --force 

那样，您就是在最新的 origin/develop

之上重放（重新设定）您的新分支

现有的拉取请求/合并请求将自动更新，其解决方案将是一个简单的合并（因为 myNewBranch 提交都是在目标分支上的 新 提交 {{ 1}})

Answer 2

有几种方法，这取决于您使用的分支策略。在逐个项目的基础上，我会选择一种策略并坚持下去，但最有效的策略取决于您正在寻找什么。

合并： （从分支执行）：

• git pull（或git fetch）
• git merge origin/develop
• git push

这保留了历史并且是非破坏性的。它在分支上创建一个新的提交，代表从 develop 引入分支的更改。

变基： （从分支执行）：

• git pull --rebase（或 git fetch）
• git rebase origin/develop
• git push --force（或 git push -f）

这会重写历史并且具有破坏性。分支上的原始提交将被丢弃并重新创建（它们看起来相似（相同的评论、文件和作者），但具有不同的提交 ID 和提交时间。它使历史更加“线性”。

用壁球变基： （从分支执行）：

• git pull（或git fetch）
• git rebase origin/develop
• git rebase -i HEAD~2（假设分支在开发前有 2 次提交）
• git push --force（或 git push -f）

类似于rebase（上面） - 重写和破坏性 - 但将分支折叠为单个提交。历史不仅是线性的，而且是简明的——整个分支都被折叠成一个单一的提交。

---

我通常的建议是避免对缺乏经验的团队使用 rebase。使用 rebase 很容易遇到麻烦，并且有各种各样的事情需要注意。尽管如此，rebase 创造了漂亮的历史（如果这很重要） - 但取证变得更难（如果这很重要）。 “--force”是 git 告诉你你正在取消安全措施并小心你正在做的事情的方式。

查看 git-pull 上的手册页。有一些命令可以折叠 pull/merge 或 pull/rebase 以将步骤减少一个。还有 git-config 命令指定“拉”始终是“拉和合并”或“拉和变基”。