关于程序员:Git进阶系列-3-基于Pull-Request实现更好的协作

1次阅读

共计 2393 个字符，预计需要花费 6 分钟才能阅读完成。

Git 是最风行的代码版本控制系统，这一系列文章介绍了一些 Git 的高阶应用形式，从而帮忙咱们能够更好的利用 Git 的能力。本系列一共 8 篇文章，这是第 3 篇。原文：Better Collaboration With Pull Requests^[1]

本文是“Git 进阶系列”的第三篇，将介绍 pull request 这一对大型和小型开发团队都很有帮忙的超棒个性。Pull request 不仅改良了评审和反馈过程，还有助于跟踪和探讨代码变更。最初重要的一点是，pull request 是向其余没有写访问权限的代码库奉献内容的现实形式。

Git 进阶系列:

创立完满的提交

Git 中的分支策略

基于 Pull Request 实现更好的合作（本文）

合并抵触

Rebase vs Merge

交互式 Rebase

Git 中的 Cherry-pick 提交

用 Reflog 复原失落的提交

首先须要晓得，pull request 不是 Git 外围个性。相同，是由应用的 Git 托管平台提供的，GitHub、GitLab、Bitbucket、AzureDevops 以及其余平台都提供相似的内置性能。

在咱们探讨如何创立完满的 pull request 的细节之前，先来讨论一下为什么须要这个个性。

假如咱们刚刚实现软件的一个新个性，兴许之前始终在个性分支中工作，因而下一步将是将其合并到主线分支 (master 分支或 main 分支)。在某些状况下，比方说你是我的项目中惟一的开发人员，或者有足够的教训并确定团队成员不会提出异议，那么间接合并一点问题都没有。

不过如果代码变更略微简单一点，并且心愿其他人可能查看这部分工作，该怎么办呢？这就是 pull request 的目标。有了 pull request，能够邀请其他人来评论所作的工作并给出反馈。

一旦创立了 pull request，就能够和其余开发人员探讨相干代码。大多数 Git 托管平台容许其余用户在此过程中增加评论以及提出倡议，当评审人员批准后，就能够将其合并到另一个分支中。

评审工作流并不是创立 pull request 的惟一起因。如果想对其余没有写访问权限的代码库做出奉献，用 pull request 就会很不便。想想所有的开源我的项目，如果你有一个新个性的想法，或者如果想提交一个补丁，pull request 是一个很好的形式来展现想法，而不用退出这个我的项目并成为次要贡献者。

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

fork 是现有 Git 代码库的集体正本。回到之前对于开源的示例，第一步是创立原始代码库的正本（fork），之后就能够在本人的集体正本中更改代码。

一旦实现，就能够创立一个 pull request，要求原始代码库的维护者采纳你的更改。维护者或其余次要贡献者能够查看相干代码，而后决定是否采纳。

重要提醒: Pull request 总是基于分支，而不是单个提交！创立 pull request 时，须要基于一个特定的分支并申请采纳。

如前所述，pull request 并不是 Git 的外围个性。相同，每个 Git 平台都有本人的设计以及对于 pull request 如何工作的想法。这些设计在 GitLab, GitHub, Bitbucket 等平台上看起来都不太一样，每个平台都有稍微不同的工作流，用于跟踪、探讨和审查更改。

无论应用什么代码托管服务，Tower Git 客户端这样的桌面 GUI 可能提供统一的用户界面，让这所有都变得更容易。

尽管如此，个别的工作流程都差不多，包含以下步骤:

如果你没有对代码库的写权限，第一步是创立一个 fork，也就是集体版本的代码库。
在 fork 的代码库中创立新的本地分支。(提醒: pull request 是基于分支的，而不是提交!)
在本地分支中进行变更并提交。
将变更推送到本人的近程代码库。
创立一个蕴含相干变更的 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/

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。\
微信公众号：DeepNoMind

本文由 mdnice 多平台公布

正文完