为什么要将“远程跟踪分支‘起源/开发’合并到开发”？

我是我们组织里唯一一个承诺如下信息的人:

将远程跟踪分支“起源/发展”并入开发

不知道我做了什么导致他们，但我想停止。

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

108662 次浏览
小开
最佳答案

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参数删除已删除的上游分支。因此，如果在 origin存储库中删除了 foo分支，git remote update -p将自动删除您的 origin/foo参考文献。

  • 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}..

I prefer this approach over git pull --rebase for the following reasons:

  • It allows you to see the incoming upstream commits before your modify your history to incorporate them.
  • It allows you to pass the -p (--preserve-merges) option to git rebase in case you need to rebase an intentional merge (e.g., merge of an already-pushed feature branch into master).

Shorthand: git up instead of git pull

To make it easy to do the above, I recommend creating an alias called 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。这会尝试快进到新的上游提交，但是如果不可能的话，它会将你的本地提交重新定位到新的上游提交。这通常是可以的，但要小心:

  • Rebase 是一个高级主题，您应该在 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}到达的所有提交(这是“上游分支”的简写，即，如果 HEAD是 master，origin/master) ，在上游分支的顶部重播(初选)它们，然后移动当前分支引用指向重播提交的结果。这有效地将非合并提交移动到最近的上游提交，从而消除了由 git pull创建的合并。

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

小开 
git fetch
git rebase origin/master

这样应该可以了。或者如果你想继续使用拉

git pull --rebase

您还可以在配置中设置该分支，以便自动重新设置基础，或者自动设置为其他任何未来的跟踪分支。然后你就可以继续吸毒了

git pull

关于这一点，请参阅本页的“使用 rebase 而不是 merge 进行拉取”部分:

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

小开

将远程跟踪分支“起源/发展”并入开发

把原始/开发(远程更改)合并到开发(本地更改)中是一种 git 拉动，由于这些原因，我们遇到了很多问题，包括代码丢失等等。

因此，现在我们的工作流可以防止任何与 git pull 合并有关的问题，并使事情变得简单。基本上它就像一个 rebase，但是通过合并分支，在最基本的 gui 中很容易实现。其他的变化总是合并到您的，所以在冲突的情况下，您只修复影响您更改的行！只有您的更改出现在最终提交中。

  1. 检查和拉显影
  2. 从开发中创建一个特性分支 X
  3. 在 X 上做你的工作
  4. 获取可能的输入变更结帐和拉动开发
  5. 如果有远程更改，合并开发到 X
  6. 如果存在冲突，则解决它们
  7. 如果你做了5或6然后回到4
  8. 将 X 合并到开发中
  9. 推显影

是啊，看起来有点麻烦，换树枝，拉树枝什么的。但是如果您查看 rebase doc，他们会警告不要在共享分支中使用它。因此，最终创建相同的 X 分支，然后 git 获取原点 development 和 git rebase source/development，但是仍然需要将重新基于的 X 分支合并回共享分支 development，所以工作量是相同的。

通常情况下，如果在步骤5中有远程更改，特别是如果在步骤6中有冲突。您需要再次测试，这需要时间，所以这就是为什么您要回到第4步。在第8步和第9步中有一个比赛条件，但是实际上这是一个角落情况，其他人在你前面推。


提交答案