在参与项目时，你需要一个安全的位置来编写和优化代码，然后再影响主代码库。 分支、分支、提交和拉取请求协同工作，为你提供该空间，以便可以试验、以增量方式签入工作，并建议完成的更改以供审阅。
使用分支和分支隔离工作
大多数工作首先创建可以自由更改的代码的独立副本。
- 对存储库具有写入访问权限时，请使用 分支 。 分支允许你在存储库的包含区域中开发功能、修复 bug 或试验，而不会影响其他分支。 从现有分支（通常是默认分支）创建分支。
- 如果没有写入访问权限，或者希望与原始项目完全独立时，请使用 分支 。 分叉是一个单独的存储库，它与原始“上游”存储库共享代码和可见性设置。 它具有自己的分支、问题和拉取请求。 使用分支，还可以打开上游存储库的拉取请求。
在共享存储库中协作时，分支通常是最简单的选择。 分叉通常是开放源代码贡献的最佳选择，你可能没有对上游存储库的写入访问权限。
使用提交签入
编写代码时，将小而有意义的更改组保存为 提交。 每个提交都会记录你的工作的快照以及描述更改的内容的消息，这使得跟踪历史记录、查看更改以及了解代码是如何演变的更容易的。
在分支或分支上频繁提交可让你：
- 将更大的更改分解为可审阅的步骤。
- 如果试验不起作用，请回滚到早期状态。
- 为审阅者提供有关如何完成最终更改的清晰历史记录。
使用拉取请求提出更改
当工作准备好共享时，请打开 拉取请求 ，建议将更改合并到基分支中。 拉取请求将提交、更改的说明以及审阅者在合并之前需要讨论和评估它的工具。
可以通过创建草稿拉取请求来打开拉取请求，从而在不正式请求评审的情况下共享更改。 当你需要早期反馈或想要针对代码运行自动检查时，这非常有用。
使代码保持最新且已优化
当拉取请求处于打开状态时，基分支可以随着其他人合并工作而不断更改。 若要保持更改干净并减少冲突，可以：
- 经常将基分支合并或重新基于分支，以便差异始终专注于更改引入的内容。 GitHub 默认情况下，显示一个三点差异，它将分支与从基点分离的点进行比较。
- 重新设置基以整理混乱的提交历史记录（重新排序、合并或重新编写提交），然后请求审阅。
- 解决 Git 无法自动合并竞争更改时的合并冲突。
在存储库控件中工作
经验丰富的参与者在存储库定义的护栏内工作。 这些控件控制可以推送的位置、谁必须批准你的工作，以及必须在合并之前传递的内容。
- 受保护的分支和规则集 可以阻止直接推送到重要分支，需要线性历史记录或签名提交，并要求在合并之前进行状态检查或评审。
- 当更改涉及他们拥有的文件时，系统会自动请求代码所有者进行评审，因此请计划对敏感区域进行审批。
- 推送规则集 可以跨分支网络应用，限制每个分叉中的文件路径、大小或名称。
- 预接收挂钩 允许管理员在 GitHub Enterprise Server 接受提交之前在服务器上强制实施策略检查。
集成工具链
拉取请求将代码连接到自动化和服务，帮助快速安全地编写代码。
GitHub Copilot ** 可帮助你编写、调试和优化代码。
- Code scanning 在 Dependabot 更改通过拉取请求移动时，会显示安全问题和易受攻击的依赖项，以便尽早应用安全编码做法。
- GitHub Actions 可以在每次推送拉取请求时运行持续集成，自动生成和测试更改。