如何执行良好/更好的源代码控制实践？

我怀疑我专注于错误的问题，因此在介绍我设想的可能次优的解决方案之前，我将首先描述我认为问题所在。

当前情况：
目前，我的同事只有在很长一段时间内才提交他们的代码更改，这些更改分散在整个项目中。我猜这是进步，因为不久前他们只是将.zip存档放在某些网络共享上。尽管如此，合并仍然是一场噩梦-坦白地说，我已经受够了。而且我也厌倦了交谈，解释和乞讨。这只是必须停止-不要让我不断成为“坏人”。

我的解决方案：
由于似乎对这些问题一无所知，并且/或者对这些问题没有兴趣，而且我不能指望任何努力可以持续几天以上……因此，我想让几个小时的颠覆服务器来做这些事情。唠叨。

我的问题：
我是在这里偏离基地还是在看错问题？似乎我缺少了一些东西，而且我认为通过查看解决问题的工具来问错了事情。

我应该在寻找一种工具来解决此问题，还是应该采取什么措施解决此问题？

您正在寻找针对人类问题的技术解决方案。那很少起作用。

这样做的原因是，如果团队成员不接受某些东西（也不理解其含义），而不是遵循规则，他们将试图规避它们。这就是为什么（例如）开发人员应该接受和理解样式规则，而不仅仅是被检查人员强迫遵守的原因。

这是我过去曾经使用或在没有实际机会的情况下想到的一些方法。有些情况可能不适用于您的情况，具体取决于您在团队中的职位（如果您是声誉卓著的团队负责人，那么与您是本科生相比，您有更好的机会来执行您的观点）在您实习期间刚加入团队）。

1. 与您的同事讨论该问题，并解释大型提交的后果。也许他们只是不了解复杂的合并是罕见提交的直接结果，并且比小而频繁的提交会使合并（相对）容易。

   我认识许多程序员，他们只是简单地认为合并总是很复杂。他们每天最多只能进行一次提交，避免使用功能强大的工具（例如Visual Studio的差异和自动合并），并且手工合并的实践不佳（除非“带我而去”而无需进行进一步的差异检查实际上是一个好习惯）。对于他们而言，这与他们无关，并且是合并的固有性质。

2. 给出其他公司正在发生的事情的具体示例（尤其是您的同事非常尊重的公司）。他们可能根本不知道这是一个问题，并确信每个团队每天最多只能提交一次。

   有些人不知道有5-10个成员的团队最多进行50次推入生产，这意味着平均每人每天5-10次提交。他们可能既不知道怎么可能，也不知道为什么有人这样做。

3. 以身作则。做足够小的承诺。如有可能，请做一个简短的演示，以一周的时间并排显示它们和您的合并（我不确定从版本控件中提取这种信息是否容易）。强调他们在合并过程中所犯的最终错误，并将其与您所犯的错误数量（应接近零）进行比较。

4. 适当时使用“我告诉过您”技术。当您看到您的同事因痛苦的合并而受苦时，请大声评论小而频繁的提交会使合并（相对）变得无痛。

5. 说明没有进行提交的最短持续时间。提交甚至可能对应于几秒钟内所做的微小更改。重命名文件，删除过时的注释，纠正错字都是可以立即提交的所有任务。

   程序员不应该害怕进行微小的提交，而应该将许多更改汇总到一个巨大的提交中。

6. 在适当的时候与个人而不是团队合作。如果有人特别拒绝频繁做些小事，请单独与该人交谈，以了解他为什么拒绝这样做。

   他们可能会给出完全正确的理由，可能会给您一些有关团队情况的提示。我听到自己的一些原因：

   • “我的老师/导师告诉我，最好的做法是做每天一个承诺。”这并不让我感到吃惊，给什么我已经从我的老师听到在大学。

   • “我的同事告诉我，我应该减少投入。”在某些团队中，我也被告知，我理解他们的观点。我们的日志几乎充满了我的承诺（当四个队友甚至一天都不做一次承诺时，就不难做到），这使我的同事感到沮丧。

   • “我认为小的提交使得很难找到修订版本。”即使团队努力编写描述性的日志消息，也可以说是合理的观点。

   • “我不想在我们的版本控制服务器上浪费太多空间。”该人员显然不了解提交的存储方式（也不知道存储空间的便宜程度）。

   • “我认为提交应该对应于特定的任务。”鉴于任务通常对应一天中要完成的某些工作（例如在可视化管理的任务板上），这不是巧合。然后，此人应学会在积压的任务（工作2至8个小时）和应提交的逻辑上孤立的变更（工作时间从几秒到几小时）之间有所区别。这也与第5点有关。

7. 搜索团队未执行的原因的提交频率更高。您可能会对结果感到惊讶。

   最近，我在一个不同的答案中提到提交的速度很重要，甚至数百毫秒也可能迫使开发人员以较低的频率进行提交。

   其他原因可能包括：

   • 编写提交消息的规则过于复杂。

   • 强制开发人员将提交链接到错误跟踪系统中的任务的规则。

   • 担心破坏构建。

   • 不愿意立即处理破坏构建的风险：如果您在离开前的星期五晚上进行提交，则可以将处理破坏的构建推迟到星期一。

   • 担心合并。

8. 确定开发人员是否了解经常奉献的其他好处。例如，持续集成平台是频繁提交的巨大动力，因为它可以精确指出引入回归的位置。

   我宁愿CI平台告诉我，我在修订版5023中破坏了构建，该修订版包含十五分钟前在一个文件中对两种方法的更改，而不是在修订版5023中包含跨越四个打文件并代表的更改13个小时的工作。

我过去签约的一个组织想要解决同样的问题，并提出了一个相当不错的社交解决方案：开发人员没有自己的计算机。开发团队拥有计算机，但是在任何给定的一天，任何人都可以被要求并期望在任何开发计算机上工作。因此，签入是确保您可以继续处理昨天所做的事情的唯一方法！

然后，管理人员四处走动，秘密地在数小时后还原了计算机上的更改，因此所有未检入的内容都丢失了。这些“模拟计算机故障”仅需在开发人员加入之前发生几次。

当然，解释规则的“为什么”以及“什么”很重要。除非明确了“为什么”，否则他们只能将其源存储在USB驱动器上或其他东西上。