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

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

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

<1>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内核开发.

<2>Git基础使用

其实如果你是一个原来使用过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设计原则和工作原理

<3>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平台支持.

<4>Git构建原理

其实很多人从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版本状态的变化过程.我就不在此演示了.

<5>Git基础概念小结

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

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

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

针对Git的使用.在Git中文操作指南手册中.讲解大量关于GiT的细节操作.可是对于从SVN或是TFS转换的很多开发人员来说.很多并没有更多学习周期时间.那么如何才能短时间内抓住Git核心枝干.短时间内快速进入Git并在代码中集成使用工具呢.? 由于Git中富含大量的Git 命令.细节太多.本来打算在本篇中介绍一些Git通过命令的方式基本操作.等写了大概四分之一.发现完全和最初写这篇文章初衷完全背离了.

其实本篇的目的很简单.与其陷入在在长长的篇幅中介绍Git Command基本用法 还不如直接采用Windows 平台开发人员最熟悉的GUI界面工具操作更为直观.Git原理理论和操作用法也是非常系统.如果你觉得有必要建立一个系统知识结构.当然也有很好的资源可以当做日常查看手册:

Git 系统资源:

Git中文操作指南 Download Link[http://vdisk.weibo.com/s/1UJq4]

Git Command指令在线文档: [http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/index.html]

<<Git Community Book中文版>>：[http://gitbook.liuhui998.com/]

注:如上在线文档或图书版权源作者拥有.本文只是添加引用.如转载请注明出处.

作为Windows 平台开发人员最常用的开发工具莫过于Visual Studio系列.但是可惜的Git作为从Linux平台的舶来品..NET开发人员更习惯于使用用户界面，所以在进行日常任务的时候更习惯使用操作基于具有IDE的界面.

作为一个Visual Studio用户.在使用Visual SouceSafe/Team Foundation Server、Subversion或甚至Mercurial的过程中.已经建立了使用源码控制习惯.更多的开发人员希望在Solution解决方案目录中就直观看到自己的SouceCode被版本管理工具所控制着.无论在代码修改或添加都能直接获得状态反馈.所以在Visual Studio使用Git需求就一直成为Git一块”硬伤”.

如何在Visual STudio系列开发工具中使用Git版本控制工具?

<1>Visual Studio 构建Git部署环境

Well，谈到这里在上章节中Git Tool Part 1中提到能够适用Windows 平台的Git工具主要具有两个模拟*nix like运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本.不过就使用体验来说个人觉得msys平台下的msysGit最好用.在GUI图形工具上有Git extentions ，还是TortoiseGit.更加倾向于前者.

Linux开源社区也考虑到很多Windows平台开发人员的需求.在后来工具支持上推出可以Visual Studio系列开发工具集成Git版本控制系统 插件-Gitextensions.这是目前Visual Studio系列开发工具唯一支持Git具有GUI操作界面的插件.

至此在Visual Studio IDE开发工具构建Git版本控制工具组合就诞生了:

Visual Stuido Git版本控制工具组合:

Git 命令行(MsysGit) + Git Extensions + Git Source Control Provider [Only Support Visual Studio 2010]

Git 命令行一般采用BitBash工具来直接采用命令操作.

Git Extensions：则是直接Visual Studio 开发工具中集成Git GUI操作工具.

Git Souce Control Provider:为Visual STudio 提供Git版本控制支持.

首先安装MsysGit可以在[http://code.google.com/p/msysgit/]下载到最新的FullInstall版本.安装步骤请参考GitHub上Wiki[https://github.com/msysgit/msysgit/wiki/InstallMSysGit].默认编辑工具是Vim/

因Git Extensions工具是基于Git 命令行,可以在安装MsysGit之后通过[http://code.google.com/p/gitextensions/]下载安装;在安装过程中因已经安装MsysGit版本[可选也可不选].所以只需选择集成KDiff3工具即可:

另外关于Git Extension传输协议 选择:

OpenSSH 客户端，提供 Git 访问 ssh 协议的版本库.Git自身支持多种协议.在此选择默认安装OpenSSH.在GitExtension安装完成后.通过Start->Git Extension安装目录.打开Git Extension.找到Setting设置设置选项页Git:

一般情况如果安装顺序没有问题.安装Git Extension工具后都会自动找到对应Git命令行工具安装路径,git命令行工具有两种，一种是 cygwin 下命令行，一种是 msysGit 命令行，git extensions 可以配置使用哪一种命令行工具。因Git Extension是基于命令行操作的.在执行请检查该设置是否指向正确Git命令行安装工具路径

最后需要安装Git Source Control Provider,打开Visual STudio 2010开发工具.找到Tools->Extension Manager选择Online Gallery选项页搜索:Git Source Control Provider 看到：

下载安装.当然也可以不用打开Visual Studio 也可以通过[Git Source Control Provider]地址直接下载安装即可.安装完成后找到Tools->Options->Souce Control选项中把Git Souce Control Provider作为默认版本控制工具:

至此在Visual Studio 2010搭建好了Git版本控制需要环境.

<2>Git在Visual Studio 基本操作

构建好Git在Visual Studio 2010开发工具版本控制.通过一个具体的Windows phone Application 来演示一下Git基本操作，首先在硬盘上开辟一个独立的文件夹CodeDevelopment：在该项目源码放在该目录下 新建解决方案如下.看看初始状态：

在初始状态下并没有继承Git版本控制.如果在Setting目录下设置Git.可以通过右键点击文件可以看到Git操作的选项:

如要对某个项目执行Git版本控制管理.只需到此项目所在的目录创建一个仓库.也就是Git-New Repotiory操作，执行完成后能在项目目录下看到多了Git文件目录:

初始化后，在当前目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。不过目前，仅仅是按照既有的结构框架初始化好了里边所有的文件和目录，但我们还没有开始跟踪管理项目中的任何一个文件.和.git同处一个目录的所有文件，现在就纳入了这个版本库的范围之内.可以在改目录下执行Git命令.也能够看到Visual STudio多了两个View窗口:

当创建完一个仓库发现解决方案的代码文件并没有类似SVN或TFS发生状态变化-即通过文件前小图标标识状态.不知道为何这可能Git Extension一个Bug.这时只有通过重启VS工具才能看到文件跟踪的状态:

well.是否可TFS和SVN体验一致.Well来看看库当前状态右键点击项目找到Git->GitBesh通过Git指令:Git Status执行

这说明你现在的工作目录相当干净。换句话说，当前没有任何跟踪着的文件，也没有任何文件在上次提交后更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在的分支是 master，这是默认的分支名称.在没有进入代码修改之前.可以提交解决方案最原始的版本.通过右键点击解决方案找到Git->Commit执行第一次版本提交:

执行后看到Commit页面,因现在文件都没有添加到Git暂存区.所以如果直接提交会提示：

所以在执行操作之前可以把所有文件添加到Git暂存区，添加MEssage 直接提交:

点击提交Commit按钮 提交成功:

现在在代码修改Mainpage页面PageTitle为chenkai.后再次提交.就能直接看到修改的差异:

关于我们创建没有做任何操作直接执行提交操作时提示. 其实是说明Git在执行提交操作必要的流程.在工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新，已修改或者已放入暂存区。而所有其他文件都属于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区域.文件在整个Git版本控制状态周期：

Git的暂存区是在版本未在提交之前存储位置.从上图可以看出.整个提交流程目录变化位置:工作目录->暂存区->版本库.暂存区的目的相当于实际编码和真正提交到Git执行版本追踪之间一个缓冲地带.这有什么好处呢.?很简单.暂存区的文件可以任意的在工作目录和版本库实现自由的交互.这样设计目的用户在操作过程可能会出错.暂存区也就给了用户撤销原来操作的可能.在文件没有进行任何操作之前一般通过Git Add指令吧文件添加到暂存区.在执行Commit操作时文件状态就有暂存区提交成为Git版本受控制的版本库中

在Commit页面可以看到一个键便捷的操作:

实现从工作目录到暂存区文件批量操作.其实Stage的操作内部封装就是Git add指令.当然也可以通过AddFiles 执行这种批量操作:

当然在Git中执行提交操作依然可以跳过暂存区操作.尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交：这就是从工作目录->版本库直接操作.可以打开命令行:

可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添改和删改过.提交成功后.看一下文件状态:

由原来的加号变锁.标识当前所有的文件已经第一次提交到版本库.如果当前再次修改MainPage.xaml则可以看到文件状态发生改变:

红色对勾标识当前文件已经发生了修改.而浅黄色的感叹号.标识当前文件状态由工作目录已经存放暂存区等待提交.假如我们在正常编译操作.执行多次提交.可能某一次版本提交时会出现手工操作失误.比如在这次版本提交以往提交某些文件，或是忘记修改某些文件.可能需要撤消刚才所做的某些操作,请注意，有些操作并不总是可以撤消的，所以请务必谨慎小心，一旦失误，就有可能丢失部分工作成果。可以使用 --amend 选项重新提交.:

1: $ git commit --amend

令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，而所提交的文件快照和之前的一样,如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 --amend 提交:

1: $ git commit -m 'initial commit' 2: $ git add forgotten_file 3: $ git commit --amend

ok.现在修改MainPage.xaml。在把这个文件追加上一个版本中添加Add Files操作后执行Git命令如下:

well顺利提交.有时我们通过Git Extension集成的命令通过Add Files 方式把当前所有工作的目录的文件添加到暂存区.也就是添加Git版本跟踪. 可能为了减轻操作的负担.对于有些应用程序编译中自动生成的文件.类似日志.或编译的文件并不需要Git版本管理.需要把这些文件从暂存区剔除掉.取消暂存区文件.可以执行如下Git命令:

1: git reset HEAD <file文件名称>...

在我们执行提交多次可以Git Extension中查看提交的版本.当然也可以通过命令Git Log方式查看同样的效果:

可以看到最后一次提交版本Message.总共提交三次版本.当然也可以在Git History看到图形化的提交历史版本:

当我们修改完成之后.在编辑过程达到一个满意的过程.,git 是分布式版本系统，都有一个 git 版本库的拷贝，为了和远程其他版本库同步，需要进行同步操作.同步操作一般分为拉取pull.另外一个推送Push.针对Git的服务器.如果比较大的组织结构可以企业内部构建自己的Git服务器.如果是小型团队.完全没有必要这么麻烦.现在依然很好第三方托管服务类似GitHub.

首先需要建立一个GitHub账号.就不多说了打开后能看到操作流程如下:

因已经配置过Git环境.所以直接创建一个Create Repository：

填写项目名称.描述和HomePage是可选项.当然最关键是可以设置GitHub托管的项目是否公开或私密状态.创建库Repository完成可以看到具体操作Git指令的流程如下:

首先需要见车Git Bash是否设置对应的全局的用户名和Email:

设置完成后需要在GitHub针对托管的项目添加一个公钥，如果没有公钥则可以通过Bit Extension工具自动生成一个匹配的公钥和私钥文件并保存在本地,带卡Bit Extension 找到：

打开操作General 生成一对公私密钥,并保存本地硬盘目录中:

保存上面的公钥字符串和公钥key文件为public文件，密钥为private.ppk文件.保存完成后需要到GitHub控制面版页面把该公钥添加上去:

添加成功后.在指令操作流程页面就可以GitHub对外公开该项目访问路径:git@github.com:chenkai/GitBaseOperator_Demo.git,对于Github上对外访问路径格式一般是：一般是 git@github.com:yourName/yourProject.git 格式. 这时我们可以把已经修改的应用程序通过Visual Studio 中Git Push到GitHub上:

这时会提示一个窗体:

首先点击Manage添加默认的添加项目信息. 找到 Default Pull:

添加远程的Github项目信息.并save，在选择Remote REspositories设置对应项目Reposity的基本信息并Save:

关闭窗体回到Push主页面就会看到对应默认项目是BitBaseOperator_Demo.ok此时点击Push开始推送代码到Github上:

确定.在调用Git.Exe是需要允许其对外访问输入yes:

开始推送 如果提示出错类似如下:

提示当前权限不允许操作.远程连接中断.好吧这个问题折腾我好久.后来在官方社区看到解决方法.其实这主要是GitBash通过cmd命令进入命令行输入界面的。正确的操作是，在git附带的bash（GitBash可以在开始菜单的git目标里面找到）里面运行命令，就可以一切正常。当然如果觉得这种界面操作麻烦也可以根据官方给出的纯指令的方式操作吧代码Push到GitHub上操作流程如下或是参加如下小白解决方案[ttp://help.github.com/win-set-up-git/]:

github的官方文档

#1. Check for SSH keys.

$ cd ~/.ssh

#2. Backup and remove existing SSH keys.

$ lsLists all the subdirectories in the current directory

$ mkdir key_backupmakes a subdirectory called "key_backup" in the current directory

$ cp id_rsa* key_backupCopies the contents of the id_rsa directory into key_backup

$ rm id_rsa*

#3. Generate a new SSH key.

$ ssh-keygen -t rsa -C "your_email@youremail.com"

#4. Add your SSH key to GitHub.

#5. Test everything out.

$ ssh -T git@github.com

Git Bash中执行push令如下:

Push指令：$ git remote add origin git@github.com:testinguser/yourproj.git
$ git push origin master 在实际操作还有另外一种情况.也会导致这种情况出错.出错的原因是因为公私密钥保存位置不在默认目录下.导致在Push时提示需要提示提供公钥.所以在并不推荐使用工具的方式生成密钥，如果要保存最好不要自定义保存目录:

当然最好的方式就是官方给出通过Bit Bash指令工具自动生成.操作流程如下:

首先通过自己的电子邮件生成对应的公私密钥.保存和存储指令一律采用默认为空的方式保存默认目录下.注意这个默认目录在User创建成功可以通过如下指令测试是否连接GitHub成功"：

1: ssh -T git@github.com

测试成功成功后.在来通过Visual STudio 中Git集成Push到GitHub上:

you see Push成功.GitHub也能看到对应目录和Code.

well.当我们通过GitHub首先第三方代理时.通过和其他开发人员或第三方团队时很方便.随时随地就可以把代码Commit或是Pull一个版本，这样分布式结构完全体现Git的威力.ok加入Team另外一个成员修改Github上源码并Commit一个完整版本.现在Pull下来一个最新SouceCode.在Visual Studio中：执行Pull:

分支选择以主干Master. 合并策略Merge默认以GitHub SouceCode为基准覆盖本地.

Pull 成功.

如果在GitHub看到不错的项目可以通过本地找到指定目录Clone本地:

Clone操作执行本地源码:

…

Git操作的细节太多了. 我这个短短的篇幅中是无法写完的.只能列举一些在Visual Studio最基本的应用.展示一下Git作为版本控制工具强项.权当抛砖引玉.

<3>Git小结

Git作为很好的分布式的版本控制工具.在版本控制能够优雅实现多种类型模式和Team的协作模式.机动灵活处理了版本控制各种问题.当然这篇文章我写了两天.主要是要重现Git大量细节操作太费时费力了.写的很累.篇幅毕竟有限.不能全面覆盖.只能抛砖引玉.对于Windows平台的用户来 这种分布式控制版本控制工具.与强大Visual Studio集成.对Windows 平台开发人员和日常团队管理来说也是”福音”,极力推荐.