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

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

git checkout aq
git merge origin/master

对于我来说，我已经进行了更改，我想从基础分支获得最新的更改。我无法做rebase，而选择将花费很长时间，所以我做了以下工作:

git fetch origin <base branch name>  
git merge FETCH_HEAD

在这种情况下:

git fetch origin master  
git merge FETCH_HEAD

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

git checkout aq
git rebase master

这个(从这里)对我很有用:

git checkout aq
git pull origin master
...
git push

引用:

Git pull origin master获取并合并master的内容 分支和你的分支并创建一个合并提交。如果有的话 合并冲突将在此阶段通知您，您必须解决 在继续之前提交合并。当你准备好推你的 本地提交，包括新的合并提交，到远程服务器， 运行git push。

编辑:

我下面的回答记录了一种将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上提交的时间戳和标识，这也不是我想要的。