为什么我将“远程追踪分支”的起源/开发合并为“开发”？ [英] Why am I merging "remote-tracking branch 'origin/develop' into develop"?

问题描述

合并远程追踪分支的原产地/发展'开发

不确定我在做什么来造成它们，但我想停下来。

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

感谢，

〜j

解决方案 $ c>可能正在创建提交。如果你做了一个本地提交，然后在别人向存储库推送一个提交之后运行 git pull ，Git下载其他开发者的提交，然后将它合并到你的本地分支。

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

您可以使用 git pull --rebase 可以防止未来发生这种情况，但是rebasing有其危险，并且我建议避免 pull 总共。

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

 ＃下载最新的提交文件
 git remote update -p 
 
＃更新本地分支
 git merge --ff-only @ {u} 
 
＃如果上面的失败告诉本地分支有
＃diverged：
 git rebase -p @ {u } 
  

说明

• git远程更新-p 下载所有的c在远程存储库中省略并更新远程跟踪分支（例如， origin / master ）。它不会触及你的工作目录，索引或本地分支。

  
  
  

  -p 参数修剪已删除的上游分支。因此，如果在 origin 存储库中删除 foo 分支，则 git remote update -p 会自动删除 origin / foo ref。




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

git rebase -p @ {u} 有效地移动了你已经做出的提交，但还没有推到上游分支之上，这就消除了创建愚蠢合并提交你试图避免。这改善了开发历史的线性，使其更容易审查。




-p 选项告诉Git保持合并。这可以防止Git线性化提交的提交。例如，如果您将一个功能分支合并到 master 中，这一点非常重要。如果没有 -p ，功能分支上的每个提交都会在 master 上重复，作为由 git rebase 。这会让开发历史难以审查，并不容易。
$ b

当心： git rebase 可能无法达到您期望的效果，因此请在推送前查看结果。例如：



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

在 git pull --rebase 之上，原因如下：

• 它允许你看到上游提交，然后再修改历史记录以合并它们。


• 它允许您传递 -p （<$ c如果你需要重新绑定一个有意合并（例如，合并一个已经存在的合并对象），那么将$ c> - preserve-merges ）选项设置为 git rebase 推送功能分支到 master ）。
  

速记： git up 而不是 git pull

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

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

现在您只需要将您的最新的分支是运行：

  git up 
  

而不是 git pull 。如果你因为你的本地分支已经偏离上游分支而出现错误，那么你的提示就是rebase。

为什么不是 git pull --rebase ？

运行 git pull --rebase 相当于运行 git fetch ，接着是 git rebase 。这会尝试快速转发到新的上游提交，但如果这不可行，那么它会将您的本地提交重新定位到新的上游提交。这通常是可以的，但要小心：

• 重新分配是一个高级主题，您应该了解重新分配之前的含义。


• git pull --rebase 并没有给你提供在合并之前检查提交的机会。根据上游改变的情况，rebase很可能是错误的操作 - rebase - ， merge ， reset 或 push -f 可能比普通的 rebase

• 不能（现在）将 - preserve-merges 传递给rebase操作，所以任何有意的合并功能分支将被线性化，重放（并因此复制）所有功能分支提交。


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

如果您尚未推送由<$ c $创建的合并提交c> git pull ，你可以拼出合并提交。假设你没有进行任何有意的合并（例如，将一个已经推送过的特性分支合并到你当前的分支中），下面应该做到这一点：

  git rebase @ {u} 
  

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

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

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?

Thanks,
~J

解决方案

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

How to avoid these merge commits in the future

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

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 -p downloads 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 -p argument prunes deleted upstream branches. Thus, if the foo branch is deleted in the origin repository, git remote update -p will automatically delete your origin/foo ref.

• 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 -p option 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 master as part of the linearization done by git rebase. This would make the development history harder to review, not easier.

  Beware: git rebase might 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}..
  

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

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.

Why not git pull --rebase?

Running git pull --rebase is equivalent to running git fetch followed 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:

• Rebase is an advanced topic, and you should understand the implications before rebasing.
• git pull --rebase does 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 -f might be more appropriate than a plain rebase.
• It is not (currently) possible to pass --preserve-merges to the rebase operation, so any intentional merge of a feature branch will be linearized, replaying (and thus duplicating) all of the feature branch commits.

"Fixing" an existing merge commit created by 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 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/master if HEAD is 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.

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 up and avoid git pull altogether. You'll probably have to use reset to undo the merge created by pull and then do git rebase -p @{u}. The -p argument to git rebase hasn't worked reliably for me, so you might end up having to use reset to 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).

这篇关于为什么我将“远程追踪分支”的起源/开发合并为“开发”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！