Version control 在开发的早期阶段何时开始使用源代码管理?

Version control 在开发的早期阶段何时开始使用源代码管理?,version-control,Version Control,我们店里有两种人: 自第一次成功编译后开始检入代码的代码 其他的只在项目即将完成时签入代码 我是第一组的一员,试图说服第二组的人像我一样行动。他们的论点如下: 我是这个项目的独立开发者 这只是一个原型,也许我得从头重写一遍 我不想用不完整的版本污染源代码管理 如果我是对的,请帮助我提出论点来说服他们。如果您同意,请告诉我原因。如果我是项目的唯一开发人员(换句话说,存储库或其中的一部分在我的完全控制之下),那么我会在编写源代码后立即开始提交源代码,并且我倾向于在每次增量更改后签入,无论它是否有效或

我们店里有两种人:

  • 自第一次成功编译后开始检入代码的代码
  • 其他的只在项目即将完成时签入代码
  • 我是第一组的一员,试图说服第二组的人像我一样行动。他们的论点如下:

  • 我是这个项目的独立开发者
  • 这只是一个原型,也许我得从头重写一遍
  • 我不想用不完整的版本污染源代码管理

  • 如果我是对的,请帮助我提出论点来说服他们。如果您同意,请告诉我原因。

    如果我是项目的唯一开发人员(换句话说,存储库或其中的一部分在我的完全控制之下),那么我会在编写源代码后立即开始提交源代码,并且我倾向于在每次增量更改后签入,无论它是否有效或代表任何里程碑

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


    不管它是否是原型,它都应该进行源代码控制;原型代表了大量的工作,从中吸取的经验教训很有价值。另外,原型有一个成为生产代码的可怕习惯,这是你在源代码管理中想要的。

    我认为你应该在第一次构建之前就开始添加源代码并签入。这样就更容易避免签入生成的工件。我总是使用一些源代码控制,即使是我的小爱好,只是因为它会自动过滤相关的噪音


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

    在编写第一行工件之前大约20分钟开始使用源代码管理。在你开始写东西之后,从来没有一个好的开始时间。

    有些人只能从经验中学习

    就像硬盘故障一样。或者在删除实际有效的代码后,将自己编码到死胡同中


    现在,我并不是说你应该擦除他们的硬盘,然后用“如果你使用了源代码管理”来嘲弄他们……但是如果发生类似的事情,希望先做一个备份;-)

    我尝试只编写可编译的代码(其他所有代码都用TODO/FIXME标记注释掉)。。。并将所有内容添加到源代码管理中

    论点1:即使是作为一个开发人员,回滚到一个正在运行的版本、跟踪您的进度等也是不错的

    论点2:谁在乎它是否只是一个原型?您可能会在六个月左右的时间里偶然发现一个类似的问题,然后开始寻找其他代码


    论据3:为什么不使用多个回购协议?我喜欢将杂项内容归档到我的个人repo中。

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

    当有人提出要求时,他们得到了75个答案和45张选票

    当他们提问时,他们得到了26个答案


    也许你会发现一些有用的东西。

    以下是我对你观点的看法

    1) 当个人电脑出现故障时,即使是个人开发者也需要有地方保存他们的代码。如果他们在没有源代码管理的情况下意外删除文件,会发生什么情况


    2/3)原型属于源代码管理,因此其他团队成员可以查看代码。我们将原型代码放在主线分支的单独位置。我们叫它斯派克。这里有一篇很棒的文章,介绍了为什么应该尽早且经常使用Spike代码。正如务实的程序员所说,源代码管理就像一台时间机器,你永远不知道什么时候你会想回去。

    你不需要“说服他们的论据”。讨论不是游戏,你不应该把你的工作当作辩论平台。这就是你配偶的目的:)不过,说真的,你需要解释为什么你关心其他开发人员如何在其他人不参与的单独项目中工作。你缺少什么,因为他们不使用源代码管理?你需要看看他们早期的想法来理解他们后来的代码吗?如果你能成功地做到这一点,你也许能够说服他们

    我个人一直在使用版本控制,但这只是因为我不会在没有网络的情况下走钢丝。其他人更有勇气,花在基础设施上的时间更少,等等。请注意,在我看来,在2009年,硬盘很少出现故障,重写的代码通常比替换的代码要好


    当我用一个问题回答一个问题时,让我问另一个问题:您的代码是否需要编译/工作/不破坏要签入的构建?我喜欢我的分支得到良好和破坏,然后修复,工作,调试,等等。同时,我喜欢其他开发人员使用源代码管理,无论他们想要什么。分支机构的发明正是出于这个原因:这样,不能相处的人就不必同居。

    对我来说,这是一个持续的过程。如果您正在编写代码,它应该遵循与生产代码相同的源代码控制过程。这有助于在整个开发团队中建立和实施良好的开发实践

    将代码分类为原型或其他非生产类型的项目应该只用于确定将其放在源代码管理树中的位置

    我们在我工作的地方同时使用CVS(对于非.NET项目)和TFS(对于.NET项目),TFS存储库有一个开发人员沙箱文件夹,开发人员可以在其中签入个人实验项目(原型)

    如果项目开始用于生产,
    svn ci <files> -m " implement ajax support for grid control