github PR显示过去的所有提交

Question

我们最近切换了工作流程。我们在github上的（新）存储库有2个分支：master和develop。

master受保护不受直接推送，只有PR被合并。 develop是所有乐趣的发源地。

功能分支合并回develop

git merge --no-ff feat/some_feat

和发行版是从对开发的某些承诺或它的技巧中删除的。然后打开PR，如果一切正常，release会合并到master中，而master会合并到develop中，以避免分离。

现在，我们注意到打开的每个PR都在提交中显示了曾经进行的每个提交。更改的文件数量是正确的，但是经过几次发布，我们获得了大量提交。

那是为什么？我们滥用git吗？可能是。

Answer 1

我们已经找到了“问题” ...现在，历史记录，滚动到底部找到解决方案（某种）。

因此，我们希望方便地保留graphql上的线性历史记录，并保留master上的提交历史记录。

这将导致develop无限期地推进WRT develop，以使master“从不”赶上master（在提交历史的意义上）。从develop打开PR时，您会看到大量的提交列表（同样，更改的文件数是正确的，因此这里没有真正的问题）。这是GUI的不便。

结果图是这样的（在测试库中）

从develop出来的绿线是一个修补程序，在创建新PR之前，它已合并回到master中。来自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 在github上打开PR，并将其压缩到develop中。我想也可能来自master。

回到本地，我们从原点提取/获取并将release合并到master中。此步骤是必要的，否则在下一个PR中会出现“无法自动合并”的情况。

修补程序与发行版相同，但源于主版本。

当然，可以通过以下操作将发布/修复程序之后直接推送到develop：

master

这样就不会抱怨github上线性历史记录的分支保护。

这是github上PR的屏幕截图...实际上仅更改了4个文件。这些更改的实际提交是巨大列表中的最后3个。所有其他的都是以前的：（

解决方案（某种）：

PR合并后，在本地执行

$ git checkout master
$ git merge --squash x.y.z
... commit with something like "version x.y.z"
$ git push

这将重置$ git checkout master $ git pull $ git checkout -B develop $ git push --force origin HEAD ，以便develop和master都将是偶数。我们丢失了develop上的历史记录，但没有大量的“提交”列表。这让我想知道为什么我们首先需要develop，才能迁移到github flow的“ trunk”工作流程。