Git Tool Part 2
2012-01-13 15:51 chenkai 阅读(4917) 评论(6) 编辑 收藏 举报针对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 平台开发人员和日常团队管理来说也是”福音”,极力推荐.
可以参考上篇:Git Tool Part 1
