147

我是我组织中唯一一个使用以下消息进行提交的人：

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

不知道我在做什么来引起他们，但我想停下来。

我发出什么命令来创建这个提交，我应该使用什么正确的命令来不产生它？

4

3 回答 3

228

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

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

您可以使用它git pull --rebase来防止将来发生这种情况，但是变基有其危险，我建议完全避免pull.

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

# 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分支在origin存储库中被删除，git remote update -p将自动删除您的origin/fooref。

  • 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 是错误的操作——a rebase --onto, merge, reset, 或者push -f可能比 plain 更合适rebase。
  • （当前）不可能传递--preserve-merges给 rebase 操作，因此任何有意合并的特性分支都将被线性化，重放（并因此复制）所有特性分支提交。

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

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

git rebase @{u}

HEAD上面的命令告诉 Git 选择所有可从（当前提交）到达的非合并提交，减去所有可从@{u}（“上游分支”的简写，即origin/masterif HEADis master）到达的提交，重播（cherry-pick ) 将它们放在上游分支的顶部，然后移动当前分支引用以指向重放提交的结果。这有效地将非合并提交移动到最近的上游提交，从而消除了由git pull.

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

于 2011-06-20T04:55:44.147 回答
21 
git fetch
git rebase origin/master

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

git pull --rebase

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

git pull

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

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

于 2011-06-20T05:59:22.857 回答
0

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

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

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

  1. 结帐并拉动开发
  2. 从开发创建一个功能分支 X
  3. 在 X 上做你的工作
  4. 要获得可能的传入更改结帐并拉动开发
  5. 如果有远程更改合并开发到 X
  6. 如果有冲突解决它们
  7. 如果你做了 5 或 6 则回到 4
  8. 将 X 合并到开发中
  9. 推动发展

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

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

于 2021-07-08T20:58:39.900 回答