github PR 显示每个过去的提交
github PR showing every past commits
我们最近切换了工作流程。我们在 github 上的（新）存储库有 2 个分支：master 和 develop。
master 被保护免于直接推送，只有 PR 被合并。 develop 是所有乐趣发生的地方。
功能分支合并回 develop
git merge --no-ff feat/some_feat
并且发布是从开发中的一些提交或者可能是它的提示中删除的。然后打开 PR，如果一切正常，release 将合并到 master 并将 master 合并到 develop 以避免分离。
现在，我们注意到我们打开的每个 PR，都会在提交中显示曾经进行过的每个提交。更改文件的数量是正确的，但是在几次发布后我们得到了一个巨大的提交列表。
这是为什么？我们在滥用 git 吗？应该是吧。
我们找到了 "problem"...现在是历史，滚动到底部找到解决方案（有点）。
因此，我们希望在 master 上获得线性历史记录，同时保留 develop 上的提交历史记录。
这导致 develop 无限期地推进 WRT master，以便 master "never" 赶上 develop（在提交历史的意义上）。当从 develop 打开一个 PR 时，你会得到这个巨大的提交列表（同样，更改的文件数量是正确的，所以没有真正的问题）。这是 GUI 的不便之处。
结果图是这样的（在测试存储库上）
来自 master 的绿线是一个修补程序，在创建新 PR 之前合并回 develop。来自 develop 的其他行是特征。
相关方的工作流程如下：
特征：
$ 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
然后我们从 develop 在 github 上打开一个 PR 并将其压缩到 master。我想也可能来自 release。
回到我们的本地，我们从原点 pull/fetch 合并 master 到 develop。这一步是必要的，否则我们会在下一个 PR 中得到 'unable to automatically merge'。
修补程序与发行版相同，但源于 master。
当然，可以在 relase/hotfix 之后直接推送到 master，方法是：
$ 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 和 develop 都为偶数。我们失去了 develop 的历史记录，但我们没有 'commits' 的庞大列表。这让我想知道为什么我们首先需要 develop，我们可以迁移到 'trunk' 工作流程到 github 流程。
我们最近切换了工作流程。我们在 github 上的（新）存储库有 2 个分支：master 和 develop。
master 被保护免于直接推送，只有 PR 被合并。 develop 是所有乐趣发生的地方。
功能分支合并回 develop
git merge --no-ff feat/some_feat
并且发布是从开发中的一些提交或者可能是它的提示中删除的。然后打开 PR，如果一切正常，release 将合并到 master 并将 master 合并到 develop 以避免分离。
现在，我们注意到我们打开的每个 PR，都会在提交中显示曾经进行过的每个提交。更改文件的数量是正确的，但是在几次发布后我们得到了一个巨大的提交列表。
这是为什么？我们在滥用 git 吗？应该是吧。
我们找到了 "problem"...现在是历史，滚动到底部找到解决方案（有点）。
因此，我们希望在 master 上获得线性历史记录，同时保留 develop 上的提交历史记录。
这导致 develop 无限期地推进 WRT master，以便 master "never" 赶上 develop（在提交历史的意义上）。当从 develop 打开一个 PR 时，你会得到这个巨大的提交列表（同样，更改的文件数量是正确的，所以没有真正的问题）。这是 GUI 的不便之处。
结果图是这样的（在测试存储库上）
来自 master 的绿线是一个修补程序，在创建新 PR 之前合并回 develop。来自 develop 的其他行是特征。
相关方的工作流程如下：
特征：
$ 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
然后我们从 develop 在 github 上打开一个 PR 并将其压缩到 master。我想也可能来自 release。
回到我们的本地，我们从原点 pull/fetch 合并 master 到 develop。这一步是必要的，否则我们会在下一个 PR 中得到 'unable to automatically merge'。
修补程序与发行版相同，但源于 master。
当然，可以在 relase/hotfix 之后直接推送到 master，方法是：
$ 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 和 develop 都为偶数。我们失去了 develop 的历史记录，但我们没有 'commits' 的庞大列表。这让我想知道为什么我们首先需要 develop，我们可以迁移到 'trunk' 工作流程到 github 流程。