我看到很多网站都提到了git,github,svn,subversion等,但我从来都不知道所有这些都是什么.我也听过很多像'svn repo','commit'和'push'这样的术语 - 我试过谷歌搜索,但似乎我对这个主题知之甚少,我甚至不知道从哪里开始.
有人能给我初步推动,所以我可以继续自己研究吗？这些东西到底是什么？
谢谢!
伙计们:非常感谢你们所有这些长期而且包罗万象的解释.我希望我可以选择不止一个答案,但不幸的是,SO不允许这样做(他们应该有第1,第2和第3位投票功能或其他内容).非常感谢你们!
版本控制(又名修订控制).
考虑以下问题.您正在与其他人一起开展项目,并且您正在共享文件.你们都需要工作,比如"WhateverController.java".这是一个巨大的文件,你们都需要编辑它.
处理这个问题最原始的方法是不要同时编辑文件,但是你们两个都必须在同一页面上.当你有一个团队时,特别是如果团队有几十个或几百个或几千个成员(典型的开源项目),这就变得完全不可能了.
这个问题的一个古老的,原始的"解决方案"是有一个结账/签到机制.当你需要编辑文件时,你"检查出来",文件被锁定,所以没有其他人可以编辑它,直到你通过"检入"解锁它.这是通过适当的软件完成的,例如微软令人叹为观止的愚蠢的废话SourceSafe.但是当人们忘记"检查文件"时,没有其他人可以在使用时编辑该文件.然后有人去度假或出于其他原因离开项目,结果是无休止的混乱,混乱和通常相当多的丢失代码.这增加了巨大的管理工作.
然后是CVS,随后是Subversion,作者称之为"CVS做得对",因此CVS和Subversion基本上是相同的想法.有了这些,没有实际的退房.您只需编辑所需的文件并将其签入.请注意,实际文件存储在中央服务器上,每个用户也在自己的工作站上运行该软件.服务器上的此位置称为存储库.
现在,如果两个人在CVS/Subversion中处理同一个文件会发生什么？它们被合并,通常使用GNU diff和patch.'diff'是一个实用程序,可以提取两个文件之间的差异.'patch'使用这样的'diff'文件来修补其他文件.
因此,如果你在一个函数中处理WhateverController.java,并且我正在使用不同的函数处理同一个文件,那么当你完成了你的东西时,你只需检查它,并将更改应用于服务器上的文件.同时,我的本地副本不知道您的更改,因此您的更改根本不会影响我的代码.当我完成更改后,我也会检查文件.但现在我们有这个看似复杂的情况.
让我们调用原来的WhateverController.java,文件A.你编辑文件,结果是文件B.我在不同的位置编辑同一个文件,没有你的更改,这个文件是文件C.
现在我们似乎有问题.文件B和C的更改都是对文件A的更改.因此,在像SourceSafe或Dreamweaver这样可笑的向后垃圾中,通常最终会覆盖文件B的更改(因为它首先被检入).
CVS/Subversion和大概Git(我几乎一无所知)创建补丁而不是仅仅覆盖文件.
生成文件A和C之间的差异并成为补丁X.产生A和B之间的差异并成为补丁Y.
然后补丁X和Y都应用于文件A,因此最终结果是文件A +对我们各自工作站上的B和C所做的更改.
通常这完美无瑕.有时我们可能在相同的代码中处理相同的函数,在这种情况下,CVS/Subversion将通知程序员一个问题,并在文件本身中呈现问题.这些问题通常很容易解决,至少我从未解决过这些问题.Visual Studio,Project Builder(Mac OS X)等图形工具通常会向您显示文件和冲突,因此您可以选择要保留哪些行以及要丢弃哪些行...然后您还可以编辑如果要手动合并冲突,请手动设置该文件.
因此,从本质上讲,源代码控制是解决多个人处理相同文件的问题.基本上就是这样.
我希望这可以解释.
编辑:Subversion和大概Git等源代码控制系统还有许多其他好处.如果出现问题,您可以返回其他版本,这样您就不必手动备份所有内容.事实上,至少对Subversion来说,如果我搞砸了一些东西或者想看看旧版本的代码,我可以这样做而不会干扰别人的工作.
GIT,Subversion等都是关于版本控制的.如果您将这些技术用于项目,则所有源文件都存储在所谓的存储库(也称为"repo")中 - 除了不需要版本控制的文件(大文件,用户特定文件......) .
版本控制的一些优点是:
分行.您可以为正在处理的每个错误创建一个新分支,例如,不要篡改其他开发人员的代码.大多数版本控制系统将制作廉价的副本,即新的分支将占用(几乎)没有额外的空间.
版本.您可以随时返回旧版本,更新到新版本或查看提交日志以查看代码上发生的情况.像TortoiseSVN这样的GUI工具甚至提供了差异工具,可以用图形方式显示差异.术语"提交" 基本上意味着将新版本的文件放入存储库(或添加/删除文件).版本控制系统还支持"合并",即自动合并由多人(通常基于行)更改的文件的更改.
同步发展.多个开发人员可以拥有自己的"工作副本"(也称为"结帐").这意味着 - 即使您不使用分支 - 您的本地代码副本也会编译,即使其他人当前正在处理该项目(因为他们有自己的工作副本).当您认为当前代码对其他人有用时,您可以提交更改,其他人可以更新其副本.
中央存储和备份.这适用于CVS/Subversion/...,而不适用于GIT.这是一个优势,因为有一个中心位置可以提交更改,并从其他开发人员那里获取更改.
分配.但这对GIT有效(不适用于Subversion).这意味着项目可以有多个存储库,彼此独立.例如,Linux内核就是这样.人们可以"拉"他们自己的工作库 - 它就像一个完整的存储库,即提交是在本地而不是服务器.如果您想要包含来自其他人的存储库(或来自kernel.org等公共存储库)的补丁,您只需将这些更改"拉"到您的本地存储库即可.如果你想给别人你的补丁,你可以将你的更改"推"到远程仓库(如果你有权利).
希望能解释你提到的条款.我认为开始使用版本控制的一个良好开端是Subversion,如果可能的话,使用TortoiseSVN for Windows.甚至有一本关于它的免费书 - 使用Subversion进行版本控制.
它们都是源代码控制的不同版本:
http://en.wikipedia.org/wiki/Revision_control
" Git的寓言 ",由汤姆·普雷斯顿华纳(mojombo),后面GitHub的人之一,介绍了如何版本控制系统,例如如Git,可能已经进行了......同时说明为什么人们会想要和需要(分布式)版本控制系统.
另请参阅Better Explained中的" 版本控制的可视指南 "一文.
使用版本控制系统有许多优点.让我们按照复杂性增加的顺序大致列出它们:增加开发人员数量,增加项目规模/项目历史规模,更复杂的工作流程等.
即使您是项目的单一(唯一)开发人员,并且(至少目前)您不打算更改它,版本控制系统仍然有用.它允许:
回到一些工作版本.如果你正在处理你的项目,并且你意识到你完全搞砸了,你尝试的方法不起作用,你不知道如何使它工作,能够简单地回到上次工作是很好的版本,重新开始.
这意味着您应该提交,即在您有工作版本时对您的更改进行快照(好吧,有例外,见下文).为避免丢失大量工作,您应该经常,最好(如下所示)完成单个功能,单个问题或单个部分功能或问题.
你也想知道你做了什么,以及你最近在做什么.这意味着您应该描述每个变更集(每次提交).
注释文件/浏览历史记录.除非你有完美的记忆,否则你有时会想知道为什么(以及何时,以及在有多个开发人员的情况下)你写了一组给定的行.评论并不总是足够的.为此你可以使用(如果您的版本控制系统提供的)行方式文件历史注释(scm annotate或scm blame),或其他类似的工具,如Git中所谓的"pickaxe"搜索,您在其中搜索/浏览历史记录以查找引入或删除的提交给定字符串.
为了使它有用,您需要编写好的提交消息,描述更改的更改和意图,这样您就可以知道更改的原因.
Bishes历史找到错误.在某些情况下,现代版本控制系统提供了替代(插入打印语句或调试器)查找错误的方法.当您发现错误或获取错误报告,并且该错误不是上次更改的结果时,您可以使用版本控制系统(csm bisect)自动查找引入该错误的提交(第一次提交已提供错误的提交).版本控制系统使用项目历史记录的二分法,检索(检出)您标记为良好(没有错误)或坏的版本来找到此类提交,直到找到引入该错误的提交.
为此,您应该始终确保该版本在提交之前工作(或至少编译),否则您将无法确定提交是否存在错误.您应该保持较小的提交(没有太多更改),因此当您发现引入错误的提交时,您将只需要检查受更改影响的所有行数.您还需要良好的提交消息,因此您可以知道更改的原因(并确定更改是否正确).
稍后您将需要版本控制系统的另一个功能:能够在项目的不同开发线(风格)上并行工作,即所谓的分支.这包括但不限于:
分页版本.当您将项目的新版本发布给更大的公众时,您可能希望标记(标记)已发布的版本.这样当有人告诉你项目的XY版本有bug时,你就可以查看这个版本,并检查你是否可以重现这个bug(也许可以通过二分法找到一个bug,见上文).即使您没有发布项目,如果您使用可能在不同位置部署的不同版本,这可能也有用.
对于这个标签需要是不可变的(当然).
长寿的分支机构.我们假设你发布了你的项目,有人发现了一个bug.您可能希望在不停止处理新功能的情况下放置(发布)固定版本,并且不从发展中发送可能不稳定且包含多个其他错误的版本.此外,您还希望错误修复程序也在您正在使用的版本中(如果它没有独立修复).
为此,您将使用长期存在的分支:维护分支,您只需编写错误修正,以及开发分支(或主干),您将在其中执行新工作,引入新功能等.可能有更多分支具有不同的稳定性.例如,Git项目有四个这样的分支:'maint'用于错误修正,'master'用于非常稳定的更改,'next; 用于开发工作,以及'pu'或"建议更新"分支.在其他工作流程中,每个版本都有单独的维护(错误修复)分支.
引用Joel Spolsky的话说:"保持稳定和dev代码分离正是源代码控制应该让你做的事情."
主题(功能)分支.当您想要并行处理多个问题时,每个功能需要多次提交才能完成,您可能希望在单独的分支中开发每个功能(每个功能).这样,您就可以从处理一个功能切换到处理其他功能(在其他主题上).
如果您与多个开发人员合作,此工作流程尤其重要,请参阅下文.
版本控制系统最重要的特性之一是它可以实现不同开发人员之间的协作,允许多个人在同一个项目上工作而不会踩到彼此的变化.此功能在其他回复中有详细描述,因此我不会详细说明.
另请参阅" 理解版本控制 ",Eric S. Raymond(其中包括"The Catedral and the Bazaar"和"The Unix of Unix Programming")的作者正在进行的工作,以描述版本控制系统使用的各种方法.允许合作.
京公网安备 11010802040832号 | 京ICP备19059560号-6 