老板对将版本控制系统用于新项目表示怀疑，我还是应该吗？

参见/software/109817/superior-refusing-to-use-subversion

我的问题是相似的，但是这是我的情况下的主要区别：

• 我们正在使用PHP和网络技术从头开始一个新项目。如果我愿意的话，在开发中不会出现停机时间，因为从一开始我们就会采用它。

• 我的开发团队包括我和我的老板。我们是一家相对较小的公司的“ IT”部门。

该Web应用程序将完全不使用源代码控制来替换旧版应用程序。由于地域法律要求的差异，决定（在我被雇用之前）决定将应用程序分入每个版本的7个完全独立的目录中。之后，不同的开发人员在不同的时间在不同的地方做不同的事情。好吧，我认为可以在它们之间修补更改，我想这就是我要发布的原因。

我老板的建议，直接从电子邮件中粘贴：

• 更新应作为软件包提交到​​SUBMISSIONS文件夹中。程序包应包含所有相关文件以及包含更新说明的“ UPDATE.NFO”文件，包含的所有新文件的列表（带有描述）以及所有包含修改详细信息的已修改文件的列表。

• 更新包应专注于单个元素，而不应偏离其预期目的。代码应设计为模块化的，并尽可能重用。

• 所有提交的软件包都应在提交后立即安装在每个开发人员的测试环境中。每个开发人员都要审查新添加的内容，并对在生产环境中对其安装的任何疑问发表意见。在将此标准流程更新加载到生产环境之前，至少应保留3个工作日，以进行此审核过程。高优先级更新/修复可以跳过此要求。

发明源代码控制的原因是使所有这些自动化，对吗？我建议颠覆，因为那是我在大学中使用的。老板不喜欢颠覆，因为“它使代码一团糟”（即使用二进制魔术并且不易理解）。我们曾经尝试过一次，但是我认为尝试在Windows上使用它会产生奇怪的小写/大写错误，并且我们无法检出文件。我不知道这仅仅是颠覆还是所有令人反感的源代码控制产品。

那么，我应该对老板提出什么样的论点呢？还是他是对的，有可能会因为一个奇怪的错误而失去我们所有的工作吗？

还是我完全错了？在我的情况下，真的需要源代码控制吗？这是我们正在谈论的主要的关键业务软件，因此毫无疑问，它最终将是巨大的。但是只有2个开发人员（现在）。

另外，如果我不能说服他，我是否有为我自己使用它的任何意义？我说的是实际使用svn的经验非常有限的人；我只知道结帐和提交。源代码控制（可能包括svn以外的其他产品）有哪些功能可以帮助我进行个人开发？

请没有“找另一份工作”的评论。那对辩论没有帮助。

不要问他 不要告诉他 让他看。

在其他计算机上安装svn或git或任何您喜欢的东西。练习自己使用它，直到您不但可以使用它，还可以对其进行解释为止。如果您要使他对新系统感到满意，那么您需要自己对新系统更加满意。当他搞砸合并或将某些内容放入错误的位置时，您将需要能够帮助他轻松恢复。

当您准备好时，请告诉他您正在谈论的内容。告诉他，这不会“弄乱”任何东西。要指出的是，它不仅使您可以轻松地检索代码的任何先前版本，而且还可以准确知道任意两个版本之间的更改。

请指出，如果服务器发生任何事情（严重的错误，病毒，黑客，磁盘崩溃等），如果您可以立即重建必要的版本，它们都将像英雄一样。还要指出的是，如果您能够按需生产任何版本，则外观将翻倍。搜索您的旧电子邮件，并列出过去一年使用版本控制可以避免的问题列表。

给他一个备忘单，这将使他可以轻松使用您的版本控制系统。

最后，提出一些选择，但由他决定。您应该设置自己的服务器，还是使用众多托管服务之一？您应该使用svn，git还是其他工具？您应该将所有七个项目都迁移到系统上，还是首先尝试一个或两个？

源代码控制的好处远远超出了允许多个开发人员处理单个代码的范围。SourceGear的创始人Eric Sink 列举了一些令人信服的理由来将源代码管理用作唯一的开发人员：

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

埃里克（Eric）碰巧也有一个非常不错的初学者的“ 源代码控制方法”。Joel Spolsky提供了免费的在线Mercurial教程，Mercurial是一种流行的分布式版本控制系统。

下一步，我建议您作为唯一开发人员开始在计算机上本地使用源代码管理。很快，您的老板会注意到您具备强大的魔力，例如在几分钟（甚至几秒钟）之内告诉您一个超严重错误的发生时间，然后您可以准确地告诉他哪些客户帐户受到影响，并且需要先修复地狱破了。或能够撤消CEO不赞成的任何更改。

最后，在试图说服老板之前，您可能需要深入研究异议处理主题。这是101的销售。

如果不成功-尽可能快地继续前进，这不会浪费您在风车上倾斜的时间。

是的，即使只为您使用源代码控制也是完全值得的。例如，Git对于独立开发人员而言确实非常有效，并且允许您执行诸如分支和合并（以尽可能低的成本）之类的事情，并且可以随时更改更改版本。

SVN-或实际上是任何版本控制系统-都允许您执行此操作，但是合并会出现更多问题。

如果我不能说服他，我会为我自己使用它有什么意义吗？

是。只为自己使用它会有好处。您会获得更改历史记录，以便了解不同之处。

不，没有好处，因为您的老板将您的项目注定要进行无意义的返工，因为他们搞砸了事情。

我强烈建议使用git之前提到，原因1是因为任何VCS在发生灾难时都是安全网。查找“万一发生火灾：git commit，git push，离开建筑物”标签。代码可能存储在其他地方，但不能存储在笔记本电脑中，因为笔记本电脑可能会发生故障，被盗等……对于像代码这样有价值的东西，即使是本地网络服务器也不是最安全的地方。

数字2。变更的可追溯性，谁做了什么，什么时候等等。合并，撤消。数字3。将神奇的工具与＃2和更多案例进行比较。编号4.分支编号5.标记版本，发行版等。

您可以在此处找到有关最常见的git工作流程之一的更多信息：https : //nvie.com/posts/a-successful-git-branching-model/

我知道使用git最初可能会令人生畏，但这对于一项技能来说是一笔不错的投资，对于任何开发团队来说都是必须的。

关于您的文本案例问题，请避免使用Tortoise，我知道大多数人都将它用作git的GUI，因为它在SVN中非常常见，因此它可能是首选，而不是使用命令行或其他GUI（例如github桌面）或Atlasian的SourceTree。