Git 进阶系列 | 3. 基于 Pull Request 实现更好的协作

简介: Git 进阶系列 | 3. 基于 Pull Request 实现更好的协作

Git 是最流行的代码版本控制系统,这一系列文章介绍了一些 Git 的高阶使用方式,从而帮助我们可以更好的利用 Git 的能力。本系列一共 8 篇文章,这是第 3 篇。原文:Better Collaboration With Pull Requests[1]


本文是“Git 进阶系列”的第三篇,将介绍 pull request 这一对大型和小型开发团队都很有帮助的超棒特性。Pull request 不仅改进了评审和反馈过程,还有助于跟踪和讨论代码变更。最后重要的一点是,pull request 是向其他没有写访问权限的代码库贡献内容的理想方式。


Git 进阶系列:


  1. 创建完美的提交
  2. Git中的分支策略
  3. 基于Pull Request实现更好的协作(本文)
  4. 合并冲突
  5. Rebase vs Merge
  6. 交互式Rebase
  7. Git中的Cherry-pick提交
  8. 用Reflog恢复丢失的提交


什么是 Pull Request?


首先需要知道,pull request 不是 Git 核心特性。相反,是由使用的 Git 托管平台提供的,GitHub、GitLab、Bitbucket、AzureDevops 以及其他平台都提供类似的内置功能。


为什么需要创建 pull request?


在我们讨论如何创建完美的 pull request 的细节之前,先来讨论一下为什么需要这个特性。


假设我们刚刚完成软件的一个新特性,也许之前一直在特性分支中工作,因此下一步将是将其合并到主线分支(master分支或main分支)。在某些情况下,比方说你是项目中唯一的开发人员,或者有足够的经验并确定团队成员不会提出异议,那么直接合并一点问题都没有。


image.png


不过如果代码变更稍微复杂一点,并且希望其他人能够检查这部分工作,该怎么办呢?这就是 pull request 的目的。有了 pull request,可以邀请其他人来评论所作的工作并给出反馈。


image.png


一旦创建了 pull request,就可以和其他开发人员讨论相关代码。大多数 Git 托管平台允许其他用户在此过程中添加评论以及提出建议,当评审人员批准后,就可以将其合并到另一个分支中。


image.png


评审工作流并不是创建 pull request 的唯一原因。如果想对其他没有写访问权限的代码库做出贡献,用 pull request 就会很方便。想想所有的开源项目,如果你有一个新特性的想法,或者如果想提交一个补丁,pull request 是一个很好的方式来展示想法,而不必加入这个项目并成为主要贡献者。


这就引出了一个与 pull request 紧密相关的话题: fork。


用 fork 工作


fork 是现有 Git 代码库的个人副本。回到之前关于开源的示例,第一步是创建原始代码库的副本(fork),之后就可以在自己的个人副本中更改代码。


image.png


一旦完成,就可以创建一个 pull request,要求原始代码库的维护者采用你的更改。维护者或其他主要贡献者可以检查相关代码,然后决定是否采用。


image.png


重要提示: Pull request 总是基于分支,而不是单个提交!创建 pull request 时,需要基于一个特定的分支并请求采用。


让审阅者的生活更轻松: 如何创建一个优秀的 pull request


如前所述,pull request 并不是 Git 的核心特性。相反,每个 Git 平台都有自己的设计以及关于 pull request 如何工作的想法。这些设计在 GitLab, GitHub, Bitbucket 等平台上看起来都不太一样,每个平台都有略微不同的工作流,用于跟踪、讨论和审查更改。


image.png


无论使用什么代码托管服务,Tower Git 客户端这样的桌面 GUI 能够提供一致的用户界面,让这一切都变得更容易。


d800f1cb7e76ae60b1ccb42b899e2ef2.gif


尽管如此,一般的工作流程都差不多,包括以下步骤:


  1. 如果你没有对代码库的写权限,第一步是创建一个 fork,也就是个人版本的代码库。
  2. 在 fork 的代码库中创建新的本地分支。(提示: pull request 是基于分支的,而不是提交!)
  3. 在本地分支中进行变更并提交。
  4. 将变更推送到自己的远程代码库。
  5. 创建一个包含相关变更的 pull request,开始与他人讨论。


我们看看 pull request 本身,以及如何创建让其他开发人员的生活更轻松的请求。首先应该简短,以便快速审阅,当面对 3000 行代码而不是 30 行代码时,就很难理解代码了。


其次,确保添加良好的、不言自明的标题和有意义的描述。试着描述做了哪些更改,为什么创建 pull request,以及这些更改对项目的影响。大多数平台都允许添加屏幕截图来帮助展示这些变化。


批准、合并还是拒绝?


一旦变更被批准,你(或具有写访问权的人)就可以将分支合并到主分支中。但是,如果审阅者不想在当前状态下合并 pull request,该怎么办?嗯,你可以等会儿,也可以将新的提交推送到那个分支上,这样现有的 pull request 也会更新。


此外,维护者或其他具有写访问权限的人可以在不想合并更改时拒绝 pull request。


开发人员的安全网


如你所见,pull request 是与其他开发人员沟通协作的好方法。通过让其他人检查所作的工作,可以确保只有高质量的代码进入代码库。


如果想更深入了解高级 Git 工具,可以免费查看“Advanced Git Kit[3]”: 这是关于分支策略、交互式 Rebase、Reflog、子模块等主题的短视频集合。


References:

[1] Better Collaboration With Pull Requests: https://css-tricks.com/better-collaboration-with-pull-requests/

目录
相关文章
|
2月前
|
项目管理 开发工具 git
Python面试题:Git版本控制与协作开发
【4月更文挑战第19天】本文聚焦于Python面试中Git版本控制与协作开发的考察点,涵盖Git基础、协作流程及实战示例。面试者需理解仓库、提交、分支等核心概念,掌握常用命令,熟悉主干开发和GitFlow策略。在协作开发中,要掌握Pull Request工作流,有效处理合并冲突,并善用标签与里程碑。注意避免混淆工作区、忽视代码审查和直接在远程分支上工作等常见错误。通过实例展示了如何在GitFlow策略下合并分支和解决冲突,强调持续学习与实践以提升Git技能。
39 1
|
2月前
|
人工智能 数据可视化 开发工具
Git log 进阶用法(含格式化、以及数据过滤)
Git log 进阶用法(含格式化、以及数据过滤)
|
2月前
|
开发工具 git 开发者
Git Pull vs. Git Fetch:深度解析
【2月更文挑战第29天】
934 0
Git Pull vs. Git Fetch:深度解析
|
2月前
|
开发工具 git 开发者
|
2月前
|
存储 前端开发 开发工具
前端开发中的Git版本控制:构建可靠的协作和代码管理
前端开发中的Git版本控制:构建可靠的协作和代码管理
62 0
|
1月前
|
存储 开发工具 git
解决“hint: the same ref. If you want to integrate the remote changes, usehint: ‘git pull‘ before pus”
解决“hint: the same ref. If you want to integrate the remote changes, usehint: ‘git pull‘ before pus”
|
1月前
|
缓存 开发工具 数据安全/隐私保护
mac git命令行操作 git push pull 逻辑
mac git命令行操作 git push pull 逻辑
23 1
|
20天前
|
网络安全 开发工具 数据安全/隐私保护
git pull/push每次都需要输入密码问题
git pull/push每次都需要输入密码问题
28 0
|
21天前
|
存储 开发工具 git
Git工作流程:如何在团队中协作?
Git工作流程:如何在团队中协作?
|
2月前
|
存储 Linux 项目管理
Git管理与协作指南
Git管理与协作指南