什么时候开始在开发的早期阶段使用源代码控制？

Question

我店里有两种人：

1. 自第一次成功编译以来开始签入代码的人。
2. 其他只在项目完成后才签入代码的人。

我是第1组的成员，并试图说服第2组的人像我一样行事。他们的论点如下：

1. 我是这个项目的独立开发者。
2. 这只是一个原型，也许我将不得不重新从头开始重写。
3. 我不想用不完整的版本污染源代码管理。

如果我是对的，请帮助我提出论据来说服他们。如果你同意他们，请告诉我原因。

Answer 1

当有人要求good excuses not to use version control时，他们得到了75个答案和45个赞成票。

当他们问Why should my team adopt source control时，他们得到了26个答案。

也许你会在那里找到有用的东西。

Answer 2

你不需要“说服他们的论据”。话语不是游戏，你不应该将你的工作用作辩论平台。这就是你的配偶所用的:)但是，严肃地说，你需要解释为什么你关心其他开发者如何处理其他人没有参与的独奏项目。你错过了什么，因为他们没有使用源代码控制？您是否需要了解他们的早期想法以了解他们以后的代码？如果你能成功地做到这一点，你可以说服他们。

我个人在任何时候都使用版本控制，但这只是因为我没有网络走钢丝。其他人有更多的勇气，更少的时间花在基础设施上等等。请注意，在2009年，在我看来，硬盘很少会失败，重写代码通常比它替代的代码更好。

当我回答问题的问题时，让我问另一个问题：您的代码是否需要编译/工作/不打破构建以进行检查？我喜欢我的分支，以获得良好和破碎，然后修复，工作，调试等。同时，我喜欢其他开发人员使用他们想要的源代码控制。分支机构就是出于这个原因而发明的：所以那些无法相处的人不必同居。

Answer 3

以下是我对你观点的看法。

1）即使是单独的开发人员也需要在他们的PC出现故障时保留代码。如果他们在没有源代码控制的情况下意外删除文件会怎样？

2/3）原型属于源代码控制，因此其他团队成员可以查看代码。我们将原型代码放在主线分支的单独位置。我们称之为斯派克。这是一篇很棒的文章，说明为什么你应该保留Spike代码 - http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Answer 4

如果我是项目的唯一开发人员（换句话说，存储库或其中的一部分，完全由我完全控制），那么我会在编写完成后立即提交源代码，我倾向于检查在每次增量变更后，无论是否有效或代表任何一种里程碑。

如果我在一个项目的存储库中与其他人一起工作，那么我倾向于尝试做出我的提交，这样他们就不会破坏主线开发，通过任何测试等等。

它是否是原型，它应该进入源代码控制;原型代表了很多工作，从中学到的经验值很有价值。此外，原型有一个糟糕的习惯，即成为生产代码，你需要在源代码控制中。

Answer 5

在编写第一个工件的第一行之前大约20分钟开始使用源代码控制。在开始写作之后，开始永远不是一个好时机。

Answer 6

有些人只能从经验中学习。

像硬盘驱动器故障一样。或删除实际工作的代码后将自己编码为死胡同

现在，我不说你应该擦除他们的硬盘，然后用“如果你只使用过源代码控制”来嘲笑他们......但是如果发生了类似的事情，希望首先会有备份; - ）

Answer 7

我尝试只编写编译的代码（其他所有内容都用TODO / FIXME标记注释掉）......并且还将所有内容添加到源代码控制中。

参数1：即使是单个开发者，也可以回滚到正在运行的版本，跟踪进度等等。

论点2：谁在乎它是否只是一个原型？您可能会在六个月左右的时间内遇到类似的问题，然后才开始寻找其他代码......

参数3：为什么不使用多个回购？我喜欢把misc的东西归档到我的个人仓库。

Answer 8

早期和经常。正如实用程序员所说，源代码控制就像一台时间机器，你永远不知道什么时候你想回去。

Answer 9

对我来说，这是关于一致的过程。如果您正在编写代码，则应遵循生产代码所执行的相同源代码控制流程。这有助于在整个开发团队中构建和实施良好的开发实践。

将代码分类为原型或其他非生产类型的项目应仅用于确定源代码控制树中的位置。

我们使用CVS（用于非.NET项目）和TFS（用于.NET项目），我工作，T​​FS存储库有一个Developer Sandbox文件夹，开发人员可以在其中检查个人实验项目（原型）。

如果项目开始在生产中使用，代码将从Developer Sandbox文件夹中移出到主树中自己的文件夹中。

Answer 10

我会对他们说......

  

    

      

我是这个项目的独立开发者。

    

  

当你离开或交出时，我们将有0名开发人员。更有理由使用源代码控制。

代码属于公司而非您，公司希望有一些问责制。签入代码不需要太多努力：

svn ci <files> -m " implement ajax support for grid control

下次当有人想要对网格控件进行一些更改或做一些相关的事情时，他们会有一个很好的起点。所有项目都从一两个人开始。源代码控制现在比以往更容易 - 他们是否安排了30分钟的Tortoise SVN演示？

  

这只是一个原型，也许我将不得不从头开始重写。

他们是否担心存储？存储很便宜。他们是否担心版本化浪费的时间？粗略的电子邮件检查花费的时间更少。如果它们重写位，则源控制对于能够引用旧位更为重要。

  

我不想用不完整的版本污染源代码管理。

这实际上是一个很好的问题。我曾经一度认为同样的事情并避免检查代码，直到它很好和干净，这本身并不是一件坏事，但很多时候我只是想四处游荡。在这一点上学习分支有帮助。虽然我希望SVN完全支持清除像Perforce这样的文件夹。

Answer 11

让我们看看他们的论点：

  

  
1. 我是这个项目的独立开发者。
  
2. 这只是一个原型，也许我将不得不重新从头开始重写。
  
3. 我不想用不完整的版本污染源代码管理。
  

首先，第3个。我可以看到推理，但这是基于一个不好的假设 在工作中，我们使用Perforce，一个集中式VCS，实际上我们只检查成功编译的源代码，并且在同行评审之后不会破坏任何东西（理论上，当然！）。

所以当我开始一个非平凡的改变时，我觉得需要中间提交。例如，最近我开始使用JDom（XML解析）对Java代码进行一些更改（不知何故，在这个特定任务的独奏中，所以我解决了第1点）。然后我陷入困境，想要使用Java 1.6内置的XML解析。显然是时候保留当前工作的痕迹，以防我的尝试失败并想回去。注意这种情况以某种方式解决了第2点。

我选择的解决方案很简单：我使用另一种SCM！虽然像SVN这样的集中式VCS可以在本地（在开发人员的计算机上）使用，但我被分布式VCS诱惑并在简单测试Mercurial（这很好）之后，我发现Bazaar更适合我的需求和品味。
DVCS非常适合这项任务，因为它们重量轻，灵活，允许替代分支，不“污染”源目录（所有数据都在项目根目录的一个目录中）等。
通过并行源管理，您不会污染其他开发人员的来源，同时保留回溯或快速尝试替代解决方案的可能性。

最后，通过将最终版本提交给官方SCM，结果是相同的，但在开发人员级别增加了安全性。

Answer 12

我想补充两件事。使用版本控制，您可以：

• 还原到最新版本，或者至少检查它的外观。为此，您需要支持更改集/使用整树提交的SCM。
• 通过在引入错误的历史记录中查找提交，使用所谓的“ diff debugging ”来查找错误。您希望SCM以自动或半自动方式支持它。

Answer 13

就个人而言，我经常在第一次成功编译后开始版本控制。

我只是想知道为什么在这种情况下没有人提到分布式版本控制系统：如果你可以设法切换到分布式系统（git，bazaar，mercury），那么你的第二组的大多数参数都会变得毫无意义，因为它们才能开始他们的本地存储库并在需要时将其推送到服务器（如果他们想从头开始重新启动，他们也可以将其删除）。

Answer 14

我会说你应该开始添加源代码并在之前检查，甚至是第一次构建。然后，更容易避免检入生成的工件。我总是使用一些源代码控制，即使对于我的小爱好黑客，只是因为它会自动过滤相关的噪音。

因此，当我开始原型设计时，我可能会创建一个项目，然后在构建它之前，我会执行“git init，git add。，git commit -a -m ...”，这样当我想移动有趣的部分时只需使用git克隆，然后我就可以将它添加到subversion存储库或者我目前正在使用的任何地方。

Answer 15

在开始编码之前，我在源代码管理中签入了项目。 我做的第一件事是使用必要的支持库和工具（通常在lib文件夹中）创建和组织项目和支持文件（例如.NET开发中的.sln文件）。我知道我将在我的项目中使用它。 如果我已经编写了一些代码，那么我也会添加它，即使它是一个不完整的应用程序。然后我办理登机手续。从那里，一切都像往常一样，编写一些代码，编译，测试，签入...

您可能不需要从这一点进行分支或恢复您的更改，但我认为从一开始就将所有内容都置于源代码控制之下是一个好习惯，即使您没有任何可编译的内容。

Answer 16

我想如果代码可能永远不会被使用，那么在初始设置源代码控制时，人们倾向于放松。我编写的项目属于两个组，而源代码控制之外的项目并不那么重要。这是其中一件事，每天都会被推迟，但实际上不应该这样做。

另一方面，一旦我搞砸了一些CSS代码并且不知道我改变了什么，我有时候很少会让恢复变得复杂。使网站的页脚最终落在标题后面。

Answer 17

它被称为分支人员尝试使用该程序：p原型设计？在分公司工作。实验？在分公司工作。新功能？在分公司工作。

在有意义的情况下将分支合并到主干中。

Answer 18

在开始为项目编写代码之前，我在源代码管理中创建了一个目录。我在创建项目框架后进行第一次提交。

Answer 19

我喝醉了，我先做git -init然后vim foo.cpp。

Answer 20

任何体面的现代源代码控制平台（其中VSS不是一个）都不应该通过将源代码文件放入其中而受到任何污染。我认为任何预期寿命超过1/2小时的事情都应该尽早控制源。 Solo develpment不再是不使用源代码控制的有效借口。它不是关于安全性，而是关于错误和长期历史。