我们找到了“问题”......现在是历史记录，滚动到底部以找到解决方案（某种程度）。
所以，我们希望有一个线性历史的便利master并保留提交历史develop.
这导致develop推进WRTmaster无限期地这样master“永远”赶不上develop（在提交历史的意义上）。当从以下位置打开 PR 时develop你会得到这个巨大的提交列表（同样，更改的文件数量是正确的，所以没有真正的问题）。这是 GUI 的不便之处。
结果图是这样的（在测试存储库上）
绿线从master是一个修补程序，已合并回develop在创建新的 PR 之前。其他线路源于develop是特征。
对于感兴趣的各方，工作流程如下：
Feature:
$ git checkout -b new-feature develop
... work, commit, work, commit
$ git rebase develop
$ git checkout develop
$ git merge --no-ff new feature
$ git push develop
$ git branch -d new-feature
发布（从开发提示或准备发布的最后一次提交开始）
$ git checkout -b release/x.y.z (develop|045c89)
... work, commit, work, commit
$ git tag -a x.y.z -m "new release x.y.z"
$ git checkout develop
$ git merge release/x.y.z
$ git push --follow-tags develop
$ git branch -d release/x.y.z
然后我们在 github 上打开一个 PRdevelop并将其压入master。它可能来自release我想也是如此。
回到我们的本地，我们从原点拉/取并合并master into develop。此步骤是必要的，否则我们会在下一个 PR 中得到“无法自动合并”的信息。
修补程序与版本相同，但源于主版本。
当然也可以直接pushmaster发布/修补程序后，执行以下操作：
$ git checkout master
$ git merge --squash x.y.z
... commit with something like "version x.y.z"
$ git push
这样github上线性历史的分支保护就不会抱怨。
这是 github 上的 PR 的屏幕截图...实际上只更改了 4 个文件。这些更改的实际提交是庞大列表中的最后 3 个。其他的都是之前的:(
解决方案（某种程度上）：
PR合并后，本地做：
$ git checkout master
$ git pull
$ git checkout -B develop
$ git push --force origin HEAD
这将重置develop以便两者master and develop将会是均匀的。我们失去了历史develop但我们没有大量的“提交”列表。这让我想知道为什么我们需要develop首先，我们可以迁移到 github 流程的“主干”工作流程。
