我们店里有两种人：
我是第 1 组的一员，并试图说服第 2 组的人像我一样行事。他们的论点如下：
如果我是对的，请帮助我提出论据以说服他们。如果你同意他们的观点，请告诉我原因。
【问题讨论】：
标签： version-control
当有人询问good excuses not to use version control 时，他们得到了 75 个答案和 45 个赞成票。
当他们问Why should my team adopt source control 时，他们得到了 26 个答案。
也许你会在那里找到一些有用的东西。
【讨论】：
你不需要“说服他们的论据”。话语不是游戏，你不应该把你的作品当作一个辩论平台。这就是你的配偶的目的 :) 不过，说真的，你需要解释为什么你关心其他开发人员如何在其他人不参与的单独项目中工作。你错过了什么，因为他们不参与使用源代码控制？你需要看他们早期的想法才能理解他们后来的代码吗？如果你能成功地做到这一点，你也许可以说服他们。
我个人一直都在使用版本控制，但这只是因为我不会在没有网络的情况下走钢丝。其他人有更多的勇气，更少的时间花在基础设施上等等。请注意，在我看来，在 2009 年，硬盘很少出现故障，并且重写的代码通常比它替换的代码更好。
当我用一个问题来回答一个问题时，让我再问一个问题：您的代码是否需要编译/工作/not-break-the-build 才能签入？我喜欢我的分支变得好坏，然后修复、工作、调试等。同时，我喜欢其他开发人员随心所欲地使用源代码控制。树枝就是为了这个原因而发明的：让那些不能相处的人不必同居。
【讨论】：
这是我对你的观点的看法。
1) 即使是单独的开发人员也需要在 PC 出现故障时在某个地方保存他们的代码。如果他们不小心删除了没有源代码控制的文件会怎样？
2/3) 原型属于源代码管理，因此其他团队成员可以查看代码。我们将原型代码放在主线分支的单独位置。我们称之为斯派克。这是一篇关于为什么要保留 Spike 代码的精彩文章-http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx
【讨论】：
如果我是一个项目的唯一开发人员（换句话说，存储库或其中的一部分在我的完全控制之下），那么我会在编写源代码后立即开始提交，并且我倾向于检查在每次增量更改之后，无论它是否有效或代表任何类型的里程碑。
如果我正在与其他人一起在项目的存储库中工作，那么我倾向于尝试进行提交，以使他们不会破坏主线开发、通过任何测试等。
无论它是否是原型，都应该进入源代码管理；原型代表了很多工作，从中吸取的教训很有价值。另外，原型有一个很糟糕的习惯，就是变成生产代码，你需要在源代码控制中使用它。
【讨论】：
我尝试只编写可编译的代码（其他所有内容都用 TODO/FIXME 标记注释掉）...并将所有内容添加到源代码管理中。
论点 1：即使是单个开发人员，回滚到正在运行的版本、跟踪您的进度等也很不错。
论据 2：谁在乎它是否只是一个原型？您可能会在六个月左右的时间里偶然发现类似的问题，然后开始寻找其他代码...
论据 3：为什么不使用多个 repo？我喜欢将杂项内容归档到我的个人仓库中。
【讨论】：
在编写第一个工件的第一行之前大约 20 分钟开始使用源代码控制。在你开始写东西之后，从来都不是开始写作的好时机。
【讨论】：
有些人只能从经验中学习。
就像硬盘故障一样。或在删除实际有效的代码后将自己编码到死胡同
现在，我不是说你应该擦除他们的硬盘驱动器然后用“如果你使用源代码控制”来嘲讽他们......但如果发生类似的事情，希望将首先完成备份；-)
【讨论】：
早期和经常。正如 Pragmatic Programmers 所说，源代码管理就像一台时间机器，你永远不知道什么时候会想回去。
【讨论】：
我会对他们说...
我是这个项目的独立开发者。
当您离开或交出时，我们将有 0 个开发人员。更有理由使用源代码管理。
代码属于公司而不是您，公司希望承担一些责任。签入代码不需要太多努力：
svn ci <files> -m " implement ajax support for grid control
下次有人想要对网格控件进行一些更改或做一些相关的事情时，他们将有一个很好的起点。所有项目都是从一两个人开始的。现在源代码控制比以往任何时候都容易——他们是否安排了一个 30 分钟的 Tortoise SVN 演示？
这只是一个原型，也许我得从头开始重写。
他们是否关心存储？存储很便宜。他们是否担心浪费在版本控制上的时间？与粗略的电子邮件检查相比，它花费的时间更少。如果他们正在重写位，那么源代码控制对于能够引用旧位就更重要了。
我不想用不完整的版本污染源代码管理。
这实际上是一个很好的问题。我曾经想过同样的事情，并且避免签入代码，直到它干净整洁，这本身并不是一件坏事，但很多时候我只是想胡闹。此时学习分支会有所帮助。虽然我希望 SVN 能够完全支持像 Perforce 这样的清除文件夹。
【讨论】：
让我们看看他们的论点：
- 我是这个项目的独立开发者。
- 这只是一个原型，也许我得从头开始重写。
- 我不想用不完整的版本污染源代码管理。
第一个，第三个。我可以看到推理，但它是基于一个错误的假设。
在工作中，我们使用 Perforce，一个集中式 VCS，事实上，我们只在同行评审后检查编译成功并且不会破坏任何东西的源代码（理论上，当然！）。
所以当我开始一个重要的更改时，我觉得需要中间提交。例如，最近我开始对使用 JDom（XML 解析）的 Java 代码进行一些更改（不知何故，单独执行此特定任务，因此我针对第 1 点）。然后我被卡住了，想使用 Java 1.6 内置的 XML 解析。显然是时候对当前工作进行跟踪了，以防我的尝试失败并想回去。请注意，这种情况以某种方式解决了第 2 点。
我选择的解决方案很简单：我使用替代 SCM！虽然像 SVN 这样的集中式 VCS 可以在本地（在开发人员的计算机上）使用，但我被分布式 VCS 所吸引，在简要测试了 Mercurial（这很好）后，我发现 Bazaar 更适合我的需求和品味。
DVCS 非常适合这项任务，因为它们轻量级、灵活、允许替代分支、不会“污染”源目录（所有数据都在项目根目录的一个目录中）等。
通过进行并行源代码管理，您不会污染其他开发人员的源代码，同时保持返回或快速尝试替代解决方案的可能性。
最后，通过将最终版本提交给官方 SCM，结果是相同的，但在开发人员级别增加了安全性。
【讨论】：
我想补充两点。通过版本控制，您可以：
【讨论】：
就我个人而言，我经常在第一次成功编译后启动版本控制。
我只是想知道为什么没有人在这种情况下提到分布式版本控制系统：如果您可以设法切换到分布式系统（git、bazaar、mercury），那么您第二组的大多数论点将变得毫无意义，因为它们可以刚刚开始他们在本地存储库并在需要时将其推送到服务器（如果他们想从头开始重新启动，他们也可以将其删除）。
【讨论】：
对我来说，这是一个一致的流程。如果您正在编写代码，它应该遵循与您的生产代码相同的源代码控制过程。这有助于在整个开发团队中建立和实施良好的开发实践。
将代码归类为原型或其他非生产类型的项目仅用于确定您将其放在源代码控制树中的哪个位置。
我们在我工作的地方同时使用 CVS（用于非 .NET 项目）和 TFS（用于 .NET 项目），并且 TFS 存储库有一个 Developer Sandbox 文件夹，开发人员可以在其中签入个人实验项目（原型）。
如果项目开始在生产中使用，代码会从 Developer Sandbox 文件夹中移出到主树中它自己的文件夹中。
【讨论】：
我想说你应该在第一次构建之前就开始添加源代码并签入。这样就更容易避免签入生成的工件。我总是使用一些源代码控制，即使是对于我的小爱好，只是因为它会自动从噪音中过滤掉相关内容。
所以当我开始原型设计时，我可能会创建一个项目，然后在构建它之前我会执行“git init, git add ., git commit -a -m ...”，这样当我想移动有趣的部分时，我只需使用 git 进行克隆，然后我可以将其添加到 subversion 存储库或我目前正在使用的任何地方。
【讨论】：
这被称为分支人们尝试使用该程序 :p 原型设计？在一个分支工作。实验？在一个分支工作。新功能？在一个分支工作。
在有意义的时候将你的分支合并到主干中。
【讨论】：
如果代码可能永远不会被使用，我猜人们在最初设置源代码控制时往往会很懒散。我有属于这两个组的项目，源代码控制之外的项目也同样重要。这是每天都会推迟的事情之一。
另一方面，一旦我搞砸了一些 CSS 代码并且不知道我更改了什么，例如使网站的页脚最终位于页眉后面。
【讨论】：
在开始编码之前，我在源代码管理中签入项目。 我要做的第一件事是创建和组织项目和支持文件（例如 .NET 开发中的 .sln 文件）以及必要的支持库和工具（通常在 lib 文件夹中），我知道我将在我的项目中使用。 如果我已经编写了一些代码，那么我也会添加它，即使它是一个不完整的应用程序。然后我检查一切。从那里开始，一切照旧，写一些代码，编译它，测试它，签入它......
您可能不需要从这一点分支或恢复您的更改，但我认为从一开始就将所有内容置于源代码控制之下是一个好习惯，即使您没有任何要编译的东西。
【讨论】：
在开始为项目编写代码之前，我在源代码管理中创建了一个目录。我在创建项目骨架后进行第一次提交。
【讨论】：
我喝醉了，我先 git -init 然后 vim foo.cpp。
【讨论】：
任何体面的现代源代码控制平台（VSS 不是其中之一）不应以任何方式因将源代码文件放入其中而受到污染。我认为任何预期寿命超过每小时 1/2 的东西都应该尽早进行源代码控制。单独开发不再是不使用源代码控制的有效借口。这与安全无关，而是与错误和长期历史有关。
【讨论】：