Git Tool Part 1

  1. 云栖社区>
  2. 博客>
  3. 正文

Git Tool Part 1

科技小能手 2017-11-13 15:34:00 浏览996
展开阅读全文

    最近来了一些newguys,版本控制工具全部开始迁移到Git上来.原来都是老CVS或SVN的用户. 所以打算把内部Wiki上比较两篇粗糙Git的入门文章操作重写一遍.在本篇中全面解析git概念和基础使用方法.

    在写的这篇文章时.在思考.应该如何快速切入理解Git的基本使用?相对Linux操作系统下分布式版本控制工具.很多操作中都直接采用命令的方式来做.可更多Windows 开发人员习惯的是直观的用户操作界面.复杂的指令是Git在Linux本身具有的特点.而Windows 上UI不足也可以使用工具加以弥补.图形化工具(无论是 git extentions ,还是TortoiseGit),都只不过是命令行的封装。就功能而言,命令行全部可以做到;但命令行能做的,他们不一定可以做到。命令行更加原生、本色,跨越平台之间局限.

    so。本篇就以git 命令行操作方式逐步切入.至于一些图形化工具会在下篇讲到.

    Git—The Stupid Content Tracker-俗称傻瓜内容跟踪器.Linus Benedict Torvalds-Linus之父在官方的Wiki中自嘲的取了这个名字.官方给出解释如下:

 I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.
 

    Git最初是用于Linux内核开发的一个版本控制工具.从2002年起,Linux 内核一直使用BitKeeper来进行版本管理,但是在2005年BitKeeper和Linux 内核开源社区的合作关系结束,BitKeeper再也不能免费使用了,这迫使Linus决定开发一个开源界自已的版本控制系统.与常用的版本控制CVS、Subversion等均不同.它采用分布式的版本库控制方式.相对于CVS或SVN. Git并不需要服务器端软件的支持.Git的速度很快.它的本地操作速度和本地文件系统在一个级别,远程仓库的操作速度和SFTP文件传输在一个级别.至于如何实现的可以看看Git内部实现机制.Git is the next Unix.这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪[merge tracing]能力.

    Git最初的开发动力来自于BitKeeperMonotone[2][3]。 Git最初只是作为一个可以被其他前端比如Cogito 或 StGIT[4]包装的后端而开发的。不过,后来Git内核已经成熟到可以独立地用作版本控制[5]。很多有名的软件都使用Git来进行版本控制[6],其中有Linux内核X.Org服务器OLPC内核开发.

    其实如果你是一个原来使用过CVS到SVN.或是也经历从VSS迁移到TFS.你会发现版本控制管理模式从集中向分散演变.这也是因为现在的很多开发团队变得越来越分散,原来微软的Visual SourceSafe和Team Foundation Server这样的集中式源代码控制系统很难保持其吸引力.而Git作为分布式版本控制工具.逐渐在.NET 社区开始广泛使用.

    了解Git一些基础概念.如下篇幅来了解Git在实际项目中使用.在使用Git之前需要安装对应Git工具.相对于Windows 平台.可选安装软件有两个:

Windows 安装工具:

Windows平台有两个模拟*nix like运行环境的工具:cygwinmsys;Git在cygwinmsys下都有相应的移植版本.工具下载:

TortoiseGit-[http://code.google.com/p/tortoisegit/downloads/list]

Msysgit-[http://code.google.com/p/msysgit/downloads/list]

注:前者是与Windows 资源管理器整合的Git管理工具.后者是Git的功能软件.个人觉得msys平台下的msysGit最好用.推荐使用. 


 
 

    本篇Git操作演示均采用MsysGit工具.安装过程没什么可提的.在设置Git Setup时:

    由于windows平台的换行符(CRLF)和Linux(*nix)平台的换行符(LF)不同,那么在windows下开发最好选“Checkout as-is, commit as-is”这个选项,这样,Git就不会修改你代码的换行符风格。

    安装完成后需要配置Git.在Linux下,可以在命令行里直接使用git config进行配置, 而在windows下则要先打开“Git Bash”,进入msysGit命令行界面,再用git config命令进行相应的配置操作.打开Git Bash.首先需要配置的UserName用户名和Email.这回在每次Git操作日志出现: 

    Git的配置信息分为全局和项目两种,上面命令中带了“--global"参数,这就意味是在进行全局配置,它会影响本机上的每个一个Git项目.为了演示目的这里首先建立一个用来测试操作的仓库,首先在默认路径下创建一个仓库目录.并在该目录下创建一个仓库: 

    mkDir创建一个测试仓库目录demogitdir,Cd 则是进入该目录. git init 指令在当前目录下创建一个测试操作的仓库.有了可操作的仓库.可以添加一个任意内容的文件到仓库并提交:

    echo 则是把”hello git tool”内容写入到sayhello.txt文件中. git add则是把该文件添加暂存区. 通过git commit指令则提交到默认的当前的仓库中.可以通过Git Log查看当前的提交记录.也可以在记录中看到Git设置的用户名和Email.:

    在log能看到Commit 后根据一段“8223db3b064a9826375041c8fea020cb2e3b17d1” SHA1串.Git通过对提交内容进行 SHA1 Hash运算,得到它们的SHA1串值,作为每个提交的唯一标识。根据一般的密码学原理来说,如果两个提交的内容不相同,那么它们的名字就不会相同;反之,如果它们的名字相同,就意味着它们的内容也相同.现在修改一下刚创建的文件内容 并提交到仓库中,在来查看该文件与第一个保存版本之间存在的不同:

    在原来基础上添加字符串chenkai modify.这时可以提交并查看当前git 状态和日志.有具体的库.在回过头看看GitConfig具体的配置.在Git bash中可以通过cat /Head指令获取当前库GitConfig中配置 比如获取刚才设置用户名和Email:

    很多刚操作对git config配置不熟悉.可以直接找到对应根目录下GitConfig文件直接修改也可以达到同样的效果.当然也可以通过git config –list获取全部配置信息.

    通过如上Git 一些指令操作是即使你不了解Git原理前提下 是否有了一个感性的认识.如下来挖掘Git设计原则和工作原理.

    其实要理解Git这个版本控制工具由来过程.以及演变到今天具有分布式特点.从版本控制最原始角度来分析.它突显特点最容易理解的角度.开发人员最容易在使用工具往往注重学会它如何去使用 而忽略这些建立功能背后所解决问题.如果我们能够从Git本身设计原则上看到解决问题.就自然会理解Git版本工具优势特点在哪里.才不会在使用过程纯粹为了使用Git而学习.同样要在使用过程中理解其演变过程.知其所以然.用起来才能游刃有余.

什么是版本控制?

版本控制是一种记录若干文件内容变化,以便将来查阅特定版本修订情况的系统

   严格意义来说版本控制文件可以是任何文本文件.而我们突出是对源代码文本文件版本控制管理.

    在最原始版本控制中.习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别.这样的方式很简单.但存在问题也不少.容易混淆工作目录.版本之间没有交互实现版本指教差异跟踪等.未解决这个问题在最开始设计多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异,具体构成:

 

    最流行的一种叫做 rcs,现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后,也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁(patch)。文件补丁是一种特定格式的文本文件,记录着对应文件修订前后的内容变化。所以,根据每次修订后的补丁,rcs 可以通过不断打补丁,计算出各个版本的文件内容。这个特点甚至影响后来的CVS和SVN设计.现在依然能够在SVN中看到,版本之间需要作出补丁包.

    虽然解决了能够通过数据控制版本之间变化.但在实际操作又要面对新问题-如何让在不同系统上的开发者协同工作?于是,集中化的版本控制系统( Centralized Version Control Systems,简称 CVCS )应运而生。这类系统,诸如 CVS,Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法,结构成图:

这种做法的好处是:

相较于老式的本地 VCS 来说。现在,每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库轻松容易得多 

坏处以及遗留难以处理的问题是:

 最显而易见的缺点是中央服务器的单点故障。若是宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。如果中央服务器的磁盘发生故障,并且没做过备份或者备份得不够及时的话,还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录,被客户端提取出来的某些快照数据除外,但这样的话依然是个问题,你不能保证所有的数据都已经有人提取出来。本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新信息的风险.

    well.新的需求出现总是不断推动新的工具推出.紧接着.为了解决集中化版本控制中存在种种问题.同时继承原有的特点.分布式版本控制系统( Distributed Version Control System,简称 DVCS )面世了。在这类系统中,诸如 Git,Mercurial,Bazaar 还有 Darcs 等,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份,结构分析截图:

    well 有了Git这种分布式工具.许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程,比方说层次模型式的工作流,这在以前的集中式系统中是无法实现的.

    从05开始其Linux开源社区为了不重蹈覆辙.决定基于Linux操作系统开发一个新版版本控制工具.就是我们今天见到的Git.当时开发团队对Git工具 设计目标作了如下的设想:

Git 设计目标:

  • 速度
  • 简单的设计
  • 对非线性开发模式的强力支持(允许上千个并行开发的分支)
  • 完全分布式
  • 有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)]

    从05年至今.经过Linux开源社区推动.Git逐渐成熟.同时对演变对其他Windows MAC平台支持.

    其实很多人从CVS或是SVN过渡而来的用户,在使用指令操作方式依然能够粗类旁通.其实在原理层次2者之间并无可比性.反而从SVN过来而来用户在理解总是存在一个对比的概念.Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的具体差异。这类系统(CVS,Subversion,Perforce,Bazaar 等等)每次记录有哪些文件作了更新,以及都更新了哪些行的什么内容,构图吐下: 

    而Git在对基本文件操作完全不同.Git 并不保存这些前后变化的差异数据。实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件没有变化,Git 不会再次保存,而只对上次保存的快照作一连接。Git 的工作方式如下: 

    这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路,并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统,但它同时还提供了许多以此为基础的超强工具,而不只是一个简单的 VCS.

    因Git在底层的设计.本身具有的操作特点也不同于其他版本控制工具.具体表现如下几点.

A:所有操作几乎在本地运行.

    Git 中的绝大多数操作都只需要访问本地文件和资源,不用连网。但如果用 CVCS 的话,差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有有关当前项目的历史更新,所以这也就不难解释Git的处理起来速度飞快特点.

    Git这点能让开发人员.在大的项目结构下.随时随地在不用连接服务器的情况下查看版本之间差异.而不是采用SVN的方式通过请求服务器端运算获取差异.引文每次版本更新都能够拿到本地存在最新代码的快照.以后所有的操作都可以基于本地的Code进行.而无需请求服务器端.

    这样一来可以让开发人员随意修改本地的Code.在存在网络的情况时通过Push操作吧更改上传远程的镜像上.换作其他版本控制系统,这么做几乎不可能,抑或非常麻烦,例如:Subversion 或 CVS,虽然可以编辑文件,但无法提交更新,因为数据库在网络上.

B:时刻保持数据完整性

    在保存到 Git 之前,所有数据都要进行内容的校验和(checksum)计算,并将此结果作为数据的唯一标识和索引。换句话说,不可能在你修改了文件或目录之后,Git 一无所知。这项特性作为 Git 的设计哲学,建在整体架构的最底层。所以如果文件在传输时变得不完整,或者磁盘损坏导致文件数据缺失,Git 都能立即察觉.

    Git 使用 SHA-1 算法计算数据的校验和,通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值,作为指纹字符串。该字串由 40 个十六进制字符(0-9 及 a-f)组成,看起来就像是:

 1:  24b9da6552252987aa493b52f8696cd6d3b00373

    Git 的工作完全依赖于这类指纹字串,所以你会经常看到这样的哈希值。实际上,所有保存在 Git 数据库中的东西都是用此哈希值来作索引的,而不是靠文件名

C:多数操作仅仅添加数据

    常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作,比如删除数据,要回退或重现都会非常困难。在别的 VCS 中,若还未提交更新,就有可能丢失或者混淆一些修改的内容,但在 Git 里,一旦提交快照之后就完全不用担心丢失数据,特别是在养成了定期推送至其他镜像仓库的习惯的话。

    这种高可靠性令我们的开发工作安心不少,尽管去做各种试验性的尝试好了,再怎样也不会弄丢数据.

D:Git文件中三种状态

    接下来要讲的概念非常重要。对于任何一个文件,在 Git 内都只有三种状态:已提交(committed),已修改(modified)和已暂存(staged)。已提交表示该文件已经被安全地保存在本地数据库中了;已修改表示修改了某个文件,但还没有提交保存;已暂存表示把已修改的文件放在下次提交时要保存的清单中。

    由此我们看到 Git 管理项目时,文件流转的三个工作区域:Git 的工作目录,暂存区域,以及本地数据目录:

    每个项目都有一个 git 目录,它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要,每次克隆镜像仓库的时候,实际拷贝的就是这个目录里面的数据。

    从项目中取出某个版本的所有文件和目录,用以开始后续工作的叫做工作目录。这些文件实际上都是从 git 目录中的压缩对象数据库中提取出来的,接下来就可以在工作目录中对这些文件进行编辑。

    所谓的暂存区域只不过是个简单的文件,一般都放在 git 目录中。有时候人们会把这个文件叫做索引文件,不过标准说法还是叫暂存区域。

基本的 Git 工作流程如下所示:

  1. 在工作目录中修改某些文件。
  2. 对这些修改了的文件作快照,并保存到暂存区域。
  3. 提交更新,将保存在暂存区域的文件快照转储到 git 目录中。

    所以,我们可以从文件所处的位置来判断状态:如果是 git 目录中保存着的特定版本文件,就属于已提交状态;如果作了修改并已放入暂存区域,就属于已暂存状态;如果自上次取出后,作了修改但还没有放到暂存区域,就是已修改状态.

    其实如上三种装当你在每次从创建文件到提交文件整个过程.一旦执行一条命令都可以通过Git Status来查看当前文件的状态.就能够很清晰扑捉到一个文件从创建到提交过程在Git版本状态的变化过程.我就不在此演示了. 

    着重写本篇主要目的是为了在使用Git解惑.清楚了解Git之前整个版本管理工具演化过程.以及相对其他版本工具Git自身具有的特点.和工作原理.重要性不言而喻. 就像很多开发人员强迫自己学习GOF 23种模式一样.大多的人只是关注如何快速熟练的使用GOF每种模式.力求使用能够精通.我们愿景是能够遇到问题时能够采用前人经验去解决.可惜是现实中使用效果总是与我们设想效果差很远.原因很简单.很多开发人员学习玩GoF 23模式后在碰到问题往往反而更迷茫了.因为他不知道采用哪种模式来解决问题最简单.或是换句话我们只是知道 了解 并熟练掌握GOF模式使用而忽略GOF模式本身的价值.具体解决什么样问题. 适用在什么问题场景最合适?这是否对学习对强迫自己学习GOF的同学是一种悲哀呢/.

    学习GIT也是如此.不要陷入细节的海洋无法自拔.在处理问题上.多一点全局的观念.往往能够带来更多思考.至少我们能确定做事方向和路线是对的.有些开发人员往往从事行业多年.却对很多专业技术都是略知.说白在建立自身知识系统完整性缺乏. 这也是产生所谓行业多了很多”IT民工”角色 而少了真正的创新原因之一.

    这种现象是否值得我们去反思这种问题的现状呢?



本文转自chenkaiunion 51CTO博客,原文链接:http://blog.51cto.com/chenkai/763016

网友评论

登录后评论
0/500
评论
科技小能手
+ 关注