使用拉取请求进行协作
利用拉取请求，可告知其他人你推送到 GitHub 存储库的更改。
拉取请求发送后，感兴趣的各方可评审更改集，讨论潜在的修改，必要时甚至推送后续提交。
拉取请求通常由使用共享存储库模型进行协作的团队和组织使用。
每个人都共享一个存储库，并且使用主题分支来开发功能和隔离更改。
GitHub 上的很多开源项目使用拉取请求来管理参与者所作的更改。
通过这些请求，可将用户所作的更改告知给项目维护人员。
此外，在将更改集合并到主分支之前，发起代码评审并对这些更改进行常规讨论。
拉取请求将对代码的评审和合并组合到一个协作过程中。
当你在分支中修复 bug 或新功能时，会创建一个新的拉取请求。
将团队成员添加到拉取请求中，以便他们可对你所作的更改进行评审和投票。
使用拉取请求评审正在进行的工作，及早获取更改反馈。
所有者可随时放弃拉取请求，因此不保证会合并更改。
让代码得到评审
在拉取请求中完成的代码评审并非只是为了找到 bug，这是测试所关心的。
适当的代码评审可捕获不太明显的问题，这些问题可能会导致在以后产生巨大成本。
代码评审可帮助保护团队免受不良合并和中断生成的影响，这些都会削弱团队的生产力。
评审在合并之前会捕获这些问题，从而阻止对重要分支进行不必要的更改。
通过在代码评审中使用各种审阅者，交叉传播专业知识并传播解决问题的策略。
传播的技能和知识使团队更可靠、更灵活。
提供出色的反馈
高质量评审从高质量反馈开始。 拉取请求中优秀反馈的关键是：
- 让正确的人员评审拉取请求。
- 确保审阅者了解代码的作用。
- 提供可操作、建设性的反馈。
- 立即回复评论。
向拉取请求分配审阅者时，请确保选择了正确的审阅者集。
你希望审阅者了解代码的工作方式，并尽量让在其他领域工作的开发人员参与进来，分享他们的想法。
此外，还有能清楚描述更改的人员，他们可以生成在其中运行修补程序或功能的代码。
审阅者应尝试对其不同意的更改提供反馈。 确定问题并就采取的不同做法提出具体建议。
此反馈有明确的意图，便于拉取请求的所有者了解。
拉取请求的所有者应回复注释、接受建议，或者解释建议的更改不是理想之选的原因。
有时建议很好，但进行的更改不在拉取请求的范围内。
根据这些建议，在拉取请求之外创建新的工作项和功能分支，以进行这些更改。
使用策略保护分支
存储库通常包含一个或多个分支，包括 main，由于它们的关键性，它们需要额外的保护。 Azure Repos 提供了多种基于策略的机制，你应考虑实施这些机制来帮助实现此目标。
这些机制的基本前提是将约束应用于拉取请求。 例如，可以强制实施特定的代码评审策略，例如，在合并拉取请求之前，要求最少从指定评审者处获得一定数量的批准。 利用集体专长时，必将提高代码更改的质量和可靠性。
此外，请考虑实施“检查链接的工作项”策略。 这将验证每个拉取请求是否都链接到工作项，提供上下文并提升可跟踪性。 “检查评论解决”策略有助于确保在合并拉取请求之前解决所有代码评审的评论。
与自动化代码分析、测试和合规性检查相关的策略会在集成之前确认更改是否满足预定义的标准。 限制合并类型有助于维护控制分支历史记录。 例如，可以选择只允许快进和 Squash 合并。
在允许将新代码版本合并到关键分支之前，还可以强制对其进行清洁生成。 这将确保合并的更改不会引入生成失败或回归问题。 状态检查可用于根据外部服务生成的信号完成拉取请求。 例如，此类信号可由运行自动测试和代码分析的 Azure Pipelines 生成。
任何配置了所需策略的分支都会自动阻止直接推送，从而有效地强制执行所有更改的拉取请求。 此外，无法删除此类分支。