我真的需要版本控制吗?

时间:2008-10-30 17:14:44

标签: svn version-control

我在互联网(各种网站和博客)上阅读有关版本控制的内容。它有多棒,所有开发者都需要使用它,因为它非常有用。

这是一个问题:我真的需要这个吗?我是一名前端开发人员(通常只是HTML / CSS / JavaScript),我从未遇到像“哇,我昨天的文件!”这样的问题。 我已经尝试使用它,安装SubversionTortoiseSVN,我理解版本控制背后的概念,但是...我不能使用它(对我来说很奇怪)。

好的,所以......那很糟糕吗?我通常独自工作(自由职业者),我没有客户要求我使用Subversion(但这对此来说永远不会太晚,对吧?)。那么,我应该开始并努力学习使用Subversion(或类似的东西?)或者只是浪费时间?


相关问题:Good excuses NOT to use version control

30 个答案:

答案 0 :(得分:117)

这是一个场景,可以说明源控制的有用性,即使你单独工作。

  

您的客户要求您对网站实施雄心勃勃的修改。它将花费您几周时间,并涉及对许多页面的编辑。你上班了。

     

当客户致电并告诉您放弃正在进行的操作以对网站进行紧急但更微小的更改时,您已完成此任务的50%。你没有完成更大的任务,所以它还没有准备好上线,客户端不能等待较小的更改。但是他也希望将微小的改变合并到你的工作中以进行更大的改变。

     

也许您正在一个包含该网站副本的单独文件夹中处理大型任务。现在,您必须弄清楚如何以可以快速部署的方式进行微小更改。你疯狂地工作并完成它。客户端回调进一步的细化请求。你也这样做并部署它。一切都很好。

     

现在您必须将其合并到正在进行的主要更改工作中。你为紧急工作改变了什么?你工作得太快,无法记笔记。而且你现在不能简单地区分这两个目录,因为两者都有相对于你开始的基线的变化。

上面的场景表明,即使你单独工作,源代码控制也是一个很好的工具。

  • 您可以使用分支处理长期任务,然后在完成后将分支合并回主线。
  • 您可以将整个文件集与其他分支或过去的修订版进行比较,看看有什么不同。
  • 您可以跟踪一段时间内的工作情况(顺便说一句,这非常适合报告和开发票)。
  • 您可以根据日期或您定义的里程碑恢复任何文件的修订。

对于个人作品,建议使用Subversion或Git。任何人都可以自由选择其中一个,但要么明显优于不使用任何版本控制。好的书是Mike Mason的“Pragmatic Version Control using Subversion, 2nd Edition”或Travis Swicegood的“Pragmatic Version Control Using Git”。

答案 1 :(得分:38)

答案 2 :(得分:33)

您不需要版本控制,只需要一个trapese艺术家需要一个安全网。这就像备份你的硬盘一样 - 大部分时间看似多余,因为没有任何反应,但最终需要 。这里没有maybes。 发生。而且你永远无法预测何时和过去是何时会发生的糟糕指标。它可能在将来只发生一次,但即使你知道一旦你不知道它会有多糟糕就会发生。

答案 3 :(得分:11)

是!

做到这一点。它不会伤害你..

我通常会从笔记本电脑切换到PC,然后将代码放在中央存储库中,这绝对太棒了。

有时候恢复到最新版本是很好的,因为你搞砸了一些难以修复的东西..

答案 4 :(得分:5)

缺少的最大优势是能够重新生成生成旧版本的源代码。

在构建时,使用“Build 4.26”标记源代码管理。第二天你开始编译Build 4.27。三个月后,当客户说“我正在使用Build 4.26,并且Frickershaw功能中存在一个错误。由于您在构建4.27中对文件格式进行了一些更改,我无法升级到任何其他版本。是否存在你能为我做点什么吗?我愿意付钱。“

然后,您可以签出4.26源代码的分支...修复Frickershaw功能,然后在大约一两个小时内为用户重新构建包。然后您可以切换回版本4.39,并继续工作。

同样,您可以追踪添加错误的确切位置。为bug测试版本4.25,然后是4.20,然后是4.10,最终发现版本4.12中引入了bug。然后,您将查找“Build 4.11”和“Build 4.12”之间所做的所有更改,然后关注Frickershaw功能。您无需调试就可以快速找到错误的源代码。

答案 5 :(得分:4)

尝试使用DVCSGit Bazaar。它们非常易于设置,易于使用,并提供Subversion,CVS等所有重要功能。

关键是你可以在破坏某些东西时恢复到工作版本,这通常比手动撤消更改要快得多。

答案 6 :(得分:4)

分支似乎对你没用?你有没有想过尝试一下看看它是否有效?我也做了很多普通的旧html / css的东西,我发现它非常宝贵。分支测试某些东西,看它是否有效,并决定“meh”然后回滚,确实没有危险。

我从来不需要备份(敲木头),但我发现回滚功能非常宝贵。

答案 7 :(得分:4)

作为自由职业者的一些好处:

  • 明确了解您在每个文件中更改的内容以及何时(只要您经常办理登机手续)
  • 回滚到过去的任何版本。令人惊讶的是,这是多么有价值。
  • 将一组更改作为“发布”进行跟踪。通过这种方式,您可以了解每个客户当前使用的内容以及正在开发的内容。
  • 备份
  • 如果您突然不单独,轻松分享项目的能力

答案 8 :(得分:3)

我认为从“保持所有版本的文件系统”迁移到源代码控制系统的主要优势在于,sccs为所有这些文件添加了所有这些文件的结构,并为您提供记录“在X点 整个 文件系统的一致状态”。

换句话说,“哪个版本的文件A与哪个版本的B,C,D,......”有关。

事后的想法(¡!):提交签入的特殊行为让你想到“这是什么?”,结果日志信息可以,希望,作为记忆......

答案 9 :(得分:3)

源代码控制的一个小优点是我在多台开发计算机上工作。在机器之间移动我的工作很容易。

我认为最大的优势已经列出。它允许我在晚上睡觉,知道如果我们必须回滚更改,那将非常容易。

答案 10 :(得分:3)

如果没有他们整合到我们的流程中,我就不会聘请承包商。他们必须通过我们的SVN访问代码,如果没有满足单元测试和代码审查要求,则不太可能获得报酬。

如果签约,我一定会对VSS(签到/退出)和CVS(合并与冲突)模型有丰富的经验。

自己动手,你有很好的机会玩最新的 - 我会尝试Git。

作为一个单独的开发人员,您可以将源代码控制视为无限制的撤消 - 跨会话和重新启动的协议。

答案 11 :(得分:3)

这个问题的字面答案是,不,你不需要版本控制。

但是,即使您不知道,也可以使用版本控制。


那就是说,许多SCM工具在你突破Grok Barrier之前可能会让人感到神秘或彻头彻尾的不愉快,所以让我们稍微修改一下:

“但是,你确实需要易于使用的版本控制。”它就在那里......下载一堆推荐的视觉客户端并给它们一个旋转,然后尝试最适合你想象的方式。

这导致您意味着提出的问题:

  

为什么我想使用版本控制?“

答案:版本控制可让您无法忍受!

答案 12 :(得分:2)

是的,你需要它。

至少,对于一个开发人员商店,您需要每天多次将代码移动到ProjectName-Date-Time目录中。

也就是说,编写一个脚本,在午餐和退出时自动备份您的工作目录,而不会覆盖其他备份。

这可以快速增长,所以最终你只想保存文件之间的差异,这就是VC应用程序的作用。

答案 13 :(得分:2)

由于您通常独自工作,我会说使用版本控制是个好主意。我在使用版本控制(在我的情况下是Subversion)中发现的主要好处之一是,当单独工作时,它让我更有信心尝试新方法来解决问题。您可以随时分支到解决问题的新方法或框架,看看您是否更喜欢它。如果事实证明这个分支不起作用,你可以放弃它并返回旧方法。这也使得更容易并排尝试不同的解决方案。

所以,如果你曾经见过一种解决问题的不同方法而你想尝试一下,我肯定会使用版本控制作为工具来使这更容易。

答案 14 :(得分:1)

必须必须必须。您必须使用版本控制。

这是最重要的。

如果你现在不明白为什么,你有一天会。

答案 15 :(得分:1)

在整个代码库中搜索。这是一个杀手级功能,主要是因为搜索在另一台机器上进行操作,因此您可以不受干扰地继续工作。

顺便说一句,这就是为什么我们没有更改为SourceGear Vault的原因。它无法做到这一点。我们仍然在寻找与SourceSafe兼容的替代品......好吧,SourceSafe。尽管每个人都说,但它还没有让我们失望*

*这可能只是时间问题。

答案 16 :(得分:1)

真的很奇怪。自从我开始使用版本控制以来,我偶尔需要查找我的代码的旧副本并使用它们。我之前从未需要这样做......可能是因为做的想法并没有真正坚持下去。当您发现版本控制有用时,很容易不会注意到这些时间。

答案 17 :(得分:1)

当你的客户惊慌失措,因为现场网站上有什么东西被打破而且这是一个回归,你会很高兴你可以打开TortoiseSVN,看看你上周二做了什么导致了破损。

答案 18 :(得分:1)

如果您自己工作,并且定期执行备份,则可能不需要VC(除非您将备份计为版本历史记录)。一旦你开始与另一个开发人员合作,你就应该实现版本控制,这样你就不会开始过度编写彼此的工作。

答案 19 :(得分:1)

当事情出错时,他们会。 能够引用一个月前可能已删除的代码,或者在硬件故障或升级后恢复整个项目,这是非常好的。

未来可能还有一点,项目的工作比你更多。在这样的环境中,必须具备防止(或控制)分支和版本控制的能力。

答案 20 :(得分:1)

想想它是否像备份一样。直到你需要的那一天,它有点刺激。然后,您丢失的工作量与备份频率成正比。

另一个好处是能够看到你做旧事情的方式,这些事情可能在某个地方已经过时但在另一个地方可能有用。只需剪切并粘贴进行比较时得到的旧代码。

除非你喜欢重新发明你已经重新发明的轮子......

答案 21 :(得分:1)

拥有html / css / javascript更改历史记录可能是天赐之物。能够在一个月或几个月之前将前端与代码进行比较,确实可以确定为什么突然模板全部都是歪斜的。

另外,如果您希望/需要获得项目帮助,您将拥有一个简单的系统来分发,跟踪和部署更新的内容。

一定要这样做,一旦你习惯了,你会感谢你自己。

结帐(一次) 更新(一天开始) 提交(任务结束/测试后更改)

这就是它的全部。不要提交您在浏览器中刷新的任何单个修改,只需要您想要上线的修改。

答案 22 :(得分:1)

即使您现在不需要它,也是您在团队中工作时所需要的。

答案 23 :(得分:0)

您需要版本控制,就像您在生活中需要保险一样。

答案 24 :(得分:0)

您需要版本控制来管理不同的文件版本。有了它,您可以从不同的地方获取和处理文件,这有助于团队成员在同一个项目上进行协作。

答案 25 :(得分:0)

是的,您需要版本控制用于开发目的或仅用于存储文档。这样,如果您需要这样做,您可以及时返回,以便还原对代码或文档所做的更改或错误。

答案 26 :(得分:0)

一旦你开始在一个团队中工作,该团队引用了来自多个调用者/应用程序的不断升级的“组件”,那么版本控制将是绝对必要的。在那种环境中,你无法跟上可能发生变化的所有排列。

答案 27 :(得分:0)

  

“我真的需要版本控制吗?”

是。除非你写出永远不需要改变的完美代码。

一个例子: 我有一个要求。我建立了一个网页,花了一天左右的时间在页面上,它的Section 508兼容性(这大概是6 - 7年前),并上传到网站。接下来,要求发生了巨大变化。我花了一天时间在页面上工作(Hayuge Excel文件没有轻易转换为可访问的HTML)。大约一周后,客户端交换机要求我们返回版本A.源控制将在大约10分钟内完成。事实上,我不得不在这个任务上再吹一个%$#^^& $#日。

答案 28 :(得分:0)

虽然旧有粗糙,但我们发现Microsoft Visual SourceSafe可以工作。它非常适合保存版本历史记录。如果您不担心分支,这可能不是您的独立开发者,那么它可能符合要求。

就登记而言,找到一个好的检查点可能是一个挑战,但是检查每次保存只会使版本难以跟踪。

答案 29 :(得分:0)

我认为您已经做出了使用某种版本控制的正确决定。为简单起见,我选择了SVN(忽略CVS,因为SVN基本上是一个“更好”的CVS)

SVN可以在文件系统和许多平台上使用“本地”存储库,因此您不必在基础架构(服务器,网络等)中过多地使用它们

SVN的绝佳资源:http://svnbook.red-bean.com

我对GIT了解不多,但它是开源的并获得大量的思想共享可能有很多类似的优势!

从某个地方借用一句话:你现在可能不需要它,但是当你这样做时,你会很高兴你做到了。

快乐版本!