作为前言，我想说 git-flow 将解决其中一些问题。我更愿意坚持使用 GitHub PR 来处理功能分支和修补程序分支。我也更喜欢对功能分支进行 rebase 。我遵循这样的原则:每次提交都应该有一套完整的通过测试。如果您 merge 上游提交，则无法保证所有提交都会通过测试，而无需在每次提交上重新运行测试。
我有分支 PROD 和 DEV。 PROD 应该始终位于 DEV 的上游。如果我有需要进行 PROD 的修复，我会这样做:
- 从 PROD 分支并创建修复 -> 提交 X
- 将 X merge 到 PROD 中，并使用
git tag ...发布一个新标签(与 GitHub PR merge ，以便可以审核修复结果) - 从 DEV && gitcherry-pick X 分支然后 PR 到 DEV(无需在此处发布新标签)
现在问题出现在最后一步。如果我忘记了最后一步怎么办？我如何检查 X'(精心挑选的提交)是否在 DEV 上？保持 PROD 和 Dev 最新的最佳方法是什么，或者至少看看它们是否与樱桃选择不同？
我已经尝试过 git log --cherry-pick DEV..PROD，但提交 X 仍然显示。
This article提供了一些不错的选择，但我正在尝试解决我必须挑选而不是维护另一个分支的情况。
最佳答案
我找到了我自己问题的答案。显然，这是一个见仁见智的问题，因为有很多潜在的解决方案，但这是我的:
我现在使用git tags卡住我的 PROD 分支。对于每个新版本，我都会使用新的 git 标签更新代码库的次要版本。如果我发现上游标签上存在需要修复的错误，我会对 DEV(领先分支)进行更改，然后挑选对 PROD 的所有更改。例如:
$ git checkout DEV && git checkout -b HOTFIX
$ # commit the changes
$ git checkout PROD # HEAD is at v1.2.0
$ git cherry-pick ..HOTFIX
$ git tag v1.2.1
上面是我所做的简单版本，没有考虑 GitHub。
相反，我对 GitHub 所做的是使用 Jenkins和 ghprb plugin将 HOTFIX 分支 PR 到 PROD，然后从 Jenkins 运行发布脚本。每当我 PR PROD 时，都会运行另一个作业来将 PROD 与开发进行比较，如下所示:
$ git log --cherry-pick --no-merges --right-only DEV...PROD
如果出现任何差异，我会发送通知(我使用 Slack plugin ，但我确信您可以使用其他同样有效的东西)。
就是这样!实际上，设置一切非常简单。如果您(读者)发现我正在做的事情有任何缺陷，请发表评论，不仅这样我可以修复我的答案，还可以修复我的实际设置!
关于git - 在 GitHub 上使用 Git 维护多个应用程序版本，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48408925/