如何找到未经过拉取请求推送的提交?

11 浏览
0 Comments

如何找到未经过拉取请求推送的提交?

在我的项目中,要求使用来自功能分支的拉取请求向主分支添加更改。目前,仓库已配置为禁止直接推送到主分支,但过去是允许的。

是否有可能找到直接推送到master的提交,而没有拉取请求?

0
0 Comments

如何找到没有pull request的提交?

在项目中使用的合并策略是什么?是rebase还是merge策略?你是否保留了merge-commit?

我不确定。我可以在哪里检查它?据我所知,我们没有强制要求有合并提交,但通常情况下(如果不是总是),它们会被创建。

合并策略可以在两个层面上设置:在你的git配置中git config --local merge.ff only(有几种方法可以做到这一点,我让你去查看文档),以及在你的代码仓库(github、bitbucket等)中。

还有一件事!你考虑过git branch --contains=A_GIVEN_BRANCH/COMMIT_ID吗?

在BitBucket中,合并策略被设置为默认值,即“Merge commit --no-ff”。每个开发者的本地设置可能是不同的。

对于git branch --contains=...,我尝试过了,但问题是对于git来说,从开始到当前分支指针的历史中的每个提交都被认为包含在该分支中。即使该提交是在分支开始之前创建的。

0
0 Comments

如何找到没有使用拉取请求推送的提交?

问题的原因是拉取请求的第二个父提交是master的合并请求。

如果您保留拉取请求,您可以简单地检查每个合并到master的提交的第二个父提交是否是拉取请求。

Github将拉取请求保留为引用,因此您可以使用git ls-remote u://r/l refs/pull/*/head列出它们,试图在Atlassian的服务上找到相当的方法感觉像在猪油中游泳,所以您需要自己弄清楚。

对于使用Github约定发布拉取请求的存储库,可以使用以下类似的方法:

awk 'ARGIND==1 { prhead[$1]=1; next}

!prhead[$3] { print $0, "was not merged from a pull request" }' \

<(git ls-remote u://r/l refs/pull/*/head)

<(git rev-list --first-parent --merges master --parents)

您可以(毫不意外地)推送存储库设置接受的任何内容,因此在您的限制生效之前,其他人可能已经推送了快速推进。这些将显示为master上的非合并提交:

git rev-list --first-parent --no-merges master

将列出在master上进行的每个提交且未合并的提交。

0
0 Comments

如何找到未经Pull Request推送的提交?

这相当于从主分支中删除所有属于PR的提交。我可以提供一种手动方法,虽然不太高效,但可能还可以接受:

1)从主分支创建一个临时副本进行操作

git checkout -b master-sandbox

2)找到一个PR的所有提交哈希(可以在在线上找到,例如在Bitbucket的PR请求中复制它们)

3)根据哈希从master-sandbox中删除提交

git rebase -i HEAD~1000

其中HEAD~1000表示最近的1000次提交,或者使用提交哈希,从中进行检查,例如:git rebase -i <hash>。这将在编辑器中打开一个提交列表。找到上面收集的提交哈希并将其删除。

剩下的提交就是不属于PR的提交。

重复上述步骤直到处理完所有PR,剩下的提交就是直接提交的提交。

我不明白这样做有什么帮助。我不想解决任何冲突!

请问你的情况是什么?你能解释一下吗?为什么不简单地合并你的新功能,为什么需要知道哪些是直接提交的更改?提前谢谢。

我的情况是,我负责从“master”分支准备一个新的发布版本。我希望确保所有的更改都已经通过了代码审查。不幸的是,最近禁止了直接推送到主分支,但之前并没有被禁止。

你是使用合并提交还是压缩提交来合并经过审查的PR?这是另一种值得设置的策略。这会使主分支更加透明。

BitBucket被配置为使用合并提交。所以在主分支中有一些合并分支的痕迹。

嗯,在将来,如果没有其他考虑因素,请将压缩提交设置为默认选项。在这种情况下,合并提交将表示主分支上的一个PR,而直接提交的更改(例如快速修复)将保持纯净的提交。对于你当前的情况,我提供了一个不太完美的解决方案...但这可能比没有好。

0