【问题标题】：Github pull request issueGithub 拉取请求问题
【发布时间】：2016-10-13 07:44:33
【问题描述】：

我有以下场景：

我的 Github 默认分支是“develop”
我有三个“开发”分支的拉取请求
3 个拉取请求已构建并验证正常（通过 CI 服务器）
然后手动将一个拉取请求合并到“开发”。 '$ bumpversion --commit dev' 会自动执行，并且版本会被构建和发布。因此，所有包含版本的文件都会在“develop”上更改（.bumpversion.cfg，module/__init__.py）
到目前为止一切顺利。现在，由于“开发”中的更改，剩余的两个拉取请求变得无效，不能再通过 Github GUI 合并。我需要检查分支并与@Anirudha 详细描述的“开发”合并。
我不希望我的拉取请求因更改这两个文件而变得无效

我确信解决方案对于知道如何解决此问题的 git 专家来说是显而易见的。暂时没找到，求分享。

【问题讨论】：

按照我下面的建议联系公关作者并要求他/她重新站在他/她的一边有什么问题？
阅读我的新分析器。看看它是否适合作为您问题的答案。（如果不告诉我）

标签： git github

【解决方案1】：

您需要做的就是，checkout 处理这些拉取请求：git checkout PR1

pull develop 分支的最新变化。 git pull origin develop

查看您的相应更改。并推送到您各自的 PR。 git remote PR 会随着新的变化而更新，您的 CI 也会相应地批准。

【讨论】：

你所描述的正是我想要避免的。如果有 n 个拉取请求，我将不得不这样做 fac(n) 次。
在这种情况下有 2 个选项： 1. 删除版本信息，它会合并而不会失败（不推荐，因为这意味着你会失去哪个 git 的本质是基于）。 2. 还原开发分支上的更改，合并所有打开的 PR，然后在开发分支上重做更改（也不推荐，因为它会在您的更改上来回改变您的开发分支。）合并单个分支是更清洁，并保持你的 git 树完好无损。

【解决方案2】：

我建议你为这种情况做一个git rebase。

Git Rebase Official Doc

它的作用是，在执行 rebase 时结帐到您指定的分支，假设您有 pr#2 和 pr#3 待处理，您克隆 repo 并在生成 PR 的分支中执行，

git rebase develop

它会说rebase in prgress，所以，你去解决那个过程中的冲突，然后做一个

git add

现在，如果没有更多冲突，rebase 要么继续，要么停止。如果你有，你可以在终端中读取状态，继续，

git rebase --continue

现在，直到所有冲突都解决为止。

最后，当您结帐到该 PR 的分支时，您应该看到没有冲突，并且可以自动合并分支（显然通过推送到远程仓库）。

现在，对 pr#3 重复相同的过程，就完成了。

总之，

git rebase develop
git add <files>
git rebase --continue

对 pr#3 也重复此操作。

【讨论】：

【解决方案3】：

您应该考虑删除代码中的版本信息，并且仅在您真正发布或部署应用程序时才注入它。

这样您的源代码就不会因为版本的不断变化而变脏。

当然，您希望 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

在发布时，您可以通过以下任一方式计算您的版本：

总结：2.1.3
或较大更改后重置：2.0.2 (Proper semver)

警告

第二个选项：重要的是您接受拉取请求的顺序。（可能导致不同的版本号）
也许 git 仍然希望合并相同的行（而不是在彼此下方添加它们），这仍然会导致冲突。

优势

再也不用担心正确的版本号
开箱即用的发行说明

解决冲突

而不是将所有版本说明放在一个文件中：让人们按照以下语法为每个文件编写版本说明：[yyyy-mm-dd] [1.0.0.0(semVerFix)] [关于更改的信息说明/修复]

/\ 问题是，如果您在较旧的请求之前接受较新的拉取请求并且同时开始继续集成，则版本控制最终可能会出错。

最终解决方案

在您的 git 存储库中。

有一个名为 `/release-notes' 的文件夹

如果有人进行了更改，则必须在此处添加一个文件，说明所做的更改（最好您同时处理一项功能或修复）。

此文件具有以下格式 [日期] [版本更新] [描述]。[可选文件扩展名] 例如：2016-10-26 1.0.0.0 Added new versioning tooling.txt

只要日期和描述是唯一的，您就不会有冲突，当然，除非更改的代码包含冲突。

你的作业：制作读取这些文件并累积版本号的工具。您还可以阅读文件的内容并将其用作发行说明说明。

【讨论】：

这是不可能的，因为我们遵循语义版本控制。我添加了通过合并构建和发布模块的信息，以使其更加清晰。
听起来不像您使用正确的 semVer，因为您自动颠簸版本。更改应表明它是主要功能还是修复。
@mark 通过正确的 semvers 实施查看我的完整答案。我认为这将满足您的需求。缺点是您将不得不稍微更改构建和部署周期。

【解决方案4】：

如果您因为冲突而无法在您的新开发（GitHub proposed recently）上重新定位那些 PR 分支，那么正常的工作流程是：

联系公关作者
要求他/她在获取的更新源/开发之上重新设置 PR 分支，解决冲突，检查一切是否正常
强制推送 PR 分支（这将更新 PR，并将触发 CI 服务器的新一轮构建）

基本上，您需要确保 PR 作者正在做所有艰苦的工作；）当您想要集成该 PR 时，您需要做的就是合并或变基（没有冲突）。

【讨论】：

【解决方案5】：

版本控制应该通过 git 而不是通过存储库中的文件来完成。您可以使用新版本的标签，而不是使用 bumpversion.cfg：

git tag 1.0.0 -m "Optional Description or release name."

并拥有一个变更日志文件，该文件仅由bumpversion 通过累积提交标题进行更改。

Debian 有一个 git 扩展来自动完成这一切：

git dch

编辑：如果您想自动添加版本，您可以有一些约定将增量添加到提交消息中，最好是通过提交挂钩。 git dch 有选项可以指定增加哪个版本。

【讨论】：