git从大师拉入开发分支 [英] git pull from master into the development branch

问题描述

我有一个名为dmgr2（development）的分支，我想从主分支（live site）中取出，并将所有更改合并到我的开发分支中。有一个更好的方法吗？
这里是我计划做的事情：

  git checkout dmgr2 
 git pull origin master 
  

这应该将实时更改拉到我的开发分支中，还是我有这个错误？

解决方案

您列出的步骤可行，但有更长的路可以给您更多的选择： b
$ b

  git checkout dmgr2＃让你在分支dmgr2上
 git fetch origin＃让你获得最新的原始数据
 git merge origin / master 
  

fetch 命令可以在 merge ，也就是说，您可以交换抓取和结帐的顺序，因为 fetch 只是转到命名远程（ origin ）并对它说：给我所有你没有的东西，即所有分支上的所有提交。它们被复制到您的存储库中，但是在远程上名为分支的任何分支名为 origin / branch 。

此时您可以使用任何查看器（ git log ， gitk 等）看到你不知道的东西，反之亦然。有时这只对温暖的模糊感觉有用（啊，是的，这实际上就是我想要的），有时它对完全改变策略很有用（哇，我不想要这些东西）。 p>

最后， merge 命令接受给定的提交，您可以将其命名为 origin / master ，并且在执行 merge 时执行任何操作以将该提交及其祖先引入到您所在的任何分支中。您可以插入 - no-ff 或 - ff-only 以防止快进或仅合并如果结果是快进的，如果你喜欢。

当你使用序列时：

  git checkout dmgr2 
 git pull origin master 
  

pull 命令指示git运行 git fetch ，然后将 git合并原点/主。所以这几乎与手动执行两个步骤相同，但是有一些细微的差别可能不会对你太过关注。 （尤其是 fetch 步骤由 pull >仅限于 origin / master ，并且它不会更新您的仓库中的ref： ¹ 任何新的提交只会被特殊的 FETCH_HEAD引用）

如果你使用更明确的 git fetch origin （那么可以随意查看），然后 git merge origin / master 序列，您也可以自带本地的 master 最新与远程，只有一个 fetch 在网络上运行：

  git fetch origin 
 git checkout master 
 git merge --ff-only origin / master 
 git checkout dmgr2 
 git merge --no-ff origin / master 
  

举例。



---

第二部分已经改变 - 我说固定 - 在git 1.8.4中，它现在更新机会性的远程分支引用。 （正如发行说明所述，这是一个故意的设计决定，可以跳过更新，但事实证明更多的人更喜欢git更新它。如果你想要旧的远程分支SHA-1，它默认保存在，因此可以从reflog中恢复，这也启用了新的git 1.9 / 2.0功能来查找上游的rebase。）

I have a branch called dmgr2 (development) and I want to pull from the master branch (live site) and incorporate all the changes into my development branch. is there a better way to do this? here is what I had planned on doing:

 git checkout dmgr2
 git pull origin master

this should pull the live changes into my development branch, or do I have this wrong?

解决方案

The steps you listed will work, but there's a longer way that gives you more options:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

The fetch command can be done at any point before the merge, i.e., you can swap the order of the fetch and the checkout, because fetch just goes over to the named remote (origin) and says to it: "gimme everything you have that I don't", i.e., all commits on all branches. They get copied to your repository, but named origin/branch for any branch named branch on the remote.

At this point you can use any viewer (git log, gitk, etc) to see "what they have" that you don't, and vice versa. Sometimes this is only useful for Warm Fuzzy Feelings ("ah, yes, that is in fact what I want") and sometimes it is useful for changing strategies entirely ("whoa, I don't want THAT stuff yet").

Finally, the merge command takes the given commit, which you can name as origin/master, and does whatever it takes to bring in that commit and its ancestors, to whatever branch you are on when you run the merge. You can insert --no-ff or --ff-only to prevent a fast-forward, or merge only if the result is a fast-forward, if you like.

When you use the sequence:

git checkout dmgr2
git pull origin master

the pull command instructs git to run git fetch, and then the moral equivalent of git merge origin/master. So this is almost the same as doing the two steps by hand, but there are some subtle differences that probably are not too concerning to you. (In particular the fetch step run by pull brings over only origin/master, and it does not update the ref in your repo:¹ any new commits winds up referred-to only by the special FETCH_HEAD reference.)

If you use the more-explicit git fetch origin (then optionally look around) and then git merge origin/master sequence, you can also bring your own local master up to date with the remote, with only one fetch run across the network:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

for instance.

---

¹This second part has been changed—I say "fixed"—in git 1.8.4, which now updates "remote branch" references opportunistically. (It was, as the release notes say, a deliberate design decision to skip the update, but it turns out that more people prefer that git update it. If you want the old remote-branch SHA-1, it defaults to being saved in, and thus recoverable from, the reflog. This also enables a new git 1.9/2.0 feature for finding upstream rebases.)

这篇关于git从大师拉入开发分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！