使用GitHub的GIT拉取请求

旧习惯

我们已经使用git超过一年了。 SCM是从SVN迁移而来的，它拥有所有的历史。 我们的习惯也被迁移了。 我们的流程非常简单： master分支是我们从中部署代码的地方。 在处理要素时，我们创建要素分支。 几个人可以在这个分支上工作。 有些创建私有本地分支。 有些没有。 代码审查是一对一完成的。 一位成员要求另一位成员加入并浏览代码。

向团队介绍拉取请求

最近，在队友“ 拉取请求”概念的帮助下，我介绍了团队。 花费一些时间来掌握方法并看到好处。 但是，我已经开始看到协作，代码质量和编码行为方面的改进。

好处

1. 更好的协作
   当一个人进行更改并要求拉取请求时，整个团队都可以看到更改。 每个人都可以发表评论并发表评论。 在更改合并到主分支之前对其进行讨论。
2. 代码所有权
   每个人都知道更改，任何人都可以检查和评论。 结果是每个人都可以“拥有”代码。 它可以帮助每个团队成员参与编码和检查任何代码。
3. 分支机构
   在合并之前，需要对代码进行额外的修订。 合并功能后可以删除分支（应删除IMHO）。 git历史记录（日志）更加清晰。 （这完全取决于评论的质量）
4. 改善代码质量
   我发现即使在代码审查之前 ，它也可以提高代码质量。 人们知道每个人都可以观看时， 人们不想引入错误的代码。
5. 更好的代码审查
   自项目开始以来，我们一直在进行广泛的代码审查。 但是，正如我上面所解释的，我们是一对一完成的，通常作者会向审阅者解释代码。 在我看来，这样做会错过代码审查的优势。 当作者向审阅者解释材料时，代码审阅的质量降低。 使用拉取请求，如果审阅者不了解某些内容，则意味着代码可能不够干净。 因此，更多的评论和注释，从而使代码更好。
6. 指导
   当长者一对一地对初中进行代码审查时，没有其他人看到它。 对于年长者来说，要向案例展示代码的外观和代码审查的期望更加困难。 （当然，还有其他一些传递方式，例如代码dojos。而且，虽然是一对一的，但也可以成对编程）。 通过在请求请求中评论评论，团队可以了解重要的信息以及如何进行评论。 每个人都可以从其他团队成员的审查中受益。
7. 改善git使用习惯
   当某人与整个团队合作时，他/她可能会写出更好的git注释。 由于没有人希望读取大量的diff行，因此提交会更小，更频繁。 因此，没有人想让团队“沮丧”。 使用拉取请求会强制使用分支，从而改善git历史记录。

异议

其他人可能将此部分称为缺点 。 但是从我的角度来看，更多的是抱怨“为什么我们需要这个？ 我们对目前的情况很满意”

1. 我已经收到太多电子邮件了
   好吧，这是真的。 使用请求请求，我们开始收到更多电子邮件，这很烦人。 噪音太大了。 我可能没有注意到重要的电子邮件。 答案很简单： 如果您是此功能的一部分&