# 为项目编写代码

使用分支、分支、提交和拉取请求安全地编写、优化和建议协作项目的代码更改。

在参与项目时，你需要一个安全的位置来编写和优化代码，然后再影响主代码库。 分支、分支、提交和拉取请求协同工作，为你提供该空间，以便可以试验、以增量方式签入工作，并建议完成的更改以供审阅。

## 使用分支和分支隔离工作

大多数工作首先创建可以自由更改的代码的独立副本。

* 对存储库具有写入访问权限时，请使用 **分支** 。 分支允许你在存储库的包含区域中开发功能、修复 bug 或试验，而不会影响其他分支。 从现有分支（通常是默认分支）创建分支。
* 如果没有写入访问权限，或者希望与原始项目完全独立时，请使用 **分支** 。 分叉是一个单独的存储库，它与原始“上游”存储库共享代码和可见性设置。 它具有自己的分支、问题和拉取请求。 使用分支，还可以打开上游存储库的拉取请求。

在共享存储库中协作时，分支通常是最简单的选择。 分叉通常是开放源代码贡献的最佳选择，你可能没有对上游存储库的写入访问权限。

## 使用提交签入

编写代码时，将小而有意义的更改组保存为 **提交**。 每个提交都会记录你的工作的快照以及描述更改的内容的消息，这使得跟踪历史记录、查看更改以及了解代码是如何演变的更容易的。

在分支或分支上频繁提交可让你：

* 将更大的更改分解为可审阅的步骤。
* 如果试验不起作用，请回滚到早期状态。
* 为审阅者提供有关如何完成最终更改的清晰历史记录。

## 使用拉取请求提出更改

当工作准备好共享时，请打开 **拉取请求** ，建议将更改合并到基分支中。 拉取请求将提交、更改的说明以及审阅者在合并之前需要讨论和评估它的工具。

可以通过创建草稿拉取请求来打开拉取请求，从而在不正式请求评审的情况下共享更改。 当你需要早期反馈或想要针对代码运行自动检查时，这非常有用。

## 使代码保持最新且已优化

当拉取请求处于打开状态时，基分支可以随着其他人合并工作而不断更改。 若要保持更改干净并减少冲突，可以：

* 经常将基分支合并或重新基于分支，以便差异始终专注于更改引入的内容。
  GitHub 默认情况下，显示一个三点差异，它将分支与从基点分离的点进行比较。
* 重新设置基以整理混乱的提交历史记录（重新排序、合并或重新编写提交），然后请求审阅。
* 解决 Git 无法自动合并竞争更改时的合并冲突。

## 在存储库控件中工作

经验丰富的参与者在存储库定义的护栏内工作。 这些控件控制可以推送的位置、谁必须批准你的工作，以及必须在合并之前传递的内容。

* **受保护的分支和规则集** 可以阻止直接推送到重要分支，需要线性历史记录或签名提交，并要求在合并之前进行状态检查或评审。
* 当更改涉及他们拥有的文件时，系统会自动请求**代码所有者**进行评审，因此请计划对敏感区域进行审批。
* **推送规则集** 可以跨分支网络应用，限制每个分叉中的文件路径、大小或名称。
* **预接收挂钩** 允许管理员在 GitHub Enterprise Server 接受提交之前在服务器上强制实施策略检查。

## 集成工具链

拉取请求将代码连接到自动化和服务，帮助快速安全地编写代码。

* **Code scanning** 在 **Dependabot** 更改通过拉取请求移动时，会显示安全问题和易受攻击的依赖项，以便尽早应用安全编码做法。
* **GitHub Actions** 可以在每次推送拉取请求时运行持续集成，自动生成和测试更改。

## 延伸阅读

* [创建拉取请求](/zh/enterprise-server@3.22/pull-requests/how-tos/create-pull-requests/creating-a-pull-request)