编辑:

我下面的回答记录了一种将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将master aquto重置到将保留提交名称的分支上，但如果这是一个远程分支，则不要重置。如果你不关心保留提交名称，你可以得到合并主aq。如果你想保留提交名称，并且它是一个远程分支，git会选择<commit hash>将提交到你的分支。

与aq合并

git checkout master
git pull
git checkout aq
git merge --no-ff master
git push

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

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

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

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

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

git merge hotfixes

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

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

git checkout aq
git rebase master