我想知道，在这种情况下合并期间选择提交的优先级是什么，如下所述。
我有develop分支。
D1 - D2 - D3
然后我release从中创建了分支并添加了一些提交。
D1 - D2 - D3 - R4 - R5
同时添加了一些开发提交
D1 - D2 - D3 - D6
release然后，我使用以下命令从分支中删除一些提交git rebase -i HEAD~3：
D1 - x - x - R4 - R5
release分支将如何合并到developusing git merge --no-ff release？我想要这样：
D1 - D2 - D3 - R4 - R5 - D6
是否有可能我会通过提交删除获得合并分支？
D1 - x - x - R4 - R5 - D6
我期待着关于“幕后”的解释:)
如果你做了 a revertinrelease它会在合并时恢复这些提交。如果你做了rebase它不会。那是因为revert显示您明确删除它们，并在历史记录中保留该事实。 rebase看起来这些提交从未发生在 中release，因此没有理由merge删除它们。
就优先级而言，两个分支无论如何都具有相同的优先级。回到分支共同的最后一次提交，如果每个分支以不同的方式更改某些内容，git 会将其显示为合并冲突。rebase不恢复这些提交的唯一原因是因为您重写了历史记录以使其看起来好像它们从一开始就从未出现在分支中。
顺便说一句，您确实意识到您可以在 git 中测试这些东西，无论是在克隆中还是通过小心您的分支，可能比提出问题所需的时间还短？
作为其他答案的补充：
我想知道，在这种情况下合并期间选择提交的优先级是什么
Git 通常在合并期间没有“优先级”的概念。在合并期间，所有分支都同等重要，Git 会尝试合并来自所有分支的更改。
如果存在矛盾（例如不同的分支以不同的方式更改同一行），Git 不会以某种方式让一个分支“获胜”，而是会报告合并冲突。
这实际上是一个深思熟虑的设计决定。Linux 谈论在 Git 中合并：
Linus：就我个人而言，我想要一些可重复且不聪明的东西。我理解或告诉我它做不到的事情。
http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
因此，Git 故意不以某种方式巧妙地尝试找出哪个分支“更重要”——它只是将决定权留给了用户。
你似乎知道git-rebase，所以：
$ git checkout develop
$ git rebase -i D1 release
交互模式让您可以按照自己的方式选择和重新排序提交。