标签: pull-request

我想审查全新的代码。但是，我无法创建拉取请求，也无法添加评论。

github 是否支持仅检查现有存储库更改的代码？如果它是仅在 master 上构建的新存储库怎么办？有人可以通过 Github 获得全新存储库的代码审查并让其他人对其发表评论吗？

底线：

我想将一个拉取请求分成两个具有不同文件子集的较小拉取请求。我不想按提交拆分，我想按文件拆分。

细节：

假设我有一个分支branch_1 （master分支之外），我在其中修改了 2 个文件：file_1和file_2. 假设这些文件在一次或多次提交中一起修改（更改不能通过提交分开），并且假设这些文件没有以任何方式相互引用。

一段时间后，我想合并branch_1到master，但决定只file_1准备合并。我file_2以后可能会合并，所以我把它放在一个新的分支上。

所以我创建了一个branch_2off of branch_1. branch_2现在包含对file_1和的更改file_2。没关系，因为无论如何branch_2都会合并branch_1。

现在，我怎样才能很好地恢复branch_1以删除对 的更改file_2？

如果我只是去branch_1和git checkout master file_2，它的工作原理，但是：当我合并branch_1到master，然后master进入branch_2，那么它会删除file_2。这根本不是我想要的！

基本上我想让它就好像file_2从来没有存在过一样branch_1。

我在 Azure DevOps 中的 Pull Request 构建期间有一个自定义构建步骤，该步骤在某些情况下会失败。

我想通过提出 PR 评论来进一步扩展它，类似于 GitHub 中的这种事情：https : //developer.github.com/v3/issues/comments/#create-a-comment

我没有要在此处添加的代码示例，因为我找不到可用于构建的有用示例。我将 PowerShell 用于我的自定义构建步骤 - 在运行我的分支的 PR 构建时如何实现这一点？

我有一个案例，Github repo master 当前有一系列单独的拉取请求，这些请求已经合并到 master 中。我想恢复说最后 20 个拉取请求合并，但从命令行执行并保留历史记录。

类似的问题被标记为重复恢复多个合并

然而，已经存在的答案并没有真正解决当您想要恢复的所有内容都来自一系列全部合并的拉取请求时会发生什么的具体问题。将 -m 选项与 git revert 一起使用对于一次合并来说是有好处的，对吗？所以我认为答案是没有一个好的方法（从命令行）来快速恢复一系列已合并的单独拉取请求并保留历史记录？如果我对此有误，请纠正我。如果我必须一次执行一项操作，我不妨使用 Github 控制台，然后单击每一项的“还原”。

设置

主分支策略：推送新更改时：重置所有批准投票

• 创建从 dev 分支到 master 分支的拉取请求 (PR1)
• VSTS 执行策略检查。

• 在用户能够完成 PR1 之前，另一个 PR (PR2) 已完成并合并到 master。

问题/问题 PR1 状态仍然显示“无合并冲突/上次检查 # 分钟前”；但是，由于更新了目标（主）分支，情况可能不再如此。如果用户在本地执行合并（将 master (PR2) 合并到 dev）并推送新合并的代码，则投票会重置。现在用户必须再次等待评论。

有没有办法在 PR 中手动触发合并冲突检查，或者在用户推送新更改时不重置投票，但这些更改只是“从 master 合并”。

每当主分支更新时，我希望所有打开的拉取请求都显示更新分支的选项，如下所示。我怎么做？

我有一个 github 单一存储库（mono repo），如下所示：

 /
  - .github
  - docs
  - web
  - mobile

问题：

我想仅为web但不为其他文件夹创建拉取请求模板。github上可以实现吗？

我的pull_request_template.md：

<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

## Web checklist

我使用 git-flow 并根据 Github 保护规则我有分支master和develop受保护，两者都带有选项Require linear history。

一切正常，但现在我想不只是从develop到合并master，而是开始使用“拉取请求”( develop -- PR --> master) 我想知道是否可以在保持历史线性的同时保持分支均匀/同步，而不需要对develop树枝施加力。

目前，如果我PR从developto创建一个拉取请求master，并且因为Require linear history选中了该选项，我无法合并，但只是squash and merge因为rebase and merge这样，如果我修改develop分支并进行另一次提交，它会提前 N 倍，但永远不会是“偶数” 。

我发现报复的唯一develop方法master就是

git pull origin master --rebase

但这随后意味着强制推动：

git push -f

不使用时PR，我只需将开发合并到master（FastForward）并保持历史线性，我可以合并拉取请求并通过禁用来防止强制推送Require linear history，但历史不会是线性的。（我认为 PR 没有使用 FastForward 合并）

我使用 git-flow 的原因是该develop …

我可能有一些昂贵的任务/测试，并且未经审查的 PR 可能需要额外的更改。

我不想为每次提交或微小更改运行这些昂贵的任务，但只有在此类更改经过审查和批准后才运行。

这些任务不仅运行成本昂贵，而且还可能有一些运行配额。迁移到 CI 构建是不可取的，因为这意味着破坏应用程序的代码可能会进入 master，并且需要额外的 PR 来修复。

目前可以在 Azure DevOps 中实现吗？如何？

我正在尝试使用以下属性配置 GitHub 项目：

1. main所有用户 - 包括管理员 - 都需要通过拉取请求提交代码，并且不能直接推送到main
2. 所有用户 - 包括管理员 - 必须等待所有 CI 测试通过才能合并拉取请求
3. 所有用户的拉取请求都必须获得批准，但管理员可以绕过此要求并合并他们自己的拉取请求

我很难同时满足第一个和第三个要求。具体来说，如果我启用“不允许绕过上述设置”设置，那么管理员就无法绕过拉取请求批准。但是，如果我禁用它，那么管理员可以直接推送到main. 有什么办法可以让我鱼与熊掌兼得吗？

以下是我对main分支的完整分支保护设置：