您最好的程序员是否应该将其他所有人的代码检入源代码控制中？

svn和git之间的区别之一是控制对存储库的访问的能力。很难将二者进行比较，因为对于完全应该允许谁提交更改的观点存在差异！

这个问题是关于将git用作某个公司的团队的集中存储库。假设团队成员的技能水平各不相同，这与大多数公司中的情况大同小异。

Git似乎假设只有最好的（最有生产力，最有经验的）程序员才能签入代码。如果是这种情况，您将他们的时间花在了编写实际代码以检查其他人的代码以进行检入方面。我真的想将这个问题的重点放在最佳程序员时间的最佳利用上，而不是一般的最佳版本控制实践上。一个必然的结果是，如果优秀的程序员的大部分工作是检查他人的代码，他们会辞职吗？我认为这两个问题都归结为：审查是否值得提高生产力？

由于您的问题尚不清楚，我只想指出，git完全不需要网守工作流程。由于存在大量不受信任的贡献者，因此在开源项目中很受欢迎，但是在组织内部意义不大。您可以根据需要选择允许所有人推送访问。

人们在此分析中忽略的是，优秀的程序员无论如何都要花很多时间与其他程序员的坏代码打交道。如果每个人都具有推入访问权限，则构建将被破坏，并且最好的程序员往往是在事情中断时经常集成和跟踪罪魁祸首的程序员。

每个人都具有推入访问权限的事情是，当发生故障时，每个拉动的人都会得到一个损坏的构建，直到违规的提交被还原或修复。使用关守工作流程时，仅关守会受到影响。换句话说，您只影响一个最好的程序员，而不是所有。

可能会发现您的代码质量相当高，并且关守的成本效益比仍然不值得，但不要忽略熟悉的成本。仅仅因为您已经习惯了生产力下降，并不意味着它不会发生。

另外，不要忘记探索混合选项。使用git可以很容易地设置任何人都可以推送到的存储库，然后让像高级开发人员，测试人员甚至自动连续集成服务器这样的网守来决定是否以及何时将更改更改为另一个更稳定的存储库。这样一来，您就可以充分利用双方的优势。

我的工作是签到仅限于团队负责人（团队负责人无法签入自己的代码）。这是我们执行代码审查的机制，主要是由于许多事件，即使是在门控检入和静态分析周围，错误的提交也进入了代码库。

一方面，它做到了。在它们进入代码库之前，发现了许多错误的提交（并迅速忘记了一个星期左右，直到有人偶然发现了它们）。这样可以减少代码库的中断。另外，我可以推迟一些格式化/结构化的事情，直到它们成为技术债务。在变成bug之前捕获一些bug。这让我对团队的工作感觉很好。

另一方面，当我的3条线变更花了4个小时来提交时，由于不得不追踪另一个线索并让他们进行提交，这导致我自发地陷入了致命的愤怒。它迫使我执行的提交次数比最佳实践少得多，并且偶尔导致尝试跟踪对执行更改的开发人员的更改。

除了在最需要的环境中，我一般不会推荐它。实际上，进行审阅和提交还不错。尽管我自己的过程依赖于其他人的异想天开，但这确实令人生气。如果您不信任开发人员签入代码，请寻求更好的开发人员。

否。任何人都应该能够提交。

如果您在提交错误时遇到问题，这不是错误的源代码管理策略。是开发人员无法确保他/她所做的事情有效。因此，您要做的是针对提交的内容和时间定义明确的准则。

另一个很棒的事情叫做单元测试；）

不过，还有另一种选择。

a）如果使用分布式版本控制，则可以创建一个主存储库，只能向其发出拉取请求。这样，所有开发人员都可以在控制主分支的同时获得自己代码的版本控制。

b）在Subversion和类似版本中，您可以使用分支，每个开发人员都必须创建补丁才能将其放入主分支。

您应该看一下Gerrit之类​​的项目，该项目允许所有开发人员将其代码推送到“审阅”分支，而一旦您的高级/首席开发人员对这些更改感到满意，他们便可以将其推送到master / release。

如果他们不满意，可以在代码行旁留下注释，要求提供更新的补丁程序等。

这样，任何有待更改的人都可以立即将其发布，只有合格的人员（在Gerrit中具有正确的+2特权）才可以将该代码进行测试，然后再投入生产。

不，这是对您最好的才华的不良利用。想象一家出版公司聘用最成功的作者并让他们进行编辑；馊主意。

应该进行代码审查，但这并不意味着它始终是检查JR代码的Sr。最终，应该期望团队中的每个人都达到可以在最少的指导下贡献代码的水平。他们经历了三个信任级别：

1. 无-在签入之前，我想查看每一行代码。
2. 一些-让我知道您在做什么，我会提供反馈
3. 大多数-做好工作，仅在需要时寻求帮助。

释放人才的优势：

• 专注于设计
• 参与建立编码标准和实施策略（无需自己手动完成）
• 解决棘手的编码问题
• 提供指导（无需批准每一行代码）

有一些对管理路径感兴趣的开发人员可能不愿意整天编写代码；别管其他人。

审查值得提高生产力吗？

这取决于团队的“平衡”以及如何设置审核。两者都是管理和团队合作的问题，任何版本控制技术魔术（集中式或分布式）都不会对此产生实质性影响。

如果做错了，生产力的下降当然会扼杀审查的任何好处；答案虽然不是放弃评论的想法，而是找出正确的做法。

找出您的评论是否合格的一种方法是使用问题跟踪工具来跟踪花费在评论上的时间（某些代码审查工具也允许这样做）。如果您发现评论花了很多时间，请花一些精力来找出改善问题的原因和方法。另外，与团队成员定期进行1：1对话以发现代码审查的潜在问题也没有什么害处。

如果团队中的“最佳”程序员被迫花费数小时来挖掘糟糕的编码人员产生的难以理解的垃圾，解决方案是解雇废话制作人，而不是诉诸VCS技术。

• ^{在过去的一个项目中，我被分配来审查由长期表现不佳的团队成员完成的代码更改，在一个组件中，它花了几乎一个小时才能构建和运行测试。我开始阅读差异文档，当我发现无法编译的更改时，我简单地完成了审核，发布了必要的评论，并要求管理层确保进一步的审核请求附带了其代码可编译的书面确认。此后就没有“审核请求”，此人很快就离开了。}

另一方面，当团队保持合理平衡时，代码审查既有趣又具有教育意义。在我之前的项目中，我们要求对代码进行100％的审查，并且既不需要花费时间，也不会分散精力。通过审查发现了一些错误，并且就编码样式和设计选择进行了辩论，但这只是... 正常。

如果代码更改在几天之内被阻止，直到“因为审查”而无法进入质量检查进行测试，则数周后，研究VCS技巧将是解决此问题的最不可能的方法。取而代之的是，最好将他们的精力集中在以如何组织审核过程的方式来发现问题上。

• <sup>-哦，由于审阅者突然生病了，真是太不幸了，这一变更的整合被大大推迟了。
  - 你好！哎呀，你有没有想过让备份审阅者来处理类似的情况？</sup>

是。但是仅当您在谈论分布式源代码控制时。集中化-这取决于。

如果只有几个程序员，那么将花费很少的时间。肯定少于以后消除错误和技术债务所需的修复。

如果程序员很多，您可以将实际的代码审查任务委派给中尉，并让首席开发人员毫无疑问地（几乎）拉动他们的更改。它适用于Linux内核，我认为没有更大的软件项目...

同样，如果项目很小，则主管将很快查看谁提供了良好的代码，以及谁产生了不良的代码。他很快就会看到J.Random编写的优质代码只需要检查体系结构决策，而实习生则编写的不良代码需要在合并之前逐行检查。通过这种方式生成的反馈将减少生产线的维护负担，并为实习生的实际经验提供第一手的经验，并应将其留在公司中。从其他存储git库中提取并合并分支实际上需要一（几）秒，通常读取提交消息的标题将花费更多时间，因此在我知道谁可以信任编写好的代码之后，合并其他人的代码是没有问题的。

代码审查不一定只需要您最好的程序员的注意。海事组织，这应该是非正式的事情。在刚进入生产阶段之前，对于非新手的一段代码，只有第二意见或第二眼。它有助于减轻主要的疏忽，同时还可以帮助人们通过接触其他开发人员的观点来更好地编码为手工艺品。

有点不太令人讨厌的结对编程精简版。换句话说，它不会花很长时间，您也不必等待某人几个小时。您的开发过程中涉及人员等待的任何事情都是浪费金钱，并破坏了IMO的发展势头/士气。

如果代码审查本来是要阻止99.5％的错误首先进入您的代码库的，那么对复杂的版本控制没有真正的意义。就是说，git起初是令人生畏的，但基本的通用用法并不那么复杂，它是高度可配置的。您应该可以停下来几个小时，教大家如何使用它。每个人都承诺。除了最菜鸟的菜鸟之外，所有菜鸟都会进行审查，直到他们在某些方面表现出专业知识为止。

只要“最佳程序员”已经审查了所提交的更改，就应该允许任何人提交代码。能够对存储库实施控制的唯一人员是发布工程师（如果存在）。

就个人而言，如果我必须签入其他人的代码，我会很生气。

您的编辑中的一些输入：不，不应该。评论是必不可少的邪恶，它的弊大于利，好的程序员将对此表示赞赏。也许不愿意参加评论，因为他们不喜欢“小程序员”批评他们的代码的想法。那太糟糕了。如果代码行经常出现错误，他们将更有可能退出，而他们会花时间清理别人的半熟提交。

是的，审查是值得的。如果由于以下原因使审核过程成比例，我不确定是否会对生产率产生影响：

• 它使程序员保持诚实-如果您知道它会受到审查，那么人们会减少捷径
• 它可以帮助新程序员学习更多经验丰富的程序员
• 它有助于转移领域特定的知识
• 审查是可以发现并修复错误和潜在问题的另一扇门

通过不允许所有程序员使用源代码控制，他们将失去跟踪更改，撤消错误以及查看合理的更改历史记录的能力。我不确定您是否只希望您的“最佳”程序员能够签入git。

话虽如此，我认为您有一个负责某些关键分支（例如发布分支）的人是合理的。在这种情况下，我可以想象每个人都可以使用git存储库，但是只有某些人可以合并到release分支中。我不确定是否有办法在git中强制执行此操作，但是应该可以通过进程来执行，并且只需检查是否有人已将其检入即可。

合并到发布分支中可以由“最好的”程序员来完成，也可以由有能力的人员在进行充分的审查后才能完成。

如果优秀的程序员的大部分工作是检查他人的代码，那么他们会辞职吗？

如果他们不喜欢这份工作而被迫参加这项活动，那么可以。这很有可能发生。如今，对于一名优秀的开发人员来说，找到下一份有趣的作品并不是一个很大的挑战。

您最好的程序员是否应该将其他所有人的代码检入源代码控制中？

绝对没有。除了某些关键逻辑必须处于坚如磐石的状态之外，肯定可以浪费他们的时间。

但是，初级或经验不足的开发人员可能应该在试用期上保证代码质量，只是为了安全起见，并确保他们的代码遵循团队开发准则，至少要有几周的时间才能获得提交承诺的特权。