如何在github中讨论pull请求

我有一个小问题，当我的同事或我，当我们不同意一段代码或方式做的事情，在拉请求。我想知道你是如何解决讨论的情况下，审稿人不同意编码器

1） 请购单将不被批准且不会合并

或

2） 编码员不接受审查并拒绝审查。无论如何，代码都将被合并

上下文是指审阅者和请求所有者与 开发者和开发者都是项目的所有者

---

感谢您的意见

让我们假设两个人拥有相同的所有者权限，一个是PR的作者，另一个是审阅者：

测试

首先，如果代码确实解决了所需的问题，那么应该对其进行测试。如果没有，那么就没有必要合并

请求更改

如果代码修复了问题或实现了新功能，那么设计问题就会出现，例如缩进、制表符/空格、愚蠢命名的变量，甚至是原始存储库可能试图保持接近的代码模式/样式指南

代码很好

如果代码在两方面都很好（algo+设计），但仍有人不赞成，那么存在以下问题：

• 代码就是感觉不对
• 不必要的特征
• 内部问题-可能评论人和公关作者彼此不喜欢

如果第三个“阶段”到来，那么在这种情况下，主要需要第三方（具有相同级别的特权）来判断代码

这是一种乌托邦式的想法，认为第三者总能解决这种情况，因此这里有一些结局你应该习惯：

• PR将留待将来解决
• 公共关系将关闭
  欢迎您制作一个fork并开发该特性，毕竟这是git的天性（请参阅），并且将来可能会在一个新的PR中提出该代码

• 公共关系将被合并

---

我非常感谢您的评论，如果有第三个人，这是个好主意。谢谢你的意见。我希望更多的评论人们的经验，如何解决分歧和思维上的差异PRs@Keniako我不是那么积极，因为在我写作的时候，已经有3票赞成结束这个问题，我可能是唯一一个足够关心的人，真正尝试回答这样一个广泛的问题，而这个问题甚至可能与此无关直接，而不是SE的其他部分，例如：）我知道这是一个广泛的问题，但事实是，讨论存在于日常工作中。我之所以提出这个问题，是因为我的团队通常都会遇到这个问题，我需要听听其他团队是如何解决这个问题的。举个例子，拥有第三者是一个简单的想法，但我们从未想到过。我喜欢有更多的评论和想法。但是如果其他人对这个话题不感兴趣或者没有这个问题，我也可以。（即使有人投了反对票，我也能理解）