github PR 显示所有过去的提交

Question

我们最近改变了工作流程。我们在 github 上的(新)存储库有 2 个分支:master 和 develop。

master 不受直接推送的影响，只有 PR 被 merge 。 develop 是所有乐趣发生的地方。

功能分支 merge 回 develop

git merge --no-ff feat/some_feat

并且发布是从开发中的一些提交或者可能是它的提示中删除的。然后打开一个 PR，如果一切正常，release 被 merge 到 master 和 master 到 develop 到避免分离。

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

这是为什么呢？我们在滥用 git 吗？可能是的。

Answer 1

我们找到了“问题”...现在是历史，滚动到底部(某种程度上)找到解决方案。

因此，我们希望在 master 上获得线性历史的便利，同时保留 develop 上的提交历史。

这导致 develop 无限期地推进 WRT master 以便 master “永远” catch develop (在提交历史的意义上)。当从 develop 打开一个 PR 时，你会得到这个巨大的提交列表(同样，更改文件的数量是正确的，所以没有真正的问题)。这是 GUI 的不便之处。

结果图是这样的(在测试库上)

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

回到我们的本地，我们从 origin 中提取/获取并将 master merge 到 develop 中。这一步是必要的，否则我们会在下一个 PR 中得到“无法自动 merge ”。

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

当然，可以通过以下方式在发布/修复后直接推送到 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 merge 后，本地做:

$ git checkout master
$ git pull
$ git checkout -B develop
$ git push --force origin HEAD

这将重置 develop 以便 master 和 develop 将是偶数。我们丢失了 develop 的历史记录，但我们没有大量的“提交”列表。这让我想知道为什么我们首先需要 develop，我们可以迁移到 github 流程的“主干”工作流程。