版本控制工具_svn版本控制工具 - CSDN
精华内容
参与话题
  • 版本控制工具

    千次阅读 热门讨论 2005-01-24 17:33:00
    版本控制工具 版本控制是程序开发、管理必不可少的工具,特别是在多人协作的团队中,适宜的版本控制工具可以提高开发效率,消除很多有代码版本带来的问题。本文首先列举没有版本控制工具时可能遇到的问题,再对主流...

    版本控制工具
        版本控制是程序开发、管理必不可少的工具,特别是在多人协作的团队中,适宜的版本控制工具可以提高开发效率,消除很多有代码版本带来的问题。本文首先列举没有版本控制工具时可能遇到的问题,再对主流版本控制工具做概要介绍,之后对作为Java开发者首选的版本控制工具CVS的历史、功能、概念做详细的介绍;最后在Eclipse+CVS环境中,以CVS使用的一个完整流程为例,介绍如何正确的使用CVS工具。

    为什么要使用版本控制工具?
    如果没有版本控制工具的协助,在开发中我们经常会遇到下面的一些问题:
    一、 代码管理混乱。如果是别人添加或删除一个文件,你很难发现。没有办法对文件代码的修改追查跟踪。甚至出现文件丢失,或新版本代码被同伴无意覆盖等现象。
    二、 解决代码冲突困难。当大家同时修改一个公共文件时,解决代码冲突是一件很头疼的事。最原始的办法是手工打开冲突文件,逐行比较,再手工粘贴复制。更高级的做法是使用文件比较工具,但仍省不了繁杂的手工操作,一不小心,甚至会引入新的bug。
    三、 在代码整合期间引入深层BUG。例如开发者A写了一个公共函数,B觉得正好可以复用;后来A又对这个公共函数进行了修改,添加了新的逻辑,而这个改动的却是B不想要的。或者是A发现这个公共函数不够用,又新做了一个函数,B却没有及时获得通知。这些,都为深层BUG留下隐患。
    四、 无法对代码的拥有者进行权限控制。代码完全暴露在所有的开发者面前,任何人都可以随意进行增、删、改操作,无法指定明确的人对代码进行负责。特别是产品的开发,这是极其危险的。
    五、 项目不同版本发布困难。特别是对产品的开发,你会频繁的进行版本发布,这时如果没有一个有效的管理产品版本的工具,一切将变得非常艰难。
        上面只是列举了一些没有版本控制系统可能带来的问题,特别是对大型项目和异地协同开发有了一个合适的版本控制工具,它可以有效解决因为代码版本不同引起的各种问题,让我们的开发人员能更多的把精力花费在开发上面。而不是每次都花费很多时间进行代码整合和解决版本不同带来的各种问题。

    主流版本控制工具介绍
        现在,有很多优秀的版本控制工具供我们选择,下面就五种主流的版本控制工具做简单的介绍。
    Starteam
        是一个集合了版本控制、构建管理(Build Management)和缺陷跟踪系统为一体的软件,并且具有强大的图形界面,易学易用;但管理复杂、维护困难。2002年底被Borland公司收购。
    PVCS Version Manager
         是美国的MERANT公司软件配置管理工具PVCS 家族中的一个组成部分,它能够实现源代码、可执行文件、应用文件、图形文件和文档的版本管理;它能安全地支持软件并行开发,对多个软件版本的变更进行有效的控制管理。
    ClearCase(CC)
        是ROSE构件的一部分,目前最牛的配置管理工具,主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务。可以控制word, excel,powerpoint,visio等文件格式,对于不认识的格式可以自己定义一种类型来标识。
    Visual SourceSafe(VSS)
        简单易用、方便高效、与Windows操作系统及微软开发工具高度集成。
    CVS(Concurrent Versions System)
        是开发源码的并发版本系统,它是目前最流行的面向软件开发人员的源代码版本管理解决方案。它可用于各种平台,包括 Linux 、Unix和 Windows NT/2000/XP等等。
        前面三种是重量级的商业版本控制工具,更适合庞大的团队和项目,并且价格不菲。Visual SourceSafe是微软的产品,当然只能用在windows平台并与微软的开发工具无缝集成。CVS免费开源,并且几乎所有开源项目都是使用CVS进行版本管理,无疑,它是我们Java开发者最优选择。

    CVS的历史、功能、基本概念的介绍

    历史

        CVS 诞生于 1986 年,当时作为一组 shell 脚本而出现;1989年3月,Brian Berlinor用C语言重新设计并编写了CVS的代码;1993年前后,Jim Kingdon最终将CVS设计成基于网络的平台,开发者们能从Internet任何地方获得程序源代码。截至目前最新版本是2004年12月13日发布的1.12.11。

    功能介绍
    一、 代码统一管理,保存所有代码文件更改的历史记录。对代码进行集中统一管理,可以方便查看新增或删除的文件,能够跟踪所有代码改动痕迹。可以随意恢复到以前任意一个历史版本。并避免了因为版本不同引入的深层BUG。
    二、 完善的冲突解决方案,可以方便的解决文件冲突问题,而不需要借助其它的文件比较工具和手工的粘贴复制。
    三、 代码权限的管理。可以为不同的用户设置不同的权限。可以设置访问用户的密码、只读、修改等权限,而且通过CVS ROOT目录下的脚本,提供了相应功能扩充的接口,不但可以完成精细的权限控制,还能完成更加个性化的功能。
    四、 支持方便的版本发布和分支功能。

    基本概念
    资源库(Repository)

    CVS的资源库存储全部的版本控制下的文件copy,通常不容许直接访问,只能通过cvs命令,获得一份本地copy,改动后再check in(commit)回资源库。而资源库通常为与工作目录分离的。CVS通过多种方式访问资源库。每种方法有不同目录表示形式。
    版本(Revision)
    每一个文件的各个版本都不相同,形如1.1, 1.2.1,一般1.1是该文件的第一个revision,后面的一个将自动增加最右面的一个整数,比如1.2, 1.3, 1.4...有时候会出现1.3.2.2,原因见后。revision总是偶数个数字。一般情况下将revision看作时CVS自己内部的一个编号,而tag则可以标志用户的特定信息。
    标签(Tag)
    用符号化的表示方法标志文件特定revision的信息。通常不需要对某一个孤立的文件作tag,而是对所有文件同时作一个tag,以后用户可以仅向特定tag的文件提交或者checkout。另外一个作用是在发布软件的时候表示哪些文件及其哪个版本是可用的;各文件不同revision可以包括在一个tag中。如果命名一个已存在的tag默认将不会覆盖原来的;
    分支(Branch)
    当用户修改一个branch时不会对另外的branch产生任何影响。可以在适当的时候通过合并的方法将两个版本合起来;branch总是在当前revision后面加上一个偶数整数(从2开始,到0结束),所以branch总是奇数个数字,比如1.2后面branch为1.2.2,该分支下revision可能为1.2.2.1,1.2.2.2,...
    冲突(Conflct)
    完全是纯文本的冲突,不包含逻辑上的矛盾。一般是一份文件,A做了改动,B在A提交之前也做了改动,这样最后谁commit就会出现冲突,需要手工解决冲突再提交。

    CVS与eclipse集成开发
      前面对CVS的历史、功能、概论等理论知识做了介绍。下面我们将使用最流行的Java IDE Eclipse中内置的CVS工具,以一个完整开发流程,介绍实际环境中CVS的正确使用。关于CVS系统的安装,不是本文的内容,您可以从附录的链接中获取安装的介绍资料。

    常用的CVS控制命令
    Check Out(检出)
    把源文件从cvs源代码仓库中取出,缺省的版本是最新的版本,你也可以选择指定的版本。在每次更改源代码之前,需要Check Out最新的版本,再起基础之上对源代码进行修改。将代码目录checkout到指定目录下,所有文件都是read-write。
    Check In(检入)
    把源代码加入到cvs源代码仓库中,每一个添加进代码库中的文件的版本是 1.1。以后每次修改文件重新ci以后,此文件的版本递增为1.2 ,1.3.……。在每次对源代码修改之后,需要Check In,提交最新版本的源代码。
    Synchronize with Repository(与资源库同步,简称同步)
    使本地更改与资源库同步,它会列出本地和资源库之间不同的所有文件。
    Add to Version Control
    将新的文件加入到版本控制之中。
    Add to .cvsIgnore
    将文件设置到版本控制之外,这样该文件或目录中的文件的更改在CVS中不可见,即使同步也无法发现。

    CVS正确使用步骤
    一、 同步(Synchronize)

    就是将本地更改与服务器同步,同步之后可以清晰的看到上一捡出(Check Out)版本之后本地、服务器上的最新改动。这是非常有用的,特别是敏捷开发,强调集体拥有代码。有了同步功能,你可以全局把握项目的代码,可以很方便的跟踪公共模块代码的任何改动。
    具体操作:在Eclipse的资源视图(Resource Perspective)或者Java视图(Java Perspective)中,选中要同步的目录,点击右键选择"Synchronize with Repository",之后它将显示同步的视图。如下图:
     
    (图一、CVS同步视图)
    同步之后,它有四种Mode可以选择,见上图绿色框框里按钮。从做到右分别为:
    Incoming Mode:表示修改是来自服务器,对应于更新(update)操作。
    Outgoing Mode:表示修改是来自本地,对应提交(commit)操作。
    Incoming/ Outgoing Mode:本地和服务器修改都在该模式(Mode)中显示。
    Conflicts Mode:显示本地和服务器修改的冲突文件。
    二、 更新(update)
    比较简单,选择Incoming Mode,再选中要更新的文件,右键选择update操作。
    三、 解决冲突并合并(solve conflct and merge)
    如果有冲突文件,冲突文件不能更新。你必须先解决冲突再操作。选中冲突的文件,再点右键选择"Open in Compare Editor",用比较工具打开该文件。如下图:

    (图二、CVS比较器视图)

    比较器(Compare)视图,左边版本底的是本地文件(Local File),右边是远程服务器文件(Remote File)。使用"Select Next Change"按钮(绿框中的第一箭头向下按钮),逐一查看不同点。如果不同点标识为黑色框框,则不用管它。如果是蓝色框框,则需要手工调整。如上图,不同点是蓝色框框,将鼠标放到两个不同点的中间小方框中,则凸出一个向右的按钮,并显示提示信息"Copy Current Change from Right to Left",意思是将右边服务器的不同点覆盖到左边的本地文件。点中此按钮。重复这样的操作,将所有服务器上的更改拷贝到本地。
    如果有一行代码,本地和服务器都同时做了修改。这时,修改点则显示红色框框。这时,你就必须手工做正确的修改。全部修改完成,保存本地文件。
    此时,如果修改点没有了蓝色的框框,就可以开始做合并(merge)操作了。操作也很简单,选择该文件,点击右键,选择"Mark as merged"。
    注意:必须确保没有蓝色框框,即完全拷贝了服务器的修改才可以做合并(merge)操作,否则会覆盖服务器上的代码。
    四、 提交(commit)
    更新服务器代码,解决冲突之后,首先要查看本地文件修改之后是否有错误。如果有,当然首先解决错误,再提交。

    附录:
    http://www.8848software.com/scmchina/scmtools.htm 由很多版本控制工具的文档链接。
    http://www.perforce.com/perforce/reviews.html Infrastructure Group对Perforce 和Clearcase, CVS, PVCS,Visual SourceSafe (VSS)几种CM工具进行了定量和定性的比较. 对于定性的比较,内容涉及工具支持的方法和环境;对于定量的比较,包括在不同的项目规模上,执行不同的活动所需要的时间。

    展开全文
  • 常用的版本控制工具对比

    万次阅读 2017-06-07 19:15:12
    项目源代码的版本管理工具中,比较常用的主要有:CVS、SVN、Git 和 Mercurial (其中,关于SVN,请参见我先前的博客:SVN常用命令 和 SVN服务器配置) 目前Google Code支持SVN、Git、Mercurial三种方式,例如:...

     Git 、CVS、SVN比较

     

    项目源代码的版本管理工具中,比较常用的主要有:CVS、SVN、Git 和 Mercurial  (其中,关于SVN,请参见我先前的博客:SVN常用命令 和 SVN服务器配置

    目前Google Code支持SVN、Git、Mercurial三种方式,例如:我上传的linux-kernel-source(Git 方式)、sdk-java(SVN方式),那么它们各有什么区别呢?


    Git与CVS 的区别 

    • 分支更快、更容易。
    • 支持离线工作;本地提交可以稍后提交到服务器上。
    • Git 提交都是原子的,且是整个项目范围的,而不像 CVS 中一样是对每个文件的。
    • Git 中的每个工作树都包含一个具有完整项目历史的仓库。
    • 没有哪一个 Git 仓库会天生比其他仓库更重要。


    Git与SVN 的区别

    Git 不仅仅是个版本控制系统,它也是个内容管理系统(CMS)、工作管理系统等。如果你曾是一个使用过SVN背景的人,那么你可以很容易的做一定的思想转换,来适应Git提供的一些概念和特征。这篇文章的主要目的就是通过介绍Git能做什么,以及它和SVN在深层次上究竟有什么不同,通过比较来帮助你更好的认识Git

    1. Git是分布式的,SVN不是

      这是Git和其它非分布式的版本控制系统(SVN,CVS)最核心的区别。如果你能理解这个概念,那么你就已经上手一半了。需要做一点声明,Git并不是目前第一个或唯一的分布式版本控制系统。还有一些系统如 BitkeeperMercurial 等也是运行在分布式模式上的,但Git在这方面做的更好,而且有更多强大的功能特征。

      Git 跟SVN一样有自己的集中式版本库或服务器。但 Git 更倾向于被使用于分布式模式,也就是每个开发人员从中心版本库的服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说,如果你被困在一个不能连接网络的地方时,就像在飞机上,地下室,电梯里等,你仍然能够提交文件,查看历史版本记录,创建项目分支等。对一些人来说,这好像没多大用处,但当你突然遇到没有网络的环境时,这个将解决你的大麻烦。

      同样,这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐,你不必再像以前那样做出补丁包,通过email方式发送出去,你只需要创建一个分支,向项目团队发送一个推请求。这能让你的代码保持最新,而且不会在传输过程中丢失,一个这样的优秀案例就是: GitHub.com 

      有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。

    2. Git 把内容按元数据方式存储,而SVN是按文件

      所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn、.cvs等的文件夹里。如果你把 .git 目录的体积大小跟.svn比较,你会发现它们差距很大。因为 .git 目录是处于你的机器上的一个克隆版的版本库,它拥有中心版本库上所有的东西,例如标签、分支、版本记录等。

    3. Git 分支和SVN的分支不同

      分支在SVN中一点不特别,就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支,你需要手工运行像这样的命令svn propget svn:mergeinfo,来确认代码是否被合并。所以,经常会发生有些分支被遗漏的情况。

      然而,处理Git 的分支却是相当的简单和有趣,你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支,你能简单而快捷的合并这些文件。

    4. Git 没有一个全局的版本号,而SVN有

      目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道,SVN的版本号实际是任何一个相应时间的源代码快照,它是从CVS进化到SVN的最大的一个突破。Git 可以使用SHA-1来唯一的标识一个代码快照,但这个并不能完全的代替SVN里容易阅读的数字版本号。

    5. Git 的内容完整性要优于SVN

      Git 的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性,确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这有一个很好的关于Git 内容完整性的讨论。(英文原文参考:diff


    CVS-SVN-GIT综合比较

    首先,介绍几个版本控制软件相互比较的重要依据:

    (1)版本库模型(Repository model):描述了多个源码版本库副本间的关系,有客户端/服务器和分布式两种模式。在客户端/服务器模式下,每一用户通过客户端访问位于服务器的主版本库,每一客户机只需保存它所关注的文件副本,对当前工作副本(working copy)的更改只有在提交到服务器之后,其它用户才能看到对应文件的修改。而在分布式模式下,这些源码版本库副本间是对等的实体,用户的机器出了保存他们的工作副本外,还拥有本地版本库的历史信息。

    (2)并发模式(Concurrency model):描述了当同时对同一工作副本/文件进行更改或编辑时,如何管理这种冲突以避免产生无意义的数据,有排它锁和合并模式。在排它锁模式下,只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下,用户可以随意编辑或更改文件,但可能随时会被通知存在冲突(两个或多个用户同时编辑同一文件),于是版本控制工具或用户需要合并更改以解决这种冲突。因此,几乎所有的分布式版本控制软件采用合并方式解决并发冲突。

    (3)历史模式(History model):描述了如何在版本库中存贮文件的更改信息,有快照和改变集两种模式。在快照模式下,版本库会分别存储更改发生前后的工作副本;而在改变集模式下,版本库除了保存更改发生前的工作副本外,只保存更改发生后的改变信息。

    (4)变更范围(Scope of change):描述了版本编号是针对单个文件还是整个目录树。

    (5)网络协议(Network protocols):描述了多个版本库间进行同步时采用的网络协议。

    (6)原子提交性(Atomic commit):描述了在提交更改时,能否保证所有更改要么全部提交或合并,要么不会发生任何改变。

    (7)部分克隆(Partial checkout/clone):是否支持只拷贝版本库中特定的子目录。

     

    名称

    版本库模型

    并发模式

    历史模式

    变更范围

    网络协议

    原子提交性

    部分克隆

    CVS

    Client-server

    Merge

    Changeset

    File

    Pserver,ssh

    No

    Yes

    SVN

    Client-server

    3-way merge, recursive

    merge, octopus merge

    Changeset and Snapshot

    Tree

    custom (svn), custom (svn) over ssh,

    HTTP and SSL (usingWebDAV)

    Yes

    Yes

    Git

    Distributed

    Merge or lock

    Snapshot

    Tree

    custom, custom over ssh, rsync,

    HTTP/HTTPS, email, bundles

    Yes

    No


    Trunk、Branches、Tags 区别:

    Trunk:软件开发过程中的主线,开发时版本存放的目录,即在开发阶段的代码都提交到该目录上,保存了从版本库建立到当前的信息。 

    Branches:软件开发过程中的分支,发布版本存放的目录,即项目上线时发布的稳定版本存放在该目录中,保存了从版本库的某一特定点(不一定是版本库建立时)到当前的信息。

    tags:表示标签存放的目录,tags只可读,不可写

    分支主要用于在不影响Trunk其它用户情况下进行一些关于新功能的探索性或实验性的开发,待新功能完善后它也可以合并到Trunk中。


    参考:http://javasogo.iteye.com/blog/1297008

                http://www.oschina.net/news/12542/git-and-svn

    展开全文
  • 1.git版本控制 1.1版本控制 版本控制的英文名称为(Version Control System),主要有以下几个作用。 记录文件的所有历史变化 错误恢复到某个历史版本 多人协作开发编辑同一个文件 1.2主流的版本控制产品 ...

    1.git版本控制

    1.1版本控制

    版本控制的英文名称为(Version Control System),主要有以下几个作用。

    • 记录文件的所有历史变化
    • 错误恢复到某个历史版本
    • 多人协作开发编辑同一个文件

    1.2主流的版本控制产品

    名称

    模型

    并发模式

    历史模式

    变更范围

    网络协议

    原子提交性

    CVS

    Client-server

    Merge

    Changeset

    File

    Pserver,ssh

    No

    SVN

    Client-server

    3-way merge, recursive merge, octopus merge 

    Changeset and Snapshot

    Tree

    custom (svn), custom (svn) over ssh, HTTP and SSL (usingWebDAV)

    Yes

    Git

    Distributed

    Merge or lock

    Snapshot

    Tree

    custom, custom over ssh, rsync, HTTP/HTTPS, email, bundles

    Yes

    * 版本库模型(Repository model):描述了多个源码版本库副本间的关系,有客户端/服务器和分布式两种模式。在客户端/服务器模式下,每一用户通过客户端访问位于服务器的主版本库,每一客户机只需保存它所关注的文件副本,对当前工作副本(working copy)的更改只有在提交到服务器之后,其它用户才能看到对应文件的修改。而在分布式模式下,这些源码版本库副本间是对等的实体,用户的机器出了保存他们的工作副本外,还拥有本地版本库的历史信息。

    * 并发模式(Concurrency model):描述了当同时对同一工作副本/文件进行更改或编辑时,如何管理这种冲突以避免产生无意义的数据,有排它锁和合并模式。在排它锁模式下,只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下,用户可以随意编辑或更改文件,但可能随时会被通知存在冲突(两个或多个用户同时编辑同一文件),于是版本控制工具或用户需要合并更改以解决这种冲突。因此,几乎所有的分布式版本控制软件采用合并方式解决并发冲突。

    * 历史模式(History model):描述了如何在版本库中存贮文件的更改信息,有快照和改变集两种模式。在快照模式下,版本库会分别存储更改发生前后的工作副本;而在改变集模式下,版本库除了保存更改发生前的工作副本外,只保存更改发生后的改变信息。

    * 变更范围(Scope of change):描述了版本编号是针对单个文件还是整个目录树。

    * 网络协议(Network protocols):描述了多个版本库间进行同步时采用的网络协议。

    * 原子提交性(Atomic commit):描述了在提交更改时,能否保证所有更改要么全部提交或合并,要么不会发生任何改变。

     

    简而言之,各有优缺点,git要配合hub,可以避免分布式损坏。svn有权限控制,避免全被clone走。git适合纯代码,svn适合综合性文档管理,结合起来就完美。显然最大的不同在于git是分布式的。

    1.3SVN

    优点:团队协作开发,代码集中化管理。

    缺点:单点故障,必须联网工作,无法单机本地工作。

    1.4介绍

    Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了。Linus虽然创建了Linux的核心,但Linux的壮大是靠全世界热心的志愿者参与的,这么多人在世界各地为Linux编写代码,那Linux的代码是如何管理的呢?

    事实是,在2002年以前,世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!你也许会想,为什么Linus不把Linux代码放到版本控制系统里呢?不是有CVS、SVN这些免费的版本控制系统吗?因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。不过,到了2002年,Linux系统已经发展了十年了,代码库之大让Linus很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。

    安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错!),于是BitMover公司怒了,要收回Linux社区的免费使用权。Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。实际情况是这样的:Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linux系统的源码已经由Git管理了!牛是怎么定义的呢?大家可以体会一下。

    Git迅速成为最流行的分布式版本控制系统,尤其是2008年,GitHub网站上线了,它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括jQuery,PHP,Ruby等等。历史就是这么偶然,如果不是当年BitMover公司威胁Linux社区,可能现在我们就没有免费而超级好用的Git了。

    1.5组成结构

     

    • 工作区:用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,拷贝的就是这里的数据。
    • 暂存区:保存了下次将提交的文件列表信息,一般在 Git 仓库目录中。有时候也被称作“索引”,不过一般说法还是叫暂存区域。
    • 版本库:也叫本地版本库,之所以说git 快,大部分提交都是对本地仓库而言的,不依赖网络,最后一次会推送的到远程仓库。
    • 远程仓库:可以看做是github,它是一个远程仓库,它提供web服务的 供大家方便下载、查看、提交、存储。文件的状态

    1.6文件的状态

           新建文件状态为untracked,add命令执行后状态变为staged,已存在的文件状态为unmodified,修改文件内容,文件状态变为modified,commit提交,文件状态编程unmodifed。

    1.7命令速查

    https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1498324567731&di=38c12e2cec3790708b3a2e350fe80eed&imgtype=0&src=http%3A%2F%2Fwww.114390.com%2Fupload_article%2Ffile_images%2Farticle%2F201409%2Fgit_big_jb51.jpg

    2本地命令

    2.1注册账号

    第一步:先官网注册账号:https://github.com

    第二步:下载安装文件:Git-2.12.0-64-bit.exe,一路next,安装完桌面右键菜单有下面两项,安装完成。选择Git Bash Here,进入git客户端。

     

     

    2.2配置身份信息

    提交文件时,就知道这个文件是谁提交的。出了问题,就知道谁干的!

    2.3查看配置信息

     

     

    2.4创建本地仓库

    D:\javaenv\git_repository

     

    2.5进入仓库

    Administrator@tonythink MINGW64 ~/Desktop
    $ cd d:                                #进入d盘
    Administrator@tonythink MINGW64 /d
    $ cd javaenv            
    $ mkdir git_repository          #创建目录
    $ cd git_repository             #进入目录

     

     

    2.6初始化仓库

    $ git init
    Administrator@tonythink MINGW64 /d/javaenv/git_repository (master)

    当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。如果你没有看到.git目录,是因为默认这个目录是隐藏的,要显示修改其显示隐藏文件即可,一般无需修改。

     

     

    2.7git的工作流程

    1. 克隆仓库
    2. 在工作目录中新增、修改、删除文件
    3. 暂存文件,将文件的快照放入暂存区
    4. 提交更新,把暂存区的内容提交到Git仓库中

     

    2.8提交文件

    创建hi.txt
    $ git add hi.txt                    #暂存单个文件
    $ git add ./*                       #批量暂存当前目录下所有内容
    $ git status                        #查看文件状态
    $ git commit -m "test"              #提交
    [master (root-commit) e522732] test
     1 file changed, 1 insertion(+)
     create mode 100644 hi.txt
    $ git status                        #查看文件状态

     

     

    2.9查看提交记录

    $ git log
    commit e522732d94c440fdd750368ce937ac1c40dbd2ed    #本次提交唯一标识,对于版本回退非常有用
    Author: nutony <52399178@qq.com>
    Date:   Fri Jun 2 09:39:31 2017 +0800
    
        test

     

     

    2.10比较当前文件和仓库文件

    修改hi.txt文件内容,然后和仓库中已经提交的hi.txt比较

    $ git diff hi.txt
    diff --git a/hi.txt b/hi.txt
    index 32f95c0..d7d0f3f 100644
    --- a/hi.txt
    +++ b/hi.txt
    @@ -1 +1 @@
    -hi
    \ No newline at end of file
    +<B1>Ƚϵ<B1>ǰ<CE>ļ<FE><BA>Ͳֿ<E2><CE>ļ<FE> #中文乱码
    \ No newline at end of file
    
    Administrator@tonythink MINGW64 /d/javaenv/git_repository (master)
    $ git diff hi.txt
    diff --git a/hi.txt b/hi.txt
    index 32f95c0..2b80830 100644
    --- a/hi.txt
    +++ b/hi.txt
    @@ -1 +1 @@
    -hi
    \ No newline at end of file
    +<U+FEFF>比较当前文件和仓库文件              #文件格式改为UTF-8即可
    \ No newline at end of file

     

     

    2.11add和commit的区别

    Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

    git的文件状态

    文件新建完状态为untracked

     

     

    2.12文件状态图

     

    展开全文
  • 版本控制工具汇总

    2018-07-09 16:05:22
    简介 工具 重点 Diff Checker 可以查看文件的修改情况 mvnrepository 查询maven的gav信息一类的

    简介

    工具

    重点

    展开全文
  • 版本控制工具 什么是版本控制工具版本控制工具提供完备管理功能,用于存储,追踪目录和文件的修改历史,是软件开发者的必备工具。 版本控制工具的最主要功能就是追踪文件的变更。它将什么时候,什么人更改的文件...
  • SVN是Subversion的简称,是一个开放源代码的版本控制系统,相较于RCS、CVS,它采用了分支管理系统,它的设计目标就是取代CVS。 二、SVN的下载安装 下载地址:https://tortoisesvn.net/downloads.zh.html 安装完...
  • 常见的版本控制管理工具

    万次阅读 2016-05-23 17:19:20
    常见的版本控制管理工具 出处:http://blog.sina.com.cn/s/blog_5f0e9ca50102v63c.html 配置管理工具是配置管理相关理论的实践载体,工具的功能范围在某种程度上可以直接影响一个组织中配置管理水平的高低...
  • 版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理,是软件配置管理的核心思想之一。 编写一个成熟可用的程序是一个工作量很大的工程,并非我们一次性就可以搞定的工作,所以在开发...
  • 各种版本控制工具的对比

    千次阅读 2018-02-23 18:23:33
    1.集中式版本控制工具 有 SVN, CVS, ClearCase 集中式版本控制工具,版本库是集中存放在中央服务器的,team里每个人work时从中央服务器下载代码,是必须联网才能工作,局域网或互联网。个人修改后然后提交到...
  • IDEA配置GIt版本控制工具在配置之前,需要先说明的是本机已经安装好了git版本控制工具。在菜单上上选择File,在下拉菜单上选择Settings在左侧列表中选择Version Control,在下面选择Git选择git安装目录中的bin目录下...
  • 一、版本控制工具的作用和必要性 所谓版本控制系统(Version Control System),从狭义上来说,它是软件项目开发过程中用于储存我们所写的代码所有修订版本的软件,但事实上我们可以将任何对项目有帮助的文档交付版本...
  • 版本控制工具:SVN和Maven的区别

    千次阅读 2017-05-16 18:37:59
    构建工具—maven,版本控制工具—svn。 一、只有svn的情况   首先考虑没有maven的情况。这样的话,项目组每个开发人员,都需要在本地check out所有的源码。 每次提交之前,需要先更新周边工程的代码。...
  • git是一款很火的版本控制工具,在团队工作中,我们经常使用这个工具,下面给大家分享下git的使用方法首先去官网下载:https://git-scm.com/download安装成功后点击鼠标右键会多出两个选项Git GUI Here和Git Bash ...
  • Git 是一个分布式版本控制工具

    千次阅读 2016-08-04 11:28:20
    Git 是一个分布式版本控制工具前言:Git常用命令: 速查手册Git — The stupid content tracker(傻瓜内容跟踪器),Linus 是这样给我们介绍 Git 的。 Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制...
  • 版本控制工具是开发中必不可少的,常见的以及常使用的版本控制工具有git和svn。git是典型的分布式版本控制工具,不需要网络也可以提交代码,即每个设备都是一个仓库。svn是典型的集中式版本控制工具,即需要一个中心...
  • 现象,近年来,我们对版本控制工具的关注点似乎正在改变.起初,我们主要也是唯一的目的就是对代码进行监控,使我们能够安全的返回到旧的版本,以便我们能够诊断代码中的问题.后来,我们的关注点更侧重于如何使人与人之间的...
  • 版本控制工具VSS使用介绍

    千次阅读 2014-10-11 21:51:46
    什么是版本控制? 1.怎样对研发项目进行整体管理  ...2.项目开发小组的成员之间如何以一种有效的机制进行协调  ...3.如何进行对小组成员各自承担的子项目的统一管理  ...6. 对在研发过程中形成的软件...版本控制工具
  • 作为一名优秀的程序猿,怎么能不会使用版本控制工具(然而我就不会)? SVN,英文名Subversion,一款很棒的开源版本控制系统,采用分支管理的模式且拥有众多IDE支持,比如Eclipse,MyEclipse,Android Studio等等等...
  • 废话不多说,今天小编手把手教你使用svn版本控制工具,包括服务端和客户端的配置。下载连接:一、首先配置服务端:1 安装服务端软件如上图msi文件安装。安装完成后,打开命令提示符 输入 svn 如下则成功,如不成功...
  • 最好用的Unity版本控制工具

    千次阅读 2016-11-12 12:57:06
    自从来到现在的公司,负责Unity组开发以来,尝试了各种版本控制工具。从一开始的TortoiseSVN,到后来为了追求逼格使用Git,尝试了Github客户端和SourceTree,发现都有各种不爽。最后,发现还是Unity的亲儿子Asset ...
1 2 3 4 5 ... 20
收藏数 641,312
精华内容 256,524
关键字:

版本控制工具