为什么我要合并“远程跟踪分支”origin/develop“？发展”？

Question

我是我的组织中唯一做出带有以下消息的承诺的人：

将远程跟踪分支“origin/develop”合并到开发中

不确定我正在做什么导致它们，但我想停止。

我发出什么命令来创建此提交，以及我应该使用什么正确的命令来不生成它？

Answer 1

git pull 可能正在创建提交。如果您进行本地提交，然后在其他人将提交推送到存储库后运行 git pull，Git 会下载其他开发人员的提交，然后将其合并到您的本地分支中。

如何避免将来发生这些合并提交

您可以使用 git pull --rebase 来防止将来发生这种情况，但是 rebase 有其危险，并且 我建议完全避免拉动。

相反，我鼓励您遵循以下使用模式：

# download the latest commits
git remote update -p

# update the local branch
git merge --ff-only @{u}

# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}

解释

• git remote update -p 下载远程存储库中的所有提交并更新远程跟踪分支（例如，origin/大师）。它不会触及您的工作目录、索引或本地分支。

  -p 参数会修剪已删除的上游分支。因此，如果在 origin 存储库中删除 foo 分支，git Remote update -p 将自动删除您的 origin/foo< /code> ref.

• git merge --ff-only @{u} 告诉 Git 将上游分支（@{u} 参数）合并到本地分支，但前提是你的本地分支可以“快速转发”到上游分支（换句话说，如果它没有分歧）。

• git rebase -p @{u} 有效地移动您已做出但尚未推送到上游分支顶部的提交，这消除了您创建愚蠢的合并提交的需要正在努力避免。这提高了开发历史的线性度，使其更容易审查。

  -p 选项告诉 Git 保留合并。这可以防止 Git 线性化正在重新设置基准的提交。例如，如果您将一个功能分支合并到 master 中，这一点就很重要。如果没有 -p，功能分支上的每个提交都会在 master 上重复，作为 git rebase 完成的线性化的一部分。这将使开发历史更难回顾，而不是更容易。

  注意：git rebase 可能不会执行您期望的操作，因此在推送之前请检查结果。例如：

  git log --graph --oneline --decorate --date-order --color --boundary @{u}..
  

与 git pull --rebase 相比，我更喜欢这种方法，原因如下：

• 它允许您在修改历史记录以合并它们之前查看传入的上游提交。
• 它允许您将 -p (--preserve-merges) 选项传递给 git rebase，以防您需要对有意合并进行变基 (例如，将已推送的功能分支合并到master中）。

简写：git up 而不是 git pull

为了使上述操作变得容易，我建议创建一个名为 up 的别名：

git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

现在您所需要的一切要使您的分支保持最新状态，需要运行：

git up

而不是 git pull。如果您因本地分支与上游分支分歧而收到错误，则提示您重新设置基准。

为什么不git pull --rebase？

运行 git pull --rebase 相当于运行 git fetch ，然后运行 ​​git rebase 。这会尝试快进到新的上游提交，但如果不可能，那么它将把本地提交重新设置为新的上游提交。这通常没问题，但要小心：

• 变基是一个高级主题，您应该在变基之前了解其含义。
• git pull --rebase 不会让您有机会在合并提交之前检查提交。根据上游的更改，rebase 很可能是错误的操作 — rebase --onto、merge、reset 或 >push -f 可能比普通的rebase 更合适。
• （目前）不可能将 --preserve-merges 传递给 rebase 操作，因此任何有意的功能分支合并都将被线性化，重播（从而复制）所有功能分支提交。

“修复”由 git pull 创建的现有合并提交

如果您尚未推送由 git pull 创建的合并提交，您可以对合并提交进行变基。假设您没有进行任何有意的合并（例如，将已推送的功能分支合并到当前分支中），则应执行以下操作：

git rebase @{u}

上述命令告诉 Git 选择可从 访问的所有非合并提交HEAD（当前提交），减去从 @{u} （这是“上游分支”的简写，即 origin/master）可到达的所有提交> 如果HEAD 是 master），在上游分支顶部重放（择优挑选）它们，然后移动当前分支引用以指向重放提交的结果。这有效地将非合并提交移动到最新的上游提交，从而消除了 git pull 创建的合并。

如果您有意进行合并提交，则不需要运行 git rebase @{u} 因为它会重播其他分支中的所有内容。处理这种情况要复杂得多，这就是为什么最好使用 git up 并完全避免 git pull 的原因。您可能必须使用 reset 撤消由 pull 创建的合并，然后执行 git rebase -p @{u}。 git rebase 的 -p 参数对我来说并没有可靠地工作，所以你最终可能不得不使用 reset 来撤消有意的合并，将本地分支更新为 @{u}，然后重做有意合并（如果存在很多毛茸茸的合并冲突，这会很痛苦）。

Answer 2

git fetch
git rebase origin/master

应该可以做到这一点。或者，如果您想继续使用 pull，

git pull --rebase

您还可以在配置中设置该分支以自动变基，或者为您将来创建的任何其他跟踪分支自动进行设置。然后，您可以返回到

git pull

在本页的“使用 rebase 而不是合并进行拉取”部分中使用更多相关内容：

https://mislav.net/2010/07/git-tips/

Answer 3

将远程跟踪分支“origin/develop”合并到develop

这是一个 git pull，将 origin/develop（远程更改）合并到开发（本地更改）中，因此我们遇到了很多问题，丢失了代码等等。

因此，现在我们的工作流程可以防止 git pull 合并出现任何问题，并使事情变得简单。基本上它就像一个变基，但是通过合并分支，可以在最基本的 GUI 中轻松完成。其他更改始终会合并到您的更改中，因此如果发生冲突，您只需修复影响您更改的行的内容即可！并且只有您的更改才会出现在最终提交中。

1. 签出并拉动开发
2. 从开发中创建一个功能分支 X 在
3. X 上进行工作
4. 获取可能的传入更改 签出并拉动开发
5. 如果存在远程更改，则将开发合并到 X
6. 如果存在冲突，请解决冲突
7. 如果您执行了 5 或 6，则返回到4
8. 将 X 合并到开发中
9. 推送开发

是的，它看起来有点麻烦，改变分支，拉动等等。但是如果你查看 rebase 文档，他们会警告不要在共享分支中使用它。因此，您最终将创建相同的 X 分支，然后 git fetch origindevelopment 和 git rebase origin/develop ，并且您仍然需要将该重新基化的 X 分支合并回共享分支develop，因此工作量相同。

通常情况下，如果第 5 步有远程更改，特别是如果第 6 步存在冲突。您需要再次测试，这需要时间，所以这就是您返回到第 4 步的原因。第 8 步和第 9 步存在竞争条件，但这确实是一个极端的情况，其他人就在你前面推动。