Git Tool Part 1

longpan

　　最近来了一些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最初的开发动力来自于BitKeeper和Monotone[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运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本.工具下载：
　　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 工作流程如下所示：

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

　　所以，我们可以从文件所处的位置来判断状态：如果是 git 目录中保存着的特定版本文件，就属于已提交状态；如果作了修改并已放入暂存区域，就属于已暂存状态；如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态.
　　其实如上三种装当你在每次从创建文件到提交文件整个过程.一旦执行一条命令都可以通过Git Status来查看当前文件的状态.就能够很清晰扑捉到一个文件从创建到提交过程在Git版本状态的变化过程.我就不在此演示了.

　　着重写本篇主要目的是为了在使用Git解惑.清楚了解Git之前整个版本管理工具演化过程.以及相对其他版本工具Git自身具有的特点.和工作原理.重要性不言而喻. 就像很多开发人员强迫自己学习GOF 23种模式一样.大多的人只是关注如何快速熟练的使用GOF每种模式.力求使用能够精通.我们愿景是能够遇到问题时能够采用前人经验去解决.可惜是现实中使用效果总是与我们设想效果差很远.原因很简单.很多开发人员学习玩GoF 23模式后在碰到问题往往反而更迷茫了.因为他不知道采用哪种模式来解决问题最简单.或是换句话我们只是知道 了解 并熟练掌握GOF模式使用而忽略GOF模式本身的价值.具体解决什么样问题. 适用在什么问题场景最合适?这是否对学习对强迫自己学习GOF的同学是一种悲哀呢/.
　　学习GIT也是如此.不要陷入细节的海洋无法自拔.在处理问题上.多一点全局的观念.往往能够带来更多思考.至少我们能确定做事方向和路线是对的.有些开发人员往往从事行业多年.却对很多专业技术都是略知.说白在建立自身知识系统完整性缺乏. 这也是产生所谓行业多了很多”IT民工”角色 而少了真正的创新原因之一.
　　这种现象是否值得我们去反思这种问题的现状呢?