在没有源代码控制的情况下与多人一起开发应用程序的最有效/最有效的方法是什么？

我的情况简介

我在一家小型Web开发公司工作。我们有一个由四个ASP.NET开发人员组成的团队，其中包括我。我们几乎所有项目（> 98％）都是一个人的项目，大约需要1-4周才能完成。我们不使用源代码或版本控制。我们唯一拥有的是本地服务器上的共享文件夹，其中包含所有项目的最新源（==实时应用程序的源）。

在极少数情况下，我们确实需要与一个以上的人一起从事同一个项目，我们使用...超越比较。开发人员每天一两次询问彼此是否有可编译的版本，然后使用Beyond Compare同步其代码。当只有两个人在一个项目上工作时，这“相当好”，但是一旦第三个开发人员进入流程，它就变成了难以处理的垃圾。尤其是当每个人都开始对数据库进行更改时。

我（和我的一两个开发人员）已经多次告诉我的老板，我们应该开始使用某种形式的源代码和版本控制，例如Git，Mercurial或TFS（我们的老板非常注重Microsoft）。不幸的是，我的老板没有看到切换到源代码和版本控制系统的优势，因为在他看来，现在一切都很好，并且他不想花费时间和金钱来建立新系统并确保每个人都知道如何使用它。即使在我向他解释了优点（例如简化的协作，应用程序的不同版本，更安全的代码更改方式……）之后，他仍然不认为这是我们所需要的。

在这四个开发人员中，只有两个（包括我在内）具有源代码控制（Git）的经验。而且这种经验非常有限。我知道如何将Github存储库克隆到我的计算机上，进行一些更改，提交它们并将其推回到Github。而已。

我的问题/担忧的解释

几周后，我们将开始为我们的标准开展一个相当大的项目。可能需要2-3个开发人员几个月才能完成。我将担任项目负责人（项目经理和首席开发人员），我将负责所有工作。我在使用“超越比较”方法时遇到了很多问题，并且我不想走这个大项目，这是我的责任。

由于我怀疑我们是否能够

• 设置我们自己的Git服务器，
• 教大家与Git合作
• 在这个大项目中成功雇用了Git，

我很感兴趣，如果你们中有人知道一些允许多人在不使用源代码或版本控制的情况下就同一项目进行协作的好方法。

更新资料

我要感谢大家的回答和评论。这是计划：

1. 与开发人员举行会议，以确保所有技术人员对实现源代码控制的感觉相同。当所有人都支持时，我们会提出一个更强的观点。
2. 向老板介绍这个想法，并告诉他我们确实需要源代码控制。
3. 尽快实施。

请花一天时间安装版本控制，并教项目中的每个人使用它。没那么难。我个人还没有使用过Git，但是我已经设置并使用了其他版本控制系统，因此它们工作起来并不难。确保选择一种与您的开发环境集成的软件。这将使它几乎无缝地使用。

这不会浪费时间。

当有人覆盖或删除某些代码时，您将损失的时间将使您付出更多。

如果您没有版本控制，则还将花费大量时间来备份项目，并担心每个人都拥有哪个版本以及服务器上的哪个版本等。

如果您需要说服上司，请估计一下设置和监视任何非版本控制解决方案所花费的时间，并增加重写几天丢失的工作的成本。不要忘了增加手动合并3个使用相同源文件的开发人员进行的编辑的费用，以及增加错误合并的额外费用。良好的版本控制可免费为您提供此功能

然后将其与获得版本控制的成本进行比较-无（如果是开源的话）并进行设置-3个工作日。

别忘了，项目后期的错误将在初期花费不菲的代价。如果您由于一个错误而不得不重做整个项目，那么任何人都可以做到，这将花费远远超过重写时间的代价，这可能会使您的老板失去公司声誉。

如果您在文件夹上共享源，则也可以在其中共享仓库。老板只知道那里有一个.git文件夹，对此一无所知。

塞思·戈丁（Seth Godin），您绝对不必寻求许可才能正确完成工作。

设置源代码控制，学习如何使用它，不要告诉老板。我通常不提倡违抗管理，但是在这种情况下，您的老板是愚蠢的。如果您真的认为git需要花费很长时间来学习，那么请从更简化的版本控制系统（如svn）开始-它不会像git一样完成所有很酷的事情，但是更容易获得基本的了解。

在执行某些操作之前，不要等到您陷入其中并陷入严重麻烦时。只要做到这一点，就可以完成工作。

编辑添加：您的问题真正要问的是“如何在不使用源代码控制系统的情况下执行源代码控制”。您已经意识到了这种需求，并且我想这里的每个人都在真实地告诉您一件事：没有源代码控制系统，就没有理智的方法来进行源代码控制。

我只有您要总结的内容，但是由此看来，您的老板正在争论时间和金钱，而您正在争论技术优势。您需要争论时间和金钱。了解git的工作方式，并在一段时间内跟踪它可以节省的时间，然后向老板显示日志，输入“ 2011年3月28日必须等待30分钟才能让Joe返回可编译的版本因此我们可以对他的上一次提交执行合并，git merge命令大约需要5秒钟，“总和在底部。

如果培训和设置服务器是业务障碍，则可以使用无数种方法来设置git工作流程，包括仅让一个团队成员实际使用git，并为“服务器”共享文件夹。

指示您的同事在适当时将其代码复制到给定的共享文件夹中。您可以为它们中的每一个保留一个存储库，并自己完成所有源代码管理工作，然后在您变得足够有信心训练它们时，将越来越多的源代码管理职责逐渐转移给它们。这远不是理想的实现方式，但是与您现在拥有的相比，即使那样也可以节省您的合并时间。用更少的团队学习曲线说服老板会更容易，并且您可以获得所需的所有回滚和版本控制优势。

我没有做太多的数据库工作，但是据我所知，源代码控制不能很好地合并数据库架构更改。如果这些合并很困难，则您可能需要考虑一个流程更改，其中所有数据库更改都将通过一个关守进行。

疯了吧。即使您自己工作，也应使用VCS。禁止在公司中不使用VCS。去做就对了。马上！真的...从一开始就不需要高级的东西。GitHub和GitLab的使用非常简单，但是我敢肯定，如果老板坚持的话，您可以找到更多与Windows兼容的托管服务（即使在Windows上设置和使用Git并不困难）。

你想的是不可能的。如果多个人在同一个项目上工作而没有使用任何源代码控制，那么您很快就会遇到很多问题，并且由于您将是首席开发人员，因此您必须处理这些问题。

根据我的个人经验，两个开发人员不可能在没有源代码控制的情况下进行项目。不是三个。不是四个。二。在某些特殊情况下，您也许可以与两名开发人员一起处理这种情况：如果这些开发人员非常有条理和专业，他们之间的互动很好，他们可以轻松地进行交流（因此，他们在同一时间位于同一房间，时间），如果他们能够避免人为错误（错误地修改了另一个人同时修改的文件，则擦除该人所做的更改）。

以我为例，要让两个人参加一个没有版本控制的项目，总是或多或少是一场灾难。在最佳情况下，一个人将更改的文件发送到第二个文件，而第二个则使用diff工具手动应用更改。在最坏的情况下，一个人跟踪她所做的更改，然后在第二个人每次修改源代码时重新应用它们。结果：大量的时间，金钱和生产力损失。

现在，从我的角度和我自己的经验来看，我看到了针对您所遇到问题的三种解决方案：

• 安装易于使用的版本控件。我曾经将CollabNetSubversion安装为SVN服务器，如果您根本不关心安全性，那么它安装起来非常快捷，容易。如果您使用Visual Studio，则可以安装AnkhSvn以使开发人员可以从Visual Studio中轻松更新/提交源代码。

• 说服您的老板，Joel测试是由一个非常了解他的工作的人编写的，并且如果Joel测试建议拥有版本控制，则背后有充分的理由。毕竟，他还可以决定开发人员不需要IDE /语法突出显示工具来编写代码。Windows记事本就可以了，不是吗？还有，为什么可以上网？我们需要的是一台运行Windows 3.1的非常老旧的PC。

• 退出这家公司，因为我对除版本控制之外的所有功能都非常完美和专业感到怀疑。

因为不想花时间在一个较大的项目上而没有使用VCS，就像光着脚长途跋涉一样，因为你不想花时间去穿鞋。

任何VCS都比根本没有VCS好几个数量级。

设置VCS的一种简单方法是获取TortoiseSVN（因为您似乎正在使用C＃，所以我认为您使用的是Windows）。您可以在所选的本地文件夹中创建存储库（导航至该目录，右键单击> TortoiseSVN>在此处创建存储库）。在您的网络中共享该文件夹（最好是在计算机上，该文件夹始终可用）并使用url进行签出file://computername/path/to/that/repository。排除下载，此过程不超过一分钟即可设置。

您的答案是指向您老板的简单链接。。。将此页面邮寄给他/她，并突出显示专业人士出现“退出”一词的次数。

虽然“哑巴”一词可能出现了很多次，但我确信您的老板没有。对他来说，这还不是很清楚。要问他的问题是什么与业务相关的问题将导致相同的响应（也许一位会计师建议“相反，不要向这座建筑物保证您与最高保证金挂​​钩，这将为您节省几美元！”）

仅当项目的开发人员数量> 0时才需要源代码控制。我开始认为有人可能会对持续集成持同样的看法...

（-：

当您是ASP.NET开发人员时，我建议您选择Subversion，TFS或Mercurial中的一种-但老实说，只要您选择某种东西，都没关系。没有版本控制的开发毫无意义-甚至更少，当工具或多或少可以自由部署并且使用它们的开销最小时。

TFS将为您提供惊人的集成水平。DVCS（Mercurial或git）可能会为您提供最大的灵活性和功能。没有充分的理由不这样做。

如果我从头开始，那几乎肯定是Mercurial。

一旦有了版本控制权，您就可以升级到构建服务器（TFS，TeamCity），并从那里进行持续集成，然后您就可以开始使用拳头了。

回到起点：

我将担任项目负责人（项目经理和首席开发人员），我将负责所有工作

对了，你是负责使你决定你需要版本控制（因为你这样做），你决定，你需要一个构建服务器（因为你这样做），你决定，你必须从第一天开始从您的项目部署的输出（因为您始终可以部署它-从而促进更多测试），并且部署将高度自动化-这些是您要采取的步骤，以确保项目成功（您对此负责）。

如上所述，您可以将存储库放在已经拥有的共享文件夹上。如果使用分布式源代码控制系统（如Git，Mercurial或Bazaar），则无需花费时间配置服务器。

我建议您使用既已有的Git，也可以使用Mercurial，后者可以很好地集成到Visual Studio中。

如果将来您的老板告诉您切换到TFS，那总比完全没有版本控制要好。

在Powerbuilder时代，我们有一个整个团队在不使用源代码控制的情况下开发一套应用程序。哦，Powerbuilder 拥有源代码控制，但是实际上使用它是一种解决方法-如果在您检出文件时PB崩溃（并且使LOT崩溃），则现在无法访问专有的二进制源代码文件。文件中设置了一些标志，并且PB的其他副本也无法加载它，即使是签出该文件的人也是如此。

所以我们所做的很简单。“嘿，汤姆，我要研究xyz.pbl。所以请不要进行任何更改”。在宏伟的计划中，我们很少遇到任何问题。

假设您无法说服您的团队采用版本控制，或者您的老板不喜欢这种诡计，并坚持要求团队停止，那么您可以采取的方法并非最佳。

在自己的计算机上安装Git或Mercurial。版本您自己的作品。当团队通过“超越比较”流程同步工作时，请将更改作为新提交添加到本地存储库中。如果团队的同步出现问题，您将始终能够从本地回购中检索以前的工作版本。

使用DVCS可确保不需要服务器，也不需要复杂的设置过程。安装Mercurial并启动并运行基本知识应该不会超过30分钟。

这不是理想的解决方案，但总比没有好。

我对此的最初反应是，您已经有了一个理想的工作流程，而没有版本控制。你们似乎都拥有管理合并等的好方法。从管理的角度来看，这似乎是一个好情况。我见过使用版本控制的团队，但是他们不得不为开发过程而苦苦挣扎。

因此，仅凭您的论点说服您的老板会产生“更好的过程”是毫无意义的。但是，还有一个更重要的论点是，为什么首先需要使用版本或源代码控制，而这很容易计算得出。那就是：

风险

问题不在于使用源代码控制可以使您的开发过程更好。如果您根本没有源代码控制，将会发生更多的问题。有什么风险？

假设有人错误地删除了代码中的功能或整个文件？维修费用是多少？希望有人对此有所涵盖，因此解决方法是微不足道的。

但是，如果没有人备份丢失的文件怎么办？要花多少工时才能解决？这可能需要几天的时间，并且很容易以平均工时计算。这对公司来说太多了吗？可以以某种方式更快地补救吗？

是的，带有某种源代码控制。相比之下：设置和备份版本控制将花费多长时间？大多数开源代码（例如git或mercurial）都不会花费很多时间来设置。考虑到您已经知道如何与Beyond Compare合并并且可以“签入”共享文件夹，教人们如何使用它并不难。这是一次性设置费用。这些工时会少于风险所带来的工时吗？如果是这样，则应优先使用源代码控制。

只要您能说明为什么进行源代码控制很有用的商业原因，而风险管理将是一个如此巨大的因素，它将使大多数老板信服。

使用像git这样的分布式版本控制系统，并使用您的共享文件夹计算机来存储参考资料库。原因如下：

每个克隆都是备份

如果服务器硬盘驱动器崩溃，则每个人都有一个副本，可以随时将其部署在新的驱动器或服务器上。由于您的公司并不认真对待版本控制，因此我想与备份几乎相同。

共同参考

具有带有master分支的主存储库可以知道最后一个单词的版本。这解决了“您已经针对Franck的版本测试了您的更改，但是您也拥有John的版本吗？并且如何合并它们？”。

提供更舒适

客户今天要购买Alpha版本吗？好了，您可以测试master是否足够稳定并发货。如果不是这样，而您又没有时间修复它，那么请及时返回以获取较旧但更稳定的版本。如果您只有最新版本，则无法这样做。

回到过去，纠正错误

您的手动合并有几天后才看到的问题，但是您已经覆盖了共享文件夹的内容？没有VSC，您将没有历史记录，因此您无法轻松返回到可以检查并纠正错误的地方。代码不像图片，而是电影：它随时间变化。您可以从电影中提取图片。您无法从图片中提取电影。

更轻松地查找错误

出现了一个错误，但是您在引入它时并没有真正注意到它，因此在代码“热”时您无法修复它。现在您真的不知道是由哪个更改引起的，因此它可能来自代码中的几个不同位置。仅需查找几个地方，就需要几个小时。使用git，您可能已经开发了一个测试来说明该错误是否在特定版本上发生，并用于git bissect查找引入该错误的确切提交。现在，您无需查找数千行代码，而是知道它位于10行更改中，并且可以将测试保留在测试套件中，以确保不会再次引入该错误。

每个开发人员都应对自己的工作负责

如果您是团队负责人，并且没有VCS，那么您很可能必须要做肮脏的工作，即合并。如果您自己执行此操作，则可能不了解所有更改的所有内容，并且可能会引入错误。相反，如果每次合并代码时，您总是要求编写代码的人与您一起收集，那么那时他们将不再使用这些代码来生成新代码。

使用VCS，在简单的工作流程中，开发人员只需照顾他/她的工作，以及一个外部更改源：master分支。在master分支中可能有1或100个人在提交，这是相同的。为了能够推动他/她的更改，他/她将不得不使它们适应他人所做的最新更改。推送代码似乎需要更长的时间，但是那是因为您还要进行合并，这反而会花费时间。

区别在于合并是由进行更改的人员完成的，该人员最了解该代码，因为他/她已经编写了该代码。

谁写的代码？

这里有那个错误，但是谁写了那行特定的代码？很难记住，尤其是如果该项目持续数月之久。git blame会告诉您写该行的人和时间，因此您可以询问合适的人，并且没有“我不记得写过”的内容。

这个项目越来越大

客户想要更多功能，而您的团队太小，您将需要其他开发人员。没有VSC，如何管理增加的合并复杂性？

紧急变化

该客户致电并要求为产品进行重要的错误修复，但是您当前正在开发一项新功能。只是git stash将您的更改放在一边，或者将其提交到新的分支中并推送更改，您就可以开始进行紧急修复，而不必担心丢失正在执行的工作。

10分钟前成功了

您正在本地进行一些更改，而十分钟前就已停止工作。如果没有VCS，您要么盯着代码，要么充其量只能查看参考版本，然后进行比较以查看所做的更改。哦，等等，自从我开始工作以来，引用已更改，因此我无法再进行比较。而且我不认为保留我所做更改的原始代码。

使用VCS，您可以立即执行类似的操作git diff，并且将更改与所基于代码的正确版本进行比较。

我必须保留调试日志

所以你是个坏人，不使用日志记录吗？您必须printf在所有代码库中添加s，直到找到该讨厌的bug的所有部分为止？现在，您找到了一个，修复它，但是想要保留精心制作的调试代码来修复其余问题。

如果没有VCS，您要么需要复制文件，清除调试代码（这可能会增加一些编辑错误），然后推送它，然后放回备份的文件。哦，但是似乎仍然有一些调试代码。

使用Git，你只要git add --patch选择你想要把你提交的代码的几行，并可以提交仅这一点。然后，您可以继续工作，并保留调试代码。您无需触摸代码，因此没有复制/粘贴错误。

大泥球

没有VCS，人们会站在一边，给您带来很多变化，有时是无关紧要的。当要检查的代码太多时，很难找到错误。

VCS将允许您进行小的，增量的更改，并提供一个更改日志。更改日志是必不可少的：人一定要告诉那里，为什么他们正在做的改变，而不是什么是变化（什么问题是alredy通过代码变化本身回答）。这意味着，例如，当您检查某个新功能的某些代码时，您将不必阅读许多无关的混合更改，例如无关的错误修正。这有助于专注于您关心的代码。

如果我一一给您100个土豆，但一个烂了，您会立即发现它。现在，如果我在您面前丢下100个土豆，请您找到烂的土豆，那可就不一样了。

缩进

希望您有良好的编码样式策略，否则如果手动合并，缩进更改会使您发疯。当然，您可以忽略更改中的空格（但在缩进计数中不能使用语言，例如Python）。但是，这样一来，您将很难看懂奇怪的代码。

你是项目负责人

如果您是领导者，这意味着如果事情不起作用，您将受到责备。如果您因为老板仍然不了解使用正确的工具来完成正确的工作是值得的而无法适应这种情况，那么至少我会拒绝成为可预见的失败的领导者。

使用保管箱，它具有自动版本历史记录。您可以在多个用户之间共享Dropbox文件夹。

编辑

您也可以下载TortoiseSVN-client，并在网络驱动器上创建“本地存储库”。然后人们可以按网络文件夹位置检出源代码。