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

Why am I merging "remote-tracking branch 'origin/develop' into develop"?

提问by Jordan Feldstein

I'm the only one in my organization who's making commits with the following message:

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

Merge remote-tracking branch 'origin/develop' into develop

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

Not sure what I'm doing to cause them, but I'd like to stop.

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

What command am I issuing to create this commit, and what is the proper command I ought to be using to not produce it?

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

回答by Richard Hansen

git pullis probably creating the commit. If you make a local commit and then run git pullafter someone else pushes a commit up to the repository, Git downloads the other developer's commit and then merges it into your local branch.

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

How to avoid these merge commits in the future

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

You could use git pull --rebaseto prevent this from happening in the future, but rebasing has its perils, and I recommend avoiding pullaltogether.

您可以使用git pull --rebase以防止这种情况再度发生，但垫底都有危险，而且我建议避免pull完全。

Instead, I encourage you to follow this usage pattern:

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

# 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}

Explanation

解释

• git remote update -pdownloads all of the commits in the remote repositories and updates the remote tracking branches (e.g., origin/master). It does NOT touch your working directory, index, or local branches.

  The -pargument prunes deleted upstream branches. Thus, if the foobranch is deleted in the originrepository, git remote update -pwill automatically delete your origin/fooref.

• git merge --ff-only @{u}tells Git to merge the upstream branch (the @{u}argument) into your local branch but only if your local branch can be "fast forwarded" to the upstream branch (in other words, if it hasn't diverged).

• git rebase -p @{u}effectively moves the commits you've made but haven't yet pushed on top of the upstream branch, which eliminates the need to create the silly merge commits you're trying to avoid. This improves the linearity of the development history, making it easier to review.

  The -poption tells Git to preserve merges. This prevents Git from linearizing the commits being rebased. This is important if, for example, you merged a feature branch into master. Without -p, every commit on the feature branch would be duplicated on masteras part of the linearization done by git rebase. This would make the development history harder to review, not easier.

  Beware: git rebasemight not do what you expect it to do, so review the results before pushing. For example:

  git log --graph --oneline --decorate --date-order --color --boundary @{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 线性化重新定位的提交。例如，如果您将功能分支合并到master. 没有-p，功能分支上的每个提交都将master作为git rebase. 这将使开发历史更难回顾，而不是更容易。

  当心： git rebase可能不会做你期望它做的事情，所以在推送之前查看结果。例如：

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

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

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

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

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

Shorthand: git upinstead of git pull

简写： git up代替git pull

To make it easy to do the above, I recommend creating an alias called up:

为了便于执行上述操作，我建议创建一个名为 的别名up：

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

Now all you need to do to bring your branch up to date is to run:

现在你需要做的就是让你的分支保持最新状态：

git up

instead of git pull. If you get an error because your local branch has diverged from the upstream branch, that's your cue to rebase.

而不是git pull. 如果您因为本地分支与上游分支分叉而收到错误消息，这就是您重新设定基准的提示。

Why not git pull --rebase?

为什么不git pull --rebase呢？

Running git pull --rebaseis equivalent to running git fetchfollowed by git rebase. This attempts to fast-forward to the new upstream commits, but if that's not possible then it will rebase your local commits onto the new upstream commits. This is usually OK, but be careful:

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

• Rebase is an advanced topic, and you should understand the implications before rebasing.
• git pull --rebasedoes not give you an opportunity to examine the commits before incorporating them. Depending on what changed upstream, it's quite possible that rebase is the wrong operation—a rebase --onto, merge, reset, or push -fmight be more appropriate than a plain rebase.
• It is not (currently) possible to pass --preserve-mergesto the rebase operation, so any intentional merge of a feature branch will be linearized, replaying (and thus duplicating) all of the feature branch commits.

• Rebase 是一个高级主题，您应该在 rebase 之前了解其含义。
• git pull --rebase不给你机会在合并之前检查提交。根据什么改变后的上行，这很可能是重订是错误的操作，一rebase --onto，merge，reset，或者push -f可能比普通的更合适rebase。
• （当前）不可能传递--preserve-merges到 rebase 操作，因此任何有意合并的功能分支都将被线性化，重放（并因此复制）所有功能分支提交。

"Fixing" an existing merge commit created by git pull

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

If you haven't yet pushed a merge commit created by git pull, you can rebase out the merge commit. Assuming you haven't made any intentional merges (e.g., merging an already-pushed feature branch into your current branch), the following should do it:

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

git rebase @{u}

The above command tells Git to select all of the non-merge commits reachable from HEAD(the current commit), minus all the commits reachable from @{u}(which is shorthand for "the upstream branch", i.e., origin/masterif HEADis master), replay (cherry-pick) them on top of the upstream branch, and then move the current branch reference to point to the result of replaying the commits. This effectively moves the non-merge commits onto the most recent upstream commit, which eliminates the merge created by git pull.

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

If you have an intentional merge commit, you don't want to run git rebase @{u}because it will replay everything from the other branch. Dealing with this case is substantially more complicated, which is why it's good to use git upand avoid git pullaltogether. You'll probably have to use resetto undo the merge created by pulland then do git rebase -p @{u}. The -pargument to git rebasehasn't worked reliably for me, so you might end up having to use resetto undo the intentional merge, update your local branch to @{u}, and then redo the intentional merge (which is a pain if there were a lot of hairy merge conflicts).

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

回答by Adam Dymitruk

git fetch
git rebase origin/master

That should do it. Or if you want to continue to use pull

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

git pull --rebase

You can also setup that branch in your config to rebase automatically, or be setup like that automatically for any other future tracking branches you make. Then you can go back to just using

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

git pull

More on this in the "pull with rebase instead of merge" section of this page:

在本页的“使用变基而不是合并拉动”部分中的更多信息：

http://mislav.uniqpath.com/2010/07/git-tips/

http://mislav.uniqpath.com/2010/07/git-tips/