我们最近改变了工作流程。我们在 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 吗?可能是的。
最佳答案
我们找到了“问题”...现在是历史,滚动到底部(某种程度上)找到解决方案。
因此,我们希望在 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 流程的“主干”工作流程。
关于github PR 显示所有过去的提交,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59937999/