如果你像我一样不想处理归并，你可以执行上面的步骤，除了使用强制而不是归并，因为它会创建一个分散注意力的日志记录:

git checkout email
git reset --hard staging
git push origin email --force

注意:除非你真的不想再在邮件里看到这些东西。

git checkout email
git merge -m "Making email same as staging disregarding any conflicts from email in the process" -s recursive -X theirs staging

你可以使用“ours”合并策略:

$ git checkout staging
$ git merge -s ours email # Merge branches, but use our (=staging) branch head
$ git checkout email
$ git merge staging

编辑2020-07-30:

关于这个问题和可能的解决方案，我想了更多。如果您绝对需要以正确的顺序合并父节点，需要通过单个命令行调用来执行此操作，并且不介意运行管道命令，您可以执行以下操作:

$ git checkout A
$ git merge --ff-only $(git commit-tree -m "Throw away branch 'A'" -p A -p B B^{tree})

这基本上就像(不存在的)合并是他们的战略。 您可以在演示存储库的管道分支中找到生成的历史记录

与-s开关相比，不是很容易读懂，也不是那么容易记住，但它做到了。结果树与分支B相同:

$ git rev-parse A^{tree} B^{tree} HEAD^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44

编辑2020-07-29:

关于-s我们的和-X我们的(后者相当于-s递归——策略选项我们的)之间的区别，似乎有很多困惑。下面是一个小示例，展示使用这两种方法得到的两个结果。我还建议阅读(Git合并)何时使用“我们的”策略，“我们的”选项和“他们的”选项的问题和答案?

首先，设置一个带有2个分支和3个提交的存储库(1个基本提交，每个分支1个提交)。您可以在GitHub上找到示例存储库

$ git init
$ echo 'original' | tee file1 file2 file3
$ git commit -m 'initial commit'
$ git branch A
$ git branch B
$ git checkout A
$ echo 'A' > file1
$ git commit -m 'change on branch A' file1
$ git checkout B
$ echo 'B' > file2
$ git commit -m 'change on branch B' file2

现在，让我们试试策略选项(不管我们用他们的还是我们的来解释):

$ git merge -X ours A
$ cat file*
A
B
original

我们最终合并了两个分支的内容(样本回购中的分支“strategy-option”)。将其与使用合并策略(在执行下一步之前重新初始化存储库或重置分支)进行比较:

$ git merge -s ours A
$ cat file*
original
B
original

结果是完全不同的(示例回购中的分支“merge-strategy”)。使用策略选项，我们得到两个分支的合并结果，使用策略，我们丢弃在另一个分支中发生的任何更改。

你还会注意到merge-strategy创建的提交实际上指向与“our”分支的最新提交完全相同的树，而strategy-option创建了一个新的，以前未见过的树:

$ git rev-parse A^{tree} B^{tree} merge-strategy^{tree} strategy-option^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44
5b09d34a37a183723b409d25268c8cb4d073206e

OP确实要求“我不再需要[…]分支中的旧更改”和“所以我只想将[A]的所有内容转储到[B]中”，这是策略选项不可能做到的。使用“我们的”合并策略是众多可能性中的一种，但可能是最简单的(其他可能性包括使用Git的低级命令，如写树和提交树)。

警告:这将删除电子邮件分支上的所有提交。这就像删除电子邮件分支，并在登台分支的头部重新创建它。

最简单的方法是:

//the branch you want to overwrite
git checkout email 

//reset to the new branch
git reset --hard origin/staging

// push to remote
git push -f

现在电子邮件分支和分期是相同的。

这个分支不会改变原来更新的分支，并让您有机会在最终提交之前进行进一步的修改。

git checkout new -b tmp
git merge -s ours old -m 'irrelevant'
git checkout old
git merge --squash tmp
git branch -D tmp
#do any other stuff you want
git add -A; git commit -m 'foo' #commit (or however you like)

你想要的是这个(实际上与目前接受的答案完全相反):

git checkout email
git merge --strategy-option=theirs staging  

它的作用是:

电子邮件分支文件现在将完全相同的分期分支 电子邮件分支的历史将被保留 分期分支的历史将被添加到电子邮件历史

作为附加价值，如果您不想要所有登台分支的历史记录，您可以使用squash将其总结为一条提交消息。

git checkout email
git merge --squash --strategy-option=theirs staging  
git commit -m "Single commit message for squash branch's history here'

总之，第二个版本所做的是:

电子邮件分支文件现在将完全相同的分期分支 电子邮件分支的历史将被保留 单个提交将被添加到电子邮件分支的历史记录之上。这个提交将表示在暂存分支中发生的所有更改