我试图讨论版本控制对于一个或两个开发人员很重要的观点.
更具体地说,我在一个部门工作,通常有两个PHP开发人员使用共享框架.他认为我们的开发系统上安装了Subversion没有增加任何附加值,而我认为偶尔能够回滚查看以前的代码是很好的,特别是在发生难以解决的无法解释的错误时 - 指出一些课程.
我认为Subversion提供了创建和跟踪更改的最简单方法,原因有多种,包括调试.Subversion可以随时保存吗？
你总是,总是希望有某种源代码控制的,即使你是在自己一个项目.
拥有变更历史对于能够在任何给定时间查看代码库的状态至关重要.回顾项目历史的原因有多种,从仅仅能够回滚一个糟糕的变化到提供对旧版本的支持,当客户只想修补补丁而不是升级到更新的版本时软件.
没有某种源控制就是纯粹的精神错乱.
我只是要在这里撒谎并说"是".喜欢@ 17的26说
没有某种源控制就是纯粹的精神错乱.
这是真话.我做过有和没有源代码控制的小项目(不是我的选择).没有,它只是糟透了.没有规范版本的项目,你永远不知道谁拥有什么,合并的变化是痛苦的运动.
实际上,任何超过5行代码的东西都应该受某种版本控制.
肯定是的.
即使您是单个程序员,也需要版本控制.您可以将代码与任何快照及时进行比较的简单性是无价的.
我的建议 - 去吧!
[有一次我没有版本控制.现在我不能了.]
我是一个程序员,我发现它非常宝贵,因为我有时想要回滚,或者将某些东西与早期版本进行比较.
此外,我从用户和类似的东西版本文档.
这是跟踪开发的好方法.
版本控制将保存你的屁股.不使用版本控制的专业开发人员是无可争议地属于软件不当行为类别的少数事情之一.
即使你是一个单独的开发者,它也会
让您回到功能何时起作用
自动维护备份:检入并备份.
当你把自己绑在一个结上时,让你撤消你当地的变化.
让您回到生产中,测试环境中或特定客户环境中运行的版本以进行调试.
如果使用得当,它还可以让您看到与特定问题的修复相关的所有更改,这些修改可能是一个非常宝贵的调试工具.
如果你不止一个开发人员,它将阻止一个程序员覆盖这些更改,这使得无论你多么小心,都会发生另一个程序员.
这些只是帮助您赢得有关是否使用版本控制的争论的基础知识.
颠覆 - 绝对不是.它是集中的,合并支持不是那么好.
版本控制 - 绝对是!即使是独唱开发者也需要它!
小而快速的移动团队需要分布式版本控制,因此请选择以下其中一项:
混帐
善变
的darcs
是的,有一个学习曲线.分发,你可以学习它.是的,你以后可以感谢我.
那些分布式存储库存在于何处？以下是一些想法:
在您的个人USB记忆棒中(并且不要将自己限制在一个 USB记忆棒上,将它们分配到多个位置,例如银行中的保险箱)
另一个在安全的地方(异地,不同的位置,网的另一侧)火灾,地震或龙卷风不能同时伤害你的来源)作为备用
一个在集中式服务器,你的或类似github
开发者机器中的多个副本
staging存储库靠近登台服务器
生产存储库附近的生产存储库
我是一个"单人乐队"程序员,当我发现自己复制整个应用程序并将它们放入一个名为"backup"的文件夹中,然后将它们命名为"20080122-backup"时,我终于开始使用版本控制.我想很多人都是这样开始的.所以问题不在于你是否应该使用版本控制,而是你应该以正确的方式进行,还是应该将一些半自制的传真机组合在一起？
只有程序员数> 0时才需要进行版本控制.
使用任何系统都可以使用,但是如果你进行开发,那么你需要进行版本控制(理想情况下,即使在担心备份之前,源也至少在两台机器上设置).
除此之外 - 寻找一个允许您提前提交并经常提交的系统.
我几乎 - 虽然听起来很奇怪 - 朝着这样的观点前进:每个项目,甚至是1个开发项目 - 都应该关注持续集成,即从头开始构建和测试这个系统,每次更改都是或者至少定期.为什么？这a)让您相信您在VCS中拥有可构建的系统,并且b)确保您实际拥有一个干净的构建来进行测试和部署.
我特别不了解Subversion,但我相信每个项目,即使是一个开发人员,也应该使用版本控制.我会看几个选项(CVS,SubVersion,git,Bazaar,Visual SourceSafe),看看哪个(s)满足你团队的最佳愿望.
版本控制是程序员最重要的工具,甚至比实际的编程语言更重要.无论您拥有多少用户,都应始终需要源代码管理.我不知道有多少次我做了一个突破性的改变,然后需要回去处理旧代码,或者至少看看原代码是如何运作的.我在小团队中工作,我们使用SVN Notifier告诉我们什么时候提交.这使我们可以审查彼此的工作,并且你没有得到可怕的"你有没有检查过你的代码？" 一直有问题.从一开始就使用源代码控制将消除您可能面临的许多令人头疼的问题(覆盖,丢失代码,对谁改变了什么).
绝对.当你冒险的编码路径变得与狼群密集时,真的没有办法处理已知良好状态的回滚.
你可以支持它.
任何没有进行版本控制的人都只是做错了.
我有一个只有我工作的项目,而版本控制让我的生活变得如此简单.例如,假设我决定实施一项新功能.无论出于何种原因,我决定将其丢弃 - 也许我写错了,也许我改变了实施它的想法,无论如何.我所需要的只是从SVN恢复到以前的版本而不是手动恢复所涉及的每个文件.
颠覆不是.但是源代码控制是.
无论您是单个开发人员还是一组开发人员,在开始编写任何内容之前,您必须执行以下操作:
设置版本控制系统.使用你喜欢的任何系统,git,SVN,Mercurial.只要您知道如何使用它就没关系.
建立协作文档系统.使用Wiki或trac,或任何其他您知道如何使用的系统.
设置构建系统.使用Make,ANT,Maven或您知道如何构建的任何其他构建系统.
编写第一个测试用例.
在完成这四项操作之前,不要编写主应用程序的单行代码
无论团队规模如何,我都强烈推荐源代码控制.我有太多的深夜会话,我打破了我的代码,并没有源代码控制去转向较旧的工作版本.
版本控制可以具有以下优点:
如上所述,回滚总是很方便
有些你可以固定以前的版本并运行它而不回滚
有助于防止两个人同时在页面上工作,这可能会导致一些问题
但是,如果你不选择一个好的,它也会有它的垮台
当我想去商店时，我开车去购物。这是不是有必要把我的汽车加油。我可以选择推车，但为什么呢？
同样，选择不使用版本控制。
京公网安备 11010802040832号 | 京ICP备19059560号-6 