Reviewing and managing merge requests

Reviewing and managing merge requests

合并请求是在 GitLab 项目中更改文件的主要方法. 通过创建并提交合并请求来提出更改，然后将其审核并接受（或拒绝）.

导航到” 项目”>”合并请求”，以查看项目中的所有合并请求 .

当您访问项目的合并请求时，GitLab 会将它们显示在列表中，并且您可以使用可用的选项卡来快速按打开和关闭进行过滤. 您还可以 .

View merge requests for all projects in a group

查看组中所有项目中的合并请求，包括组中所有后代子组的所有项目. 导航到组>合并请求以查看这些合并请求. 该视图还具有打开和关闭的合并请求选项卡.

您可以从此处搜索和过滤结果 .

Semi-linear history merge requests

将为每个合并创建一个合并提交，但是只有在可能进行快速合并的情况下才合并分支. 这样可以确保如果合并请求构建成功，则合并后目标分支构建也将成功.

导航到项目的设置，在” 合并请求：合并”方法下选择” 使用半线性历史 合并合并”选项，然后保存更改.

更改选项卡位于主要合并请求详细信息下方，并且在讨论选项卡旁边，显示了分支或提交之间文件的更改. 这种对文件更改的视图也称为diff . 默认情况下，差异视图将合并请求分支中的文件与目标分支中的文件进行比较.

The diff view includes the following:

  • 文件的名称和路径.
  • 添加和删​​除的行数.
  • 用于以下选项的按钮：
    • 切换此文件的注释； 用于内联评论.
    • 在合并请求的分支中编辑文件.
    • 显示完整文件，以防您要查看上下文中文件其余部分的更改.
    • 在当前提交时查看文件.
    • 使用预览更改.

在” 更改”选项卡中查看更改时，可以使用文件树或文件列表来浏览差异. 在具有许多更改的大型差异中滚动时，可以使用文件树或文件列表快速跳转到任何更改的文件.

File-by-file diff navigation

版本历史

  • 在 GitLab 13.2 中 .
  • 它部署在默认情况下启用的功能标志后面.
  • 建议用于生产.
  • 在 GitLab.com 上启用了它.
  • 对于 GitLab 自我管理的实例，GitLab 管理员可以选择禁用它 .

对于较大的合并请求，有时一次查看单个文件可能会很有用. 要启用，请从右上角导航栏上的头像，单击“设置” ，然后转到左侧边栏上的“首选项” . 向下滚动到” 行为”部分，然后在合并请求的”更改”标签上选择“一次显示一个文件” . 点击保存更改以应用.

从那里，在查看合并请求的” 更改”选项卡时，一次只能看到一个文件. 然后，您可以单击按钮上一个和下一个以查看其他已更改的文件.

Enable or disable file-by-file diff navigation

逐文件差异导航正在开发中，但已准备好用于生产. 它部署在默认情况下启用的功能标志的后面. 可以选择为您的实例禁用它.

要启用它：

  1. # Instance-wide
  2. Feature.disable(:view_diffs_file_by_file>)

Merge requests commit navigation

in GitLab 13.0.

要在合并请求中的提交之间无缝导航，请从” 提交”选项卡中，单击其中一个提交以打开单提交视图. 从那里，您可以通过单击页面右上角的Prev和Next按钮或使用X和C键盘快捷键在提交之间进行导航.

默认情况下，差异仅显示文件中已更改的部分. 要查看更改上方或下方的更多未更改行，请单击” 向上 扩展”或” 向下扩展”图标. 您也可以单击显示未更改的行以展开整个文件.

Incrementally expand merge request diffs

在 GitLab 13.1 中 ，当查看合并请求的更改选项卡时，如果仅重命名了某个文件，则可以通过单击显示文件内容展开它以查看全部内容 .

Ignore whitespace changes in Merge Request diff view

如果单击” 隐藏空白更改”按钮，则可以看到没有空白更改的差异（如果有的话）. 在特定的提交页面上，这也可以工作.

Perform inline code reviews

在 GitLab 11.5 中 .

GitLab 提供了一种在合并请求中更改文件的任何部分中保留注释的方法. 为此，请在”合并请求”差异 UI 的装订线中单击…按钮以展开差异行并留下评论，就像更改行一样.

Comment on any diff file line

Pipeline status in merge requests widgets

如果您在项目中设置了GitLab CI / CD ，您将能够看到：

  • 合并前和合并后管道以及环境信息（如果有）.
  • 正在进行哪些部署.

如果存在并且已将应用程序成功部署到该环境，则还将显示已部署的环境以及指向 Review App 的链接.

Post-merge pipeline status

合并请求合并后，可以看到合并请求合并到的分支的合并后管道状态. 例如，当合并请求合并到 master 分支中，然后触发到暂存环境的部署时.

将显示正在进行的部署，以及环境的部署/部署状态. 如果是第一次部署分支，则该链接将返回404错误，直到完成. 在部署期间，停止按钮将被禁用. 如果管道无法部署，则部署信息将被隐藏.

有关更多信息，请阅读有关管道 .

设置一个看起来准备合并的合并请求，以 .

Live preview with Review Apps

如果为项目配置了 ，则可以逐分支预览通过合并请求提交给功能分支的更改. 无需检出分支机构，在本地安装和预览； 带有”评论应用”链接的任何人都可以预览所有更改.

设置了 GitLab 的” 路线图”后 ，合并请求小部件会将您直接带到已更改的页面，从而使预览建议的修改变得更加轻松快捷.

还有大量与合并请求关联的功能：

Troubleshooting

有时，合并请求中的操作并没有按预期进行，这是一些故障排除步骤.

Merge request cannot retrieve the pipeline status

如果 Sidekiq 没有足够快地进行更改，则会发生这种情况.

Sidekiq

Sidekiq 没有足够快地处理 CI 状态更改. 请等待几秒钟，状态将自动更新.

Bug

发生以下情况时，无法检索合并请求管道的状态：

  1. 创建合并请求
  2. 合并请求已关闭
  3. 在项目中进行了更改
  4. 合并请求被重新打开

要正确检索管道状态，请再次关闭并重新打开”合并请求”.

Tips

以下是一些技巧，可帮助您在命令行中更有效地处理合并请求.

合并请求包含来自存储库的所有历史记录，以及添加到与合并请求关联的分支的其他提交. 这是一些在本地检出合并请求的技巧.

请注意，即使源项目是目标项目的分支（甚至是私有分支），也可以在本地签出合并请求.

Checkout locally by adding a Git alias

将以下别名添加到~/.gitconfig ：

  1. [alias]

现在，您可以从任何存储库和任何远程签出特定的合并请求. 例如，要从origin远程服务器签出 ID 为 5 的合并请求（如 GitLab 所示），请执行以下操作：

这会将合并请求提取到本地mr-origin-5分支中，并检出它.

Checkout locally by modifying .git/config for a given repository

在.git/config文件中找到适用于 GitLab 遥控器的部分. 看起来像这样：

  1. [remote "origin"]
  2.   url = https://gitlab.com/gitlab-org/gitlab-foss.git
  3.   fetch = +refs/heads/*:refs/remotes/origin/*

您可以使用以下方式打开文件：

  1. git config -e

现在，将以下行添加到上面的部分：

最后，它应如下所示：

  1. [remote "origin"]
  3.   fetch = +refs/heads/*:refs/remotes/origin/*
  4.   fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

现在，您可以获取所有合并请求：

  1. git fetch origin
  3. ...
  4. From https://gitlab.com/gitlab-org/gitlab-foss.git
  5.  * [new ref]         refs/merge-requests/1/head -> origin/merge-requests/1
  6. ...

并检查特定的合并请求：

以上所有操作均可通过脚本完成.