我有机会向我的老板正式介绍有益于公司的任何事情.我的想法是在我的工作场所采用源代码控制.我一直在使用Mercurial来管理我自己的工作项目,但团队的其他成员没有正式的源代码控制系统.不幸的是,我不善于提出想法.
所以,你们能告诉我为什么开发人员必须使用源代码控制吗？另外,为什么你会选择除 Visual SourceSafe 之外的任何工具？我没有使用VSS的经验,但他可能会问为什么我们不会只使用微软的工具.
我想听听很多聪明的程序员的意见!我首选的选项是SVN或mercurial.两者似乎都对Windows版本有很好的支持,而且两者都不如CVS那么古老.另外,作为一个自称为开源的门徒,我更愿意提出一个开源工具.:)
谢谢!
编辑:为了简化,一般来说,其他开发人员目前的做法是复制文件夹,标记日期,也可以自己录制.你得到了照片.如果我的老板说"如果它有效,为什么要解决它？"
让我们比较两个例子,一个使用源代码控制的开发环境,另一个不使用源代码控制的开发环境.
答:使用
B:不使用
场景1:请求,完成并推出项目
A + B)程序员在内部开发项目,在项目完成后,将其推出测试,然后交付给客户(无论是谁)
从大局来看,差别不大
场景2:项目发布后,客户端决定他们不需要功能X.
A + B)开发人员删除客户端不想要,测试和交付的代码.
再说一次,差别不大.
场景3:两周后,客户决定他们实际上想要特征X.
A)开发人员将他们在2中取出的代码重新集成到正常的开发树中,进行测试和交付.
B)开发人员在他们的个人计算机,文件服务器和备份上搜索旧代码.如果他们找到代码,则必须手动重新插入每个文件.如果他们不这样做,他们可能不得不重新编写整个功能.
您可以轻松获取由于某种原因而取出的旧代码
场景4:系统中存在一个奇怪的错误,其中一个函数应该返回一个布尔结果,但总是返回false.两周前不一样.
A)开发人员检查软件的所有旧版本,并确定返回错误指令不在适当的范围内 - 它在循环内而不是在外部执行.
B)开发人员花费数周时间试图找出问题所在.最终,他们注意到错误的返回,并修复它.没有源代码控制意味着他们必须检查已执行的每个文件,而不是查找它何时工作和现在的差异.
场景5:有人打破了构建.它经过了测试,几周后才被注意到.
A)团队检查提交历史,找出谁破坏了构建,让那个人修复它并购买团队晚餐.
B)团队必须返回整个项目才能找到错误,但无法弄清楚是谁放了代码.开发人员互相指责,团队动态失败.
很容易看出谁承诺了什么,何时以及为什么.
使用源代码管理,因为您和您的团队都不是完美的.源代码管理的主要功能是确保您拥有开发过程的完整历史记录.有了这个记录,你就可以自信地分出"实验"版本,知道如果实验失败,你可以备份到早期版本.
此外,像svn这样的优秀源代码控制系统将允许多个开发人员处理同一个文件,并提供强大的工具来协调每个引入的差异.
简单 - 所以你有一个真实的代码历史 - 调查变化(错误的原因),恢复版本,审计等.备份是不够的 - 你只需要当前图片的副本.永远改变文件,希望你能记得你做了什么？
出于这些原因,您必须使用源代码管理
1)您可以回滚到任何版本
2)不同的开发人员可以处理相同的文件
3)所有开发人员都可以访问相同的代码库
4)您可以跟踪更改
5)您可以回滚不起作用的更改
6)源控制是持续集成的基础,并有助于TDD的大规模使用
7)如果你不使用源代码控制,你会慢慢发疯,因为文件丢失/覆盖,没有任何工作可行
VSS不是最糟糕的SCC应用程序,我使用它多年并且变得讨厌它,但它确实有效,很简单,很多人都知道它.
这是一个简单的现实生活中的例子.
几年前,我的老板说,"功能XYZ曾经工作过,现在却没有.没有人知道发生了什么.你能解决它吗？"
现在我以前从未使用过XYZ功能.因此,修复它会涉及到很多试图弄清楚它的作用.
但我们有源控制!所以我这样做:
创建测试脚本以测试XYZ功能:"单击此处,键入此内容,单击此处,等等"
获取最新版本.建立.测试.功能XYZ已损坏.
从一周前获取版本.建立.测试.功能XYZ工作.
在这两者之间获得版本.建立.测试.功能XYZ工作.
在前一个版本和当前版本之间获取版本.建立.测试.功能XYZ已损坏.
我一直在进行这种二分搜索,直到最终我达到了变化的地步:版本145(我们会说)功能正常,但版本146已经破坏了.然后我只是对这两个版本进行了比较,看看有什么变化.事实证明我们的技术领先(叹气)检查了更改功能的代码,但也引入了破坏功能XYZ的副作用.
所以我删除了副作用,测试了......然后看,XYZ的功能再次起作用.
没有源代码控制,你永远不能这样做.你将不得不四处走动,改变一件事,希望能够神奇地击中让XYZ再次发挥作用的东西.
使用源代码控制,您只需测试版本,确定导致问题的确切代码并进行修复.
Microsoft(MSDN)有一篇关于源代码控制的好处的文章.
http://msdn.microsoft.com/en-us/library/ms173539.aspx
关于利弊,这里也有很多好的问题.
使用它后,你有什么优点和缺点？
Subversion很受欢迎,但Git将成为源代码控制领域的"下一件大事".
在我看来,大多数人已经涵盖了源代码控制的主要特征,但其中一个最大的优点是被忽略了.这些是:
分行
没有源代码存储库,就不可能为特定目的创建代码的分支(或副本/流/等).无法创建和合并分支是使VSS成为真正的源代码控制系统的最大因素之一.分支的一些目的包括:
错误修复
有时您需要解决错误并在远离代码的主线或主干版本的位置执行此操作.这可能是为了解决测试环境中的问题或任何原因.如果您有一个版本控制工具,您应该能够轻松地创建一个新的分支(VSS很糟糕)来修复错误,并且能够在必要时将其合并回主线代码
维护版本
这可能与错误修复大致相同,但在代码发布到生产后完成.示例将是修订包,服务版本等.再次,您希望能够在必要时将更改合并回主干
新功能
有时您需要在维护当前代码的同时开始开发新版本.例如,您发布并维护v1.0但需要在维护v1.0的同时在v2.0上开始工作.分支机构有助于解决这种情况
标记/标签
源代码控制系统所做的另一件事是在特定时间点制作源代码的快照.这些在VSS中称为标签,在颠覆中称为标签等.通过定期创建这些标签并将它们链接到项目中的某个重要里程碑,可以确定发布之间代码中的确切更改内容.这对审计员而言非常重要,但也可以追踪问题的来源/范围.VSS也因此失败,因为VSS只对文件进行版本控制,而不是目录.这意味着如果重命名/移动/删除存储库中的文件或目录,则无法重新创建系统的先前版本(如果重构,则会发生很多事情).像Subversion这样的优秀源代码控制系统就是这样做的.
我建议使用SVN,因为:
源代码控制为您提供优秀的历史 您可以看到进行了哪些更改,从而提供了一种很好的方式来查看随时间变化的内容(如果每次填写提交摘要,则会更好)
对于开发人员来说,如果出现可怕的错误,它会提供极好的后备.您可以将文件的更改还原到其历史记录中的任何位置,这样您就可以尝试使用该模型,如果它不起作用,则可以轻松地将其向后滚动.
它提供了一个中央存储库,比运行到不同开发人员的计算机更容易备份.
它允许您以不同的方向分支项目 - 对于特化和自定义非常有用.
它允许多个开发人员在同一个项目和相同的源上协同工作,允许您合并并以其他方式操作对一个中央副本的更改.
我建议不要使用VSS - 请查看此页面的原因:http : //www.highprogrammer.com/alan/windev/sourcesafe.html更多原因.
如果当前过程是复制文件夹并给它指定日期，那不是在获得某种开发历史记录吗，那基本上不是一种简单的源代码控制形式吗？
因此，要回答对源代码管理的任何批评，您已经在做。现在，您只需要指出当前系统中的弱点，并提出一个更好的建议。当人们真正考虑了开发过程中可能发生的许多复杂场景并开发了使他们能够处理它们的工具时，为什么需要重新发明轮子。
您当前正在做的事情非常脆弱，如果出现任何复杂的情况都将失败，这时您将不得不花费大量精力来制定如何执行工具已经完成的工作。VSS比您的工作要好，但是没有SVN，git或mercurial拥有的非常有用的约定，它使多个项目可以以井井有条的方式一起生活-我在谈论分支，标签和合并其中非常脆弱，基本上是vss的噩梦。
SVN确实有用于Visual Studio的插件。有些是免费的。但是我发现乌龟-svn遮盖了其他任何东西。我发现插件的唯一好处是，新文件会自动添加到svn中。
因此，您当前系统的弱点：
如果必须对文件进行更改，则很可能会被其他开发人员的更改覆盖或覆盖。您甚至可能没有注意到这一点。
如果您必须记住已更改了哪些文件，以将它们复制到某个“主”副本上，则有时可能会丢失一个文件。
祝您好运，找到有关何时进行更改以及原因的任何文档。
您如何在当前系统上构建稳定的自动化构建系统？巡航控制系统和哈德逊机能真的很好，您正在自欺欺人
VSS不能很好地将对多个文件的更改分组在一起。现代的一切都非常出色，并且具有原子一致性。
VSS分支和合并支持非常糟糕。当我们使用它时，我们最终将所有更改括在源代码中，并在注释中手动复制代码，而不是依赖于VSS合并。
要在实时维护中使用某些版本的代码，而在繁重的开发中使用某些其他的以后版本，将非常困难，几乎不可能在当前系统中。考虑这样使两个项目保持同步所需的内容，您将需要一个好的工具。SVN可以做到，git可以做到很好。
那可能足以继续下去，可以做更多的事情。
有一些版本控制系统有助于任何,许多情况:
如果每个版本控制系统想要调用自身的版本控制,那么每个版本控制系统必须完美执行的最基本任务是能够返回到指定版本的项目.如果你弄乱了,你可以使用以前的版本.您可以检查一些以前的版本以检查它是如何完成的(例如在重构之前,或在删除某些代码/文件之前).
与仅使用指定日期保存备份副本相比,版本控制系统占用的磁盘空间更少,因为它们使用增量化(仅存储与先前版本的差异)和压缩.通常,备份系统是存储项目的最后N个版本的手段,有时N = 1(仅前一个版本),而版本控制系统(VCS)存储项目的所有历史记录.在删除Nth最后一个版本后知道Murphy一段时间你会意识到这是你想要检查的版本.
此外,回到最后一个版本很容易并且自动化.您还可以检查单个文件在某个过去版本中的外观,并且您可以在当前状态和某个过去版本之间获得差异(以diff格式).您还可以标记(或"标记")版本,因此您不仅可以通过日期或通过当前版本的第n个版本来引用过去的版本,还可以通过符号名称来引用过去的版本,例如v1.2或v1.2-rc0.
使用版本控制系统,您可以检查历史记录,以提醒您为什么(以及如何)某些代码(给定文件的某些部分)到达当前状态.大多数VCS允许检查文件的行明智的历史,即标注,当它改变了文件的每一行,在什么承诺,以及由何人(该命令被命名annotate,blame或praise依赖于VCS).在某些VCS中,您可以搜索历史记录以获取引入给定代码片段的版本(修订版)(例如,在Git中称为"pickaxe search",VCS之一).
要使此功能真正有用,您必须维护一些规则:您应该描述每个新版本(每个新版本/每个新提交),写下更改的原因.这样的描述(提交消息)非常有用,但它在备份系统中没有自然的位置.
如果您不是唯一的开发人员,这个功能当然更有用......
使用版本控制系统允许以另一种方式查找代码中的错误,即通过搜索历史记录来查找引入错误:bisectiong历史的版本.当您找到引入bug的修订版时,您将有限制(在最好的情况下:非常有限)区域来搜索bug,因为bug必须与上一个工作版本和第一个版本之间存在差异.您还可以获得更改(提交消息)的描述,以提醒您想要执行的操作.此功能也称为diff调试.现代版本控制系统(VCS)支持自动化(或半自动化)通过将历史二等分(将历史分成两半,找到哪个部分包含错误,重复直到找到单个负责版本),以bisect(或类似的)命令的形式搜索历史.
为了使这个功能真正有用,你必须保持一些纪律:你应该提交(保存更改/在版本控制系统中放置给定状态以便记住)单个更改,仅处理一个功能,与先前版本的差别很小; 即经常提交.
大多数版本控制系统提供各种钩子,例如允许自动化测试,或自动构建产品......或者只是提醒您不遵循编码标准(编码指南).
版本控制系统允许创建多个备用并行开发线,称为分支(或流或视图).常见的情况是有开发分支,即具有用于不稳定开发的单独分支(用于测试新功能),用于稳定(主要,主干)版本的单独分支(其应当是当前工作版本),以及用于更多单独维护的分支(修复)分支机构.
拥有维护分支允许您进行错误修正并生成服务包/次要版本,并对某些已发布的版本进行更正,而无需担心新开发的干扰.稍后你可以将maintenace分支合并到stable中,或者从维护分支中选择bigfix进入稳定和开发分支(如果进一步/其他开发没有独立修复bug).
现代VCS(这里现代意味着分支和合并分支都很容易)允许更进一步,即生成单独的分支以处理单独的特征(所谓的主题分支).这允许您在工作一个功能和处理其他功能之间切换(而不仅仅是从开发新功能切换到处理紧急请求的错误修复).
如果您是根据其他(通常是第三方)产品的来源开发产品,那么您真的应该使用供应商分支机构,以便能够轻松地将供应商的新版本产品与您所做的更改集成在一起.不可否认,这不再是纯粹的"单一开发者"案例.
如果有多个开发人员在同一个项目上工作,那么使用版本控制系统会带来更多优势.VCS允许进行concurent(并行)开发,而不必担心有人会覆盖您的更改,或者不考虑您的更改.当然使用版本控制系统无法替代通信.
在多开发人员的情况下,所有上述功能都更为重要:检查谁生成了给定的更改,谁最后更改了代码(也就是破坏了构建的人),找到了不是由您编写的代码中的错误.
京公网安备 11010802040832号 | 京ICP备19059560号-6 