我在互联网(各种网站和博客)上阅读有关版本控制的内容.它是多么伟大,以及所有开发人员如何使用它,因为它非常有用.
这是一个问题:我真的需要这个吗？我是一名前端开发人员(通常只是HTML/CSS/JavaScript),我从未遇到像"哇,我昨天的文件!"这样的问题.我已经尝试使用它,安装了Subversion和TortoiseSVN,我理解版本控制背后的概念但是...我不能使用它(对我来说很奇怪).
好的,那么......那很糟糕吗？我通常独自工作(自由职业者),我没有客户要求我使用Subversion(但这对此来说永远不会太晚,对吧？).那么,我应该开始并努力学习使用Subversion(或类似的东西？)或者这只是浪费时间？
相关问题:不使用版本控制的好借口.
这是一个场景,可以说明源控制的有用性,即使你单独工作.
您的客户要求您对网站实施雄心勃勃的修改.它将花费您几周时间,并涉及对许多页面的编辑.你开始工作了.
当客户致电并告诉您放弃正在进行的操作以对网站进行紧急但更微小的更改时,您已完成此任务的50%.你没有完成更大的任务,所以它还没有准备好上线,客户端不能等待较小的更改.但他也希望将微小的变化合并到你的工作中,以应对更大的变化.
也许您正在一个包含该网站副本的单独文件夹中处理大型任务.现在,您必须弄清楚如何以可以快速部署的方式进行微小更改.你疯狂地工作并完成它.客户端回调进一步的细化请求.你也这样做并部署它.一切都很好.
现在,您必须将其合并到正在进行的主要更改工作中.你为紧急工作改变了什么？你工作得太快,无法记笔记.而且你现在不能简单地区分这两个目录,因为两者都有相对于你开始的基线的变化.
上面的场景表明,即使你单独工作,源代码控制也是一个很好的工具.
您可以使用分支来处理长期任务,然后在完成后将分支合并回主线.
您可以将整个文件集与其他分支或过去的修订版进行比较,以查看不同的内容.
您可以跟踪一段时间内的工作(顺便说一句,这对于报告和开发票非常有用).
您可以根据日期或您定义的里程碑恢复任何文件的任何修订.
对于单独工作,建议使用Subversion或Git.任何人都可以自由选择其中一个,但要么明显优于不使用任何版本控制.好书是由Mike Mason 编写的" 使用Subversion的第二版的实用版本控制 "或由Travis Swicegood编写的" 使用Git的实用版本控制 ".
有很多好处,是的,你需要它.
哪些工具/技术可以使独立开发人员受益？
单独开发人员的最佳版本控制
您不需要版本控制,只需要一个trapese艺术家需要一个安全网.这就像备份您的硬盘驱动器,大部分的时间似乎多余的,因为什么也没有发生,但它会最终被需要.这里没有maybes.它会发生.而且你永远无法预测何时和过去是何时会发生的糟糕指标.它可能在将来只发生一次,但即使你知道它会发生,一旦你不知道它会有多糟糕.
是!
做吧.它不会伤害你..
我通常从笔记本电脑切换到PC,然后将代码放在中央存储库中.
有时候恢复到最新版本是很棒的,因为你搞砸了一些难以修复的东西.
缺少的最大优势是能够重新生成生成旧构建的源代码.
在构建时,使用"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功能.您无需调试就可以快速找到错误的源代码.
京公网安备 11010802040832号 | 京ICP备19059560号-6 