我有以下情况：
我确信解决方案对于知道如何解决这个问题的git专家来说是显而易见的。到目前为止我找不到它，所以请分享。
答案 0 :(得分：6)
您需要做的就是，结帐对这些拉取请求：git checkout PR1
拉 开发分支的最新更改。 git pull origin develop
查看相应的更改。并推送到各自的公关。 git远程PR会随着新的更改而更新，您的CI也会相应地批准。
答案 1 :(得分：5)
我建议您为此方案执行git rebase。
它的作用是，在执行rebase时检查你指定的分支，假设你有pr＃2和pr＃3挂起，你克隆了repo并在生成PR的分支中做，
git rebase develop
它会告诉你犯罪，所以，你去解决这个过程中的冲突，并做一个
git add
现在，如果没有更多冲突，rebase会继续或停止。如果有，您可以在终端中读取状态，继续，
git rebase --continue
现在，这样做直到所有冲突都得到解决。
最后，当您结帐到PR的分支时，您应该看到没有冲突，并且分支可以自动合并（显然是通过推送到远程仓库）。
现在，对pr＃3重复相同的过程，你就完成了。
总之，
git rebase develop
git add <files>
git rebase --continue
也为pr＃3重复这个。
答案 2 :(得分：4)
您应该考虑删除代码中的版本信息，并在实际发布或部署应用程序时将其注入。
通过这种方式，您的源代码不会因持续版本更改而变脏。
当然，您希望git检查更改并在发生冲突时告诉您。我建议你使用另一种解决方案，这样就不会发生冲突，合并也会变得容易。 （阅读我的整篇文章以获得完整的解决方案）
而不是确定版本具有相对版本号。
我的意思是：有一个带发行说明的文件。每次有人做拉取请求时，他都会在此文件中添加一行。该文件看起来像这样：
1.0.0 Added a major breaking change
0.1.0 Added a feature
0.0.1 Added a bugfix
1.0.0 Another major change
0.0.1 Bugfix
0.0.1 Another bugfix
在发布时，您可以通过以下方式计算您的版本：
不要将所有版本说明放在一个文件中：让人们按照以下语法编写每个文件的版本说明：[yyyy-mm-dd] [1.0.0.0（semVerFix）] [关于更改的信息说明/修复]
/ \问题是，如果您在较旧的拉取请求之前接受较新的拉取请求并且同时继续进行整合，则版本控制可能最终会出错。
在您的git存储库中。
有一个名为`/ release-notes'的文件夹
如果有人进行了更改，则必须在此处添加一个文件，说明所做的更改（最好是同时使用一个功能或修复）。
此文件的格式如下[日期] [版本凹凸] [描述]。[可选文件扩展名]例如：2016-10-26 1.0.0.0 Added new versioning tooling.txt
只要日期和说明是唯一的，您就没有冲突，除非当然更改的代码包含冲突。
你的作业：制作读取这些文件并累积版本号的工具。您还可以阅读文件的内容并将其用作发行说明说明。
答案 3 :(得分：2)
如果因为冲突而无法在新开发项目（GitHub proposed recently）上重新设置PR分支，那么正常的问题是：
基本上，您需要确保PR作者正在进行所有艰苦的工作;）当您想要整合PR时，您需要做的就是合并或变基（没有冲突）。
答案 4 :(得分：1)
版本控制应该通过git完成，而不是通过存储库中的文件完成。而不是使用bumpversion.cfg，您可以使用新版本的标签：
git tag 1.0.0 -m "Optional Description or release name."
并且有一个changelog文件，只能通过累积提交标题来更改bumpversion。
Debian有一个git扩展来自动完成所有这些：
git dch
编辑：如果你想自动添加版本，你可以有一些约定来将增量添加到提交消息，理想情况是通过提交钩子。 git dch可以选择指定要增加的版本。