场景:

我从master创建了一个分支，比如branch-1，并将其拉到我的本地。 我的朋友从master创建了一个分支，比如branch-2。 他向master提交了一些代码更改。 现在我想把这些更改从主分支转移到本地分支。

解决方案

git stash // to save all existing changes in local branch
git checkout master // Switch to master branch from branch-1
git pull // take changes from the master
git checkout branch-1 // switchback to your own branch
git rebase master // merge all the changes and move you git head  forward
git stash apply // reapply all you saved changes 

执行“git stash apply”后，您可以在文件中发现冲突。您需要手动修复它，现在您已经准备好执行了。

要么选择相关的提交到分支aq，要么将分支master合并到分支aq。

检查aq分支，并从主基地。

git checkout aq
git rebase master

当你在aq分支上时，你应该能够git合并origin/master。

git checkout aq
git merge origin/master

编辑:

我下面的回答记录了一种将master合并到aq的方法，如果您查看合并的详细信息，它会列出在合并之前在aq上所做的更改，而不是在master上所做的更改。我已经意识到这可能不是你想要的，即使你认为它是!

只是:

git checkout aq
git merge master

很好。

是的，这个简单的合并将显示从master到aq的更改，而不是相反;但这没关系——因为这确实发生了!稍后，当您最终将分支合并到master时，也就是当merge最终显示您对master所做的所有更改时(这正是您想要的，并且是人们无论如何都希望找到该信息的提交)。

I've checked and the approach below also shows exactly the same changes (all the changes made on aq since the original split between aq and master) as the normal approach above, when you finally merge everything back to master. So I think its only real disadvantage (apart from being over-complex and non-standard... :-/ ) is that if you wind back n recent changes with git reset --hard HEAD~<n> and this goes past the merge, then the version below rolls back down the 'wrong' branch, which you have to fix up by hand (e.g. with git reflog & git reset --hard [sha]).

[所以，我之前的想法是:]

有一个问题:

git checkout aq
git merge master

因为合并提交中显示的更改(例如，如果你现在或以后在Github, Bitbucket或你最喜欢的本地git历史查看器中查看)是在master上所做的更改，这可能不是你想要的。

另一方面

git checkout master
git merge aq

显示在aq中所做的更改，这可能是您想要的。(或者，至少，这经常是我想要的!)但是显示正确更改的合并在错误的分支上!

如何应对?!

完整的过程，以一个合并提交结束，显示在aq上所做的更改(根据上面的第二次合并)，但合并影响到aq分支，是:

git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq

这:合并aq到主，快进，同样的合并到aq，撤销它在主，并把你回到aq再次!

我觉得我错过了一些东西——这似乎是你显然想要的东西，而且是很难做到的事情。

另外，rebase也不是等价的。它丢失了在aq上提交的时间戳和标识，这也不是我想要的。

不能保证主错误修复不在其他提交中，因此不能简单地合并。做

git checkout aq
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
...

假设这些提交代表bug修复。

但是从现在开始，将错误修复放在一个单独的分支中。你就可以

git merge hotfixes

当你想要将它们全部滚动到常规开发分支时。