git-临时将其他分支合并到我的当前分支

我有个情况。假设两个开发人员在两个不同的分支

A

和

B

上工作

 -- master --
|            |
A     <--    B  

--master--
|            |
A有两种有效的方法来实现这一点：

你做一个完整的，正常的合并。这是最简单的方法，git不管你前后合并多少次，它都能解决问题。这种方法是最诚实的：您的更改取决于在另一个分支中所做的操作，因此这反映在记录的历史中

这种方法的唯一问题是希望在
master
上保留线性历史记录或包含官方开发历史记录的SVN存储库的人（可能具有SVN或类似背景）

你将你的工作重新定位到另一个分支上。有些人喜欢这样做，因为它保留了一个线性历史，并且使与上游SVN存储库的交互更加容易。不利的一面是，你在历史问题上撒谎（请参阅我对另一个SO问题的回答，以了解更多关于为什么这是有问题的细节）。所以，如果您选择重新基址，您应该确保至少编译测试您的新提交

这种方法的另一个缺点是，每次需要利用另一个分支（包括主分支）中的更改来保留线性历史时，都需要重新确定整个工作的基础。并重复测试新的rebase创建的所有新提交

这就是为什么我非常喜欢合并方法：它允许在任何点进行合并，唯一需要测试的新提交是合并提交。我以前的所有提交保持不变，不需要重新测试

假设分支B当前正在提交
abc1234
。对你的问题最直接的回答是

git checkout B
git merge A
# run your tests
git reset --hard abc1234

但正如其他人所提到的，这是一个非常奇怪的工作流。如果B依赖于A，为什么首先要取消合并分支？也许你想要第三个“集成”分支？
你想要什么还不太清楚，但我认为你只想在B的基础上开始一个新的分支C，将a合并到C，然后再处理C。一旦完成，删除C。是的。在测试了C中的更改后，如何放弃合并A。只需删除C（
git branch-dc
）。您仍然会有A和B。Git分支是轻量级的，应该经常创建/删除。或者让C保持在测试状态，在B上工作，并根据需要将B中的其他更改合并到C中（尽量避免在C上进行任何非合并提交，在A或B上完成所有工作，然后合并到C中进行测试）。从ASCII图中，很难看出您的回购处于何种状态。看看更清晰的ASCII提交图示例。我发现这是一个奇怪的工作流。我将B合并到A并开始处理A。感谢您的回复。好吧，我看到这样的场景：如果每个分支代表单独的功能，那么稍后会以某种方式找出一个分支在另一个分支中的依赖关系。然而，您希望在将它们合并到一起之前进行代码审查和任何开发端验证，否则只会造成一个大混乱。