为什么我要将“远程跟踪分支'origin/develop'合并到develop”？

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

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

您可以使用 git pull --rebase 来防止这种情况在未来发生，但变基有其危险，并且 I recommend avoiding pull altogether。

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

# 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/master）。它不会触及您的工作目录、索引或本地分支。 -p 参数修剪已删除的上游分支。因此，如果 foo 分支在源存储库中被删除， git remote update -p 将自动删除您的 origin/foo 引用。

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

git rebase -p @{u} 有效地移动您已经做出但尚未推送到上游分支之上的提交，这消除了创建您试图避免的愚蠢合并提交的需要。这提高了开发历史的线性度，使其更易于查看。 -p 选项告诉 Git 保留合并。这可以防止 Git 线性化被 rebase 的提交。例如，如果您将功能分支合并到 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)，则在上游分支的顶部重放（cherry-pick）它们，然后移动当前分支引用以指向重放提交的结果。这有效地将非合并提交移动到最近的上游提交，从而消除了由 git pull 创建的合并。

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

---

git fetch
git rebase origin/master

那应该这样做。或者如果你想继续使用拉

git pull --rebase

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

git pull

有关此页面的“使用变基而不是合并”部分的更多信息：

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

---

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

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

所以现在我们的工作流程可以防止 git pull 合并出现任何问题并保持简单。基本上它就像一个变基，但通过合并分支，在最基本的 gui 中很容易实现。其他更改始终合并到您的更改中，因此在发生冲突时，您只需修复影响您更改的行的内容！并且只有您的更改才会出现在最终提交中。

签出并拉出开发 从开发创建一个功能分支 X 在 X 上进行工作以获取可能的传入更改签出并拉出开发 如果有远程更改合并开发到 X 如果有冲突解决它们如果你做了 5 或 6 然后返回4 将 X 合并到开发中 推开发

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

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

---