git merge origin / master和git pull之间的区别 [英] difference between git merge origin/master and git pull

问题描述

我正在开发一个本地分支BDD-local，并希望从其他开发者处获得更改。
其他开发人员正在使用他们自己的分支，一旦他们对单元测试感到满意，他们会将更改推送到远程repo（origin / master）。

我在这里经历了几个帖子并获得了相互矛盾的信息。
很少有人谈论使用：

$ g $ p $ g $ git fetch origin $ b $ git merge origin / master

其他人认为，'git pull'应该会发生变化。

我们的开发人员之一被要求使用'git merge origin / master'而没有'git fetch'。

有谁知道这些选项哪个更好。我在我的本地分支上尝试过'git pull'，但它似乎没有工作。但是，如果我在本地主服务器上执行'git pull'，它就可以正常工作（但是我希望它可以在本地分支上工作）

解决方案

获取，合并和拉取

git fetch 和 git merge origin / master 会取出&整合远程更改。让我解释一个常见的情况。起源/主人在C，有人推D，你从事E& F.请注意，在运行 git fetch 之前，您不会在本地存储库中看到D.

  origin / master 
v 
 ABCEF < master 
 \ 
（D）< master远程
  

现在运行 git fetch 。现在你可以看到D，并且origin / master被更新以匹配它正在跟踪的远程存储库。

  A-B-C-E-F < master 
 \ 
 D <远程
  

现在您运行 git merge ，给你这个：

  ABCEF 
 \\ 
 D --- G< master 
 $ 
 origin / master，master在远程
  

（E，F）上的更改与原始/主（D）上的新提交相结合。

git pull
$ b

git合并而不提取

在没有 git fetch 的情况下运行 git merge origin / master 是毫无意义的。如果没有 git fetch ，您的本地存储库不知道远程存储库上的任何潜在更改，并且origin / master不会移动。所以你处于这种状态，其中D只在远程而不在本地存在：

  origin / master 
v 
 ABCEF< master 
 \ 
（D）< master远程
 $ / code $ 
 
 
 $因为你的本地仓库没有D，所以 git merge 
 
 
 
 已经是最新的。  / p> 
 
 
因为嘿，就您的本地存储库而言，master已经拥有了所有origin / master中的所有内容。 
 
 
 什么是最好的？ 
 
 
 
以上都不是。 ：）
 
 
  git fetch 
 git rebase origin / master master 
  
或者是一个快捷方式， git pull -r ，但是我个人更喜欢在转换之前看到更改。
这将在原始/主（D）顶部重放主（E，F）上的更改，而不会发生意外合并提交。它产生：
 
 
  A-B-C-D-E'-F'< master 
 ^ 
 origin / master，master on remote 
  
请注意，在一行中，您已准备好推送，并且历史看起来不像是一个友情链接。
 
 
 
一个警告 - 不要重新绑定任何已提交的提交推。请注意，E& F成为E'& F'重新绑定后。提交完全重写，新的SHA和一切。如果您重新提交已公开的提交，那么开发人员在他们提交时会重写他们的历史记录。这太可怕了，每个人都会给你邪恶的眼睛，并且会回避你。
 
I'm working on a local branch "BDD-local" and would like to get the changes from other developers. 
The other developers are using their own branch and once they are happy with the unit tests, they push the changes to remote repo (origin/master).

I was going through several posts here and getting conflicting information.
Few people talk about using:
git fetch origin
git merge origin/master
Some others think, 'git pull' should get the changes.

One of our developers asked to use 'git merge origin/master' without the 'git fetch'

Does anyone know which of these options is better. I tried 'git pull' on my local branch but it didn't seem to work. But if I do 'git pull' on local master it works fine (however I want it to work for the local branch)
解决方案
fetch, merge, and pull

git fetch and git merge origin/master will fetch & integrate remote changes.   Let me explain a common scenario.  origin/master is at C.  Someone pushed D.  You worked on E & F.  Note that you will not see D in your local repository until you run git fetch.
   origin/master
    v
A-B-C-E-F < master
     \
     (D) < master on remote
Now you run git fetch.  Now you can see D, and origin/master is updated to match the remote repository that it's tracking.
A-B-C-E-F < master
     \
      D < origin/master, master on remote
Now you run git merge, giving you this:
A-B-C-E-F
     \   \
      D---G < master
      ^
    origin/master, master on remote
So now you've integrated your changes on master (E, F) with the new commits on origin/master (D).

git pull is simply a shortcut for the above steps.

git merge without fetching

Running git merge origin/master without the git fetch is pointless.  Without a git fetch, your local repository is unaware of any potential changes on the remote repository and origin/master will not have moved.  So you're at this state, where D is only on the remote and not present locally:
   origin/master
    v
A-B-C-E-F < master
     \
     (D) < master on remote
Since your local repository does not have D, a git merge origin/master will simply yield:

Already up-to-date.

Because hey, as far as your local repository is concerned, master already has everything in origin/master.

What's best?

None of the above. :)
git fetch
git rebase origin/master master
or a shortcut, git pull -r, but personally I prefer to see the changes before I rebase.

This will replay your changes on master (E, F) on top of origin/master (D) without a yucky merge commit.  It yields:
A-B-C-D-E'-F' < master
      ^
   origin/master, master on remote
Note how everything is in a single line, you're ready to push, and the history doesn't look like a friendship bracelet.

One warning - never rebase any commits that have already been pushed.  Note that E & F became E' & F' after rebasing.  The commits are entirely rewritten, with a new SHA and everything.  If you rebase commits that are already public, developers will have their history re-written for them when they pull.  And that's awful, and everyone will give you evil eyes and shun you.

                        
这篇关于git merge origin / master和git pull之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！