如何说服以自己为高年级的队友学习SVN概念基础？[关闭]

首先，从一些背景开始，我在今年夏天担任了新的开发人员一职，最终成为团队中的最新成员，但经验丰富。

到目前为止，由于采用成本低（在时间和精力上），我已经设法轻松地推动了健康计划。但是，情况已经有所改善。

我的队友之一，尽管经验丰富，但并不真正了解SVN。自然，在他的心理图上描绘了SVN海洋的空白区域使他采取了相当奇怪的用法。

例如，他宣布了一项策略“每个开发人员每天1 SVN提交”，因为否则“服务器将很快用尽磁盘空间”。当我向他解释SVN提交是增量而不是完整副本时，他对此表示怀疑，即使是今天，我也不确定他是否理解这意味着什么。

关于是否.project在SVN中包含Eclipse 配置，我们也有激烈的争论。我的队友坚持认为我们应该这样做，尽管这造成了许多毫无意义的冲突。我反对在SVN中保留单个开发人员配置文件。最终，事实证明，我的队友在每次提交后都有重新检出整个源代码树的做法，以确保“提交到存储库中的代码有效”。这就是他如此坚持将项目配置保留在SVN中的原因-因此很容易重新导入项目。当我解释说commit会将工作副本同步到远程逐个字节地进行，从而不必进行重新检出时，我的队友再次表示怀疑，最终将整个问题视为微不足道。

我认为，我们的团队通过解决项目配置文件中的SVN冲突而浪费时间，该项目配置文件仅包含开发人员特定的设置，根本不需要与SCM共享。所有这些都是混乱的，因为有人围绕错误的假设量身定制了该过程。

我该如何说服一个以自己为资深的队友来更好地理解SVN基础？

IMO最好将那些对项目造成直接问题/伤害的问题与仅影响单个开发人员的问题分开。例如，如果他喜欢每天多次结帐，这会让他放慢脚步，但不会影响其他人。因此，您可以让他这样做（直到他的工作出现明显的性能滞后），并避免争论的麻烦。

您提到的其他问题（例如将Eclipse .project文件保存在存储库中或每天1次提交）是您应重点关注的问题，以使团队尽可能顺利地前进。首先，您应该询问/收集其他团队成员的反馈，这是否也会给他们造成问题。如果还有其他人，您可以共同施加更大的压力，如果需要，可以更轻松地将问题升级到管理。

关于“ SVN磁盘空间不足”，很容易通过做一个实验来反驳他的信念（可能在单独的测试仓库中）。在将更改提交到一个巨大的文本文件甚至很多文件之前和之后，您只需要监视物理仓库文件层次结构的大小即可。如果那不能说服他，那什么也做不了。

在这种情况下，不幸的是，您可能遇到了权限问题，另一个人认为接受“低等”人士的建议会失去尊严。这种冲突无法通过逻辑论点解决。您需要将其升级为管理层，但在执行此操作之前，请务必确保已获得足够的支持（来自队友和/或管理层）。这样的举动可能会被其他人视为公开攻击，因此可能给您（和/或整个团队的安宁）带来麻烦。因此，请三思而后行，然后再与您的支持同事进行讨论。

如果您的公司使用Wiki，请写一些有关SVN的高质量文章：

• 为什么要使用它？
• 什么时候使用？
• 它解决什么问题？

等等

它将吸引CTO的注意，每个拒绝使用的人都必须使用:)

作为领导者，经理和团队成员，我不得不在许多层面上解决职业和人格冲突。无论我被录用什么职位，即使我不想担任该职位，我也通常会被接受为领导者。原因是我处理这些冲突的方式。

与这里的许多人不同，我不同意处理这种情况是“放弃”或“向他展示一种新工具”或“等待他跌倒或摔伤”。最重要的是，等待角色被更牢固地定义永远不是一个好主意。这些角色是由不等待的人，他们的信念，道德和处理紧急情况的能力（无论是否涉及人员）定义的。

在这种情况下，有几种方法可以处理您所描述的人的类型。第一步也是最重要的一步是调查他为何表现自己的方式。这与他所知道的或不知道的无关。他以前很容易就能找到这些信息，所以问题确实是两件事之一：“为什么不呢？” 或“为什么他拒绝提供他的信息？” 这将帮助您找到确切需要解决的问题。

以我的经验，程序员（包括我自己）仅出于以下几个原因而拒绝良好实践或新工具：

• 来源不可信。在这个“ Mac崇拜”和“ MS崇拜者”之间日趋两极化的行业中；在“开源意识形态”和“专有实用性”之间等等…-许多人总是怀疑所提供的信息及其由于提交者或作者的偏见而可能造成的腐败，即使这些信息是证明是可信的。
• 长时间的不良经历...具有相似甚至相同的技术或实践。当它开始时，没有什么是完美的，许多开始时的功能少于最终功能的1/4。在执行不力的阶段，他可能有很多小时或几天甚至几周的时间来处理劣质产品或同一个产品。
• “可信”来源...与他所显示的信息冲突。“可信”是指他信任的某个人或实体。许多人倾向于将我们信任的人们提升到不代表现实的水平。这个来源甚至不必将这种信念强加于人。通常，我们自己做。至少在一方面，它常常给我们某种渴望成为某人的东西。
• 缺乏安全性以前的海报强调了这一点。从我们开始研究它们的那一刻起，我们的程序就成为资产。不仅对我们所服务的公司，而且对与我们一起工作的人。这不仅仅是一个控制问题。我们中有些人希望能够向我们关心的人展示我们的精巧产品。我们中有些人想确保它不受外界人员或产品的伤害。对于某些人来说，它甚至是我们思维方式的延伸。它包含了我们的一些哲学和意识形态，并暴露了我们的知识核心。对于许多人来说，无论是班级，雇主还是客户，这都是我们的未来。对于某些人来说，就是所有这些。从这个意义上讲，“安全性”不适用于数据，不一定是代码或代码。

找出哪个因素通常很容易。使人处于中立的环境。通常，向该人解释您正在观察的内容。诚实地问这个人是什么导致了这种行为。现在，这种情况并不总是很顺利，但是当您似乎想帮助似乎行为不合理的人时，大多数成年人的反应都很好。很有可能他没有采取不合理的行动，但是他不知道没有人能理解真正的情况。

一旦找出问题的实质，就可以为自己配备适当的工具来解决问题。如果是方案1，请鼓励他从他信任的来源进行研究（这很重要）用他自己的发现回到你身边。这将告诉他，他自己的信息对您很有价值。在场景2的情况下，请提供与现在不同之处的准确比较。鼓励他尝试一下，但要确定备份方案是否出错。对于场景3，告诉他用您的信息重新查询他的源。可能他的消息来源并不持有他认为自己的观点，而是一次做出的。我们大多数人会随着时间而适应，因此他的观点可能已经改变。如果他不愿意，鼓励他向您介绍他的消息来源。最后，对于方案4，向他保证他的担心是您自己的。（他们应该处于某种程度）演示这个“新”工具如何保护他的利益并提高他的安全性。如果不能的话

我知道所有这些听起来都太简单了，但有时确实做到了。实际上，您越真诚，就越会做。通过满足他的需求，您正在满足团队的需求，无论他是否是“高级”，因为他是团队的一部分。向他显示您希望与他同在一个页面，但事实并非如此，这可能会鼓励他开始与您一起工作。如果您已完成所有这些操作，但仍无法解决，那么您已经尽力与团队负责人交谈了。

模糊逻辑

关于源代码控制有很多迷信。这是违反直觉的，数学是不可思议的，并且涉及软件公司拥有的最重要的一项资产。我必须承认，我的一部分仍然不信任它。但是我不会一分钟没有它。

一种解决方案可能是承担管理回购的责任。当然，如果您将其表示为“这对您来说是很多工作，而这恰好是我有经验的领域”，而不是“您不知道自己在做什么”更好的工作机会。

如果“认为自己是高级人”意味着我认为的那样，那么他不会放任它，因为他将其视为权威和控制的来源。因此，您可以在本地使用Git来管理明智的提交单位和分支，然后按他的要求每天推送一次svn。Git被设计为点对点系统，并在每台本地计算机上具有完整的回购副本。您可以将git提供给其他愿意这样做的开发人员，并且它仍可以作为单个工作组（无论是一个还是多个开发人员，是正式的还是临时的）在内部使用的SVN的补充。当高级管理人员放任自流，搬到另一个部门或公司，或将自己的SVN政策涂在无法恢复的角落的日子到来时，您就有了清理这一切的先机。

只是跟他们说话。看，我是高级开发人员，但有些事情我不知道。这就是业务的本质。如果他们变得防守或好斗，那将是开发人员的性格问题，这种情况应由团队负责人处理，或者如果他们是团队负责人，则由其老板处理。

启动一个棕色皮包计划，每隔几个星期有人在午餐时间谈论他们所知道的事情，然后将其介绍给其他人。

您以此为借口，详细介绍了SVN以及某些替代方案背后的一些想法。

几个星期后，其他人可以去了。

我将根据我的个人经验为您提供一些提示。

我的队友之一，尽管经验丰富，但并不真正了解SVN。自然，在他的心理图上描绘了SVN海洋的空白区域使他采取了相当奇怪的用法。

例如，他宣布了一项策略“每个开发人员每天1 SVN提交”，因为否则“服务器将很快用尽磁盘空间”。当我向他解释SVN提交是增量而不是完整副本时，他对此表示怀疑，即使是今天，我也不确定他是否理解这意味着什么。

即使磁盘空间是一个问题，您也总是可以一次提交很多文件，所以我认为他的建议是错误的解决方案。此外，由于SVN不会存储二进制文件的增量，因此通过检入较大的二进制文件可能会浪费大量空间。每天进行一次签入也是不好的，因为它会迫使您提交不属于您的更改，例如，如果您每天修复多个错误。

我们公司采用的解决方案是有一个过滤器拒绝任何包含二进制文件的提交。我们可以通过在签到注释中使用特殊关键字来强制提交（我们必须向SVN证明我们知道自己在做什么）。一年或两年一次，项目经理会存档旧分支并将其从存储库中删除。通过这种策略，我们不会遇到我所知道的空间问题（我们的存储库支持几个不同的项目，并且有超过100000个修订版）。

总结一下，您可以告诉他您同意他磁盘空间是一个重要问题，但另一方面，请指出

1. 与功能相关的签到而不是每天一次的整体签到的重要性；
2. 通过每天检入一个大的二进制文件，无论如何仍可以填充磁盘这一事实。

然后，您可能建议您召开一次会议（可能还会与其他开发人员或系统管理员开会），讨论控制磁盘空间使用情况的策略（例如，二进制文件筛选器，定期备份和清理未使用的旧分支）。

关于是否在SVN中包含Eclipse .project配置，我们也有激烈的争论。我的队友坚持认为我们应该这样做，尽管这造成了许多毫无意义的冲突。我反对在SVN中保留单个开发人员配置文件。最终，事实证明，我的队友在每次提交后都有重新检出整个源代码树的做法，以确保“提交到存储库中的代码有效”。这就是他如此坚持将项目配置保留在SVN中的原因-因此很容易重新导入项目。当我解释说commit会将工作副本同步到远程逐个字节地进行，从而不必进行重新检出时，我的队友再次表示怀疑，最终将整个问题视为微不足道。

我认为，我们的团队通过解决项目配置文件中的SVN冲突而浪费时间，该项目配置文件仅包含开发人员特定的设置，根本不需要与SCM共享。所有这些都是混乱的，因为有人围绕错误的假设量身定制了该过程。

您是否使用构建服务器？我们有一个构建服务器，它可以检出整个项目，并每晚进行编译。第二天早上，测试人员已经准备好该产品的安装程序（如果主版本正确运行），而我们（开发人员）则拥有包含所有警告（如果有错误，还包括错误）的版本报告。当然，您需要为构建服务器设置标准配置文件并将其检入。每个开发人员随后都可以将其与项目的其余部分一起检出，但是不允许他们检入任何本地更改。

在这种情况下，您可以解决他需要能够检出完整项目并随时构建它的需求。您还可以避免花费时间来合并最初不应该检查的更改，因为它们不是产品的一部分：产品是主版本，必须保持清洁。如果有人破坏了主版本（例如，签入自己的.project文件），则可以还原更改或强制开发人员解决问题。

也许如果他再次提出问题，您可以再次建议召开一次会议（可能与其他开发人员开会），然后共同寻找共同的策略。

我该如何说服一个以自己为资深的队友来更好地理解SVN基础？

我认为最好的策略是避免将冲突带入个人层面，而是讨论眼前的问题和可能的解决方案。如果您觉得他正在寻找个人对抗，那么这里有一些建议（同样根据个人经验）：

• 您的团队动力如何？您的其他同事在此队友中也有类似的经历吗？有很多细微但不太明显的暗示，团队可以给予其成员劝阻某些行为（小笑话或观察）并鼓励建设性对抗（提议开会，或在喝咖啡休息时间非正式地提出话题） ）。有时，一支优秀的团队可以迅速隔离出令人困扰的因素，并使事情恢复正常。
• 您的人员管理水平如何？我们公司发生了一起一起冲突案件，所有人员必须介入以清除情况。这不是很好，但有时工作环境恶化得很厉害，以至于无法单独改善。我希望这不是您的情况（我还没有得到这么远的印象），但是总是很高兴知道您是否拥有良好的人事管理或是否必须自行解决冲突。

我为什么要写这个？您说您想“说服一个以自己为高级的队友，以更好地理解SVN基础”。在我看来，冲突可能变得太个人化了。一些心理学家坚持认为，我们70％的交流都是在情感层面上进行的，如果这种交流方式不起作用，那么人们就会因为忙于处理情感而停止谈论事实。

因此，除了解释您的观点外，您还可以尝试做一些事情来改善沟通。邀请一起喝咖啡或共进午餐，就与工作无关的话题进行简短交谈等，可以改善沟通，并使同事的注意力重新回到您希望他理解的重要事实上。如果他接受这种交流，那么也许到目前为止您所发生的冲突与您彼此不了解并且存在一些小误会有关，但是他可能愿意建立建设性的合作。如果他拒绝，那么他的身边可能会有更深的敌意。

在这种情况下，我认为您应该等到角色变得清晰为止。如果您的队友在官方上没有比您更高的级别，那么您改善自己的努力就不会惹恼他。随着时间的流逝，如果他不断尝试表明自己知道更多，他将不得不接受它或自欺欺人。如果他确实有较高的职位，您应该找到一种让他明白这不在讨论中的方法：您的观察旨在提高生产力而不是损害他的职位，这一点必须100％明确。明确角色后，如果他仍然不能接受建设性的建议或批评，那么他确实必须在自尊心或类似问题上有问题。

因此，如果上述所有策略都失败了，而您又感到（非常）沮丧，那么恐怕唯一合理的事情就是收拾行装，寻找更好的地方。三年前，我取得了这一经验，并找到了一家令我非常满意的更好的公司。也许这不是您的情况（我当然希望不是），但也请尝试理解这一点。

只是我的2美分。

向他介绍一些有关SVN的工作原理以及使用SVN时的最佳实践的学习材料。

正如@Peter所说-谨慎选择战斗，不要浪费精力与显然不了解基本知识的人战斗。SVN并非完全是尖端技术，它已经存在了一段时间，因此有足够的信息。

尝试保存“ SVN时间浪费”的日志。每当遇到需要解决的冲突/结帐/版本问题时，请记下您/团队解决该问题所花的时间。如果事实证明您每周都在浪费大量时间，请与他和管理层一起逐步升级。我敢肯定，如果管理人员意识到可以通过简单地更改工作流程来提高生产率，他们很快就会寻求解决方案。

或者尝试说服您的同事参加一个试用周，在该周中，团队将使用您的签入系统（如果您当前的项目和代码库很容易实现）。向他保证，如果无法解决问题，您可以在一周结束后切换回旧系统。但是他可能会自己尝试一下后再来。

1.让Subversion为您解决问题。按照您的说法，您的同事在Subversion方面相对比较老练。在这种情况下，技术解决方案可能是一个不错的选择。如果团队的其他成员都同意，并且您可以得到经理的祝福，请global-ignores在存储库配置文件中添加一个字段，以便您可以排除.project文件和其他您不需要的版本控制文件。

2.帮助他。不要将自己的处事方式强加于他，而要帮助他以自己的方式行事而不会给其他人造成麻烦。如果你的同事是他自己的分支上工作，你真的不应该关心什么，他提交。如果他想提交.project文件，以便他可以签出整个目录的新副本，那么这对您来说没有问题。您唯一需要关心的是他不会将自己的.project文件合并回通用开发分支。同样，通过在开发分支上设置ignore属性以排除.project文件，这应该易于管理。

3.从上方寻求支持。不要和那个家伙争论“你不是我的老板”，但是如果他的行为给您造成了问题，那么请确保您的经理知道这种情况。如果您不确定如何与您的经理取得联系，请尝试寻求建议：“迈克，我一直在与拉里（Larry）交谈，但是我只是没有通过。我们其余的人都花了很多不必要的时间来解决所产生的问题。您能给我任何有关如何与这个人打交道的指示吗？”

4.别理他。为什么团队中的任何人都听这个家伙？他对该项目有任何实际授权吗？如果他没有执行权，谁会在乎是否宣布每个开发者一次提交政策？如果让他感觉好些，就让他认为他是“海龟耶鲁”，只是不要让他为您造成真正的问题。

让这个家伙被解雇，然后拖着脚跟拖拽，对新技术产生明显的污点。还是真的让他大吃一惊，开始使用GIT。如果他不懂SVn，那么他一定会被GIT吓倒了。

您似乎正在与一场失败的战斗搏斗，但可以坚持下去。《王子》中的马基雅维利（Machiavelli）描述了改变现状是多么困难。我建议再次阅读该章，然后也许不按照他的建议去做-这可能很苛刻。

您应该私下向高级开发人员提出疑虑，并确保以建设性的方式批评事情的进行方式，而不是他或任何其他开发人员。然后提供一个演讲并编写最佳实践指南。向他们展示如何更好地了解SVN将使他们的生活更轻松。最终，一切都与成本和效率有关。如果您可以证明自己的方法可以在不踩脚的情况下改善自己的状况，那么您可能会赢得这一殊荣。

尝试了解高级人员为何按原样使用存储库。他们有什么担心？他们想达到什么目的？您如何帮助他们提高生产力？首先，请务必保持冷静和专业的态度。很容易感到沮丧。自信：工作中的自信：肯· 贝克（Ken Back）和凯特· 贝克（Kate Back）撰写的处理尴尬情况的实用指南，是一本好书。最后，考虑“我将如何说服自己转换？”。做一个诚实的恶魔拥护者，这可能会帮助您提出好的答案和问题。

作为附带说明，我会谨慎使用幽默。它可能会产生奇迹，也可能使您听起来像个混蛋。因此，我会避免这种情况。

从根本上讲，请谨慎选择战斗，因为您可能不会赢得这场战斗。在这种情况下，要么不再关心，要么寻找其他工作。严厉，我知道。

大约8年前，当SVN是相当新的技术时，我曾经处于与您相反的位置。我是一名高级开发人员，并且由一个初级开发人员要求/调试安装SVN（实际上，他比开发人员更准确地提供IT支持）。尽管最初怀疑工作量增加，不必要的复杂性等，但我还是保持开放的态度，然后成为其中的忠实拥护者。

在我看来，从您的描述来看，这个问题肯定归结于团队个性-他的born强在这个问题上已成为整个团队的障碍。此时最好退后一步，让团队其他成员自然地施加压力来逼他，可能会更好。

这几乎是“缺乏权威”的情况，一个人运用自己的恐惧的力量使事情“处于控制之下”

要解决此问题，请找到启发您的队友的人或他尊敬的人，并且能够解释使用SVN之类的迫切性。这样，他对改变的恐惧和基本上“失去权威”就不会发挥作用，因为这不是团队成员告诉他该怎么做。我不会使用像经理这样的人来和这个家伙说话，因为这只会增加压力，甚至可能给自己造成更大的压力。

我最近读了The Pragmatic Programmers出版的《推动技术变革：团队中的人们为什么不对好的想法采取行动，以及如何说服他们应该这样做》。本书提供了您在尝试介绍技术变更之前应了解的背景知识，反对或拒绝变更的人员的多种模式，实施变更的技术，然后是最大限度地利用这些技术以及周围所有人员的策略。您。

根据您的帖子，我想说您的队友可能会陷入“无知”或“愤世嫉俗”模式，但他也可能是“非理性”事件的一例。建议使用一些与这些类型的人对抗的技术，以便在目标环境中积累经验，以便您可以发现任何问题并为其他人会在遇到问题之前遇到的问题提供答案，解决正确的问题，热情地传达信息，但是不要过分热心，通过清楚地展示您的方法和工具的优势并进行有机销售来演示技术（但不要仅仅为了解决问题而造成问题），并在团队的其他成员中进行宣传和购买。但是，如果他是非理性的，

最后，然后您开始使用这些技术，您需要一个总体策略。重要的是不要让那些积极敌对或非理性的人放慢您的步伐-忽略他们。相反，找到可以证明并确信自己有更好方法的人，并以他们为个体来应用适当的技术。一旦更多的人看到了您的知识所提供的改进，请使用它们继续说服他人。最后，使用基层的努力来说服管理层，这是一种更好的方法，但是请务必以他们可以理解的方式（时间，金钱，质量）来说明。

不要试图“说服”这个家伙。人们（甚至是程序员）也不会回应或尊重他们认为比他们小辈的人的合理/逻辑论证。所以不要浪费你的呼吸。相反，要与该人建立信任度。这个人只有在对他开放时才会听你说。

同时，您遇到了实际的问题：

1. 这个家伙将他的.project文件检入存储库：只需忽略它即可。您不必修改文件，团队中其他任何人也不需要知道。放手吧。如果它给您的“高级成员”像安全毯一样温暖，快乐的感觉，那就这样吧。
2. 在磁盘空间上有一个可观的预算：这就是Senior先生规定每天1次提交的原因。空间短缺是真实的还是可感知的？即使只是被感知，也许您也可以做些改变。这应该立即处理-如果您采取主动，这也有助于建立信任。

我还可以补充一点，当他认为这是他的想法时，他会愿意采用更好的SVN实践。这将需要您进行一些深思熟虑，并且他可能会因建立更好的做法而受到赞誉-但您对此表示满意。