本篇导读：
上篇介绍了一款Windows环境下的Git服务器工具GitStack ，搭建了最简单的Windows下的Git服务器，需要再次提醒的是GitStack是打包了相对较稳定的Git原生版本的，喜欢使用命令行的同学，并不影响你。GitStack仅仅是提供了一套界面化操作和一个Http服务。本篇将深入介绍如何使用强大客户端Git工具TortoiseGit进行分支切换、合并等操作。
1. 创建分支
分支在Git中可以说非常的方便实用，首先我们在什么情况下需要创建分支呢?
在这点上Git和SVN理念上就有差异。SVN的分支一般作为管理员事先分配好分支的用途，开发人员不能随意创建。而Git你想建就建吧，你自己知道分支是什么就行。
Git中每个开发者最好都有一个自己的分支。然后可以再创建分支作为阶段备份，作为试验品，干什么都行。最后，你把你的试验成果合并到自己的分支上。再然后如果自己的分支相对稳定，再提交到主干上。
当然master是否采纳你的分支全部或部分，这是master的工作。这样的自由开发方式，是不是心动了呢，继续看下去吧！
话不多说，我们直入主题，下面看下如何创建一个分支。
在项目 主文件夹右击或打开主项目文件件，在空白处右击，选择TortoiseGit,选择创“创建分支”
输入一个分支名称，"Yu_V1"表示我个人的第一个版本，下面切换到新分支如果选中，创建完成后，工作环境将切换到新分支了，如果没选，也可以很方便的切换
完成分支创建以后，我们更新增一个文件“我的第四个文件.txt”
新建文件后，我们在空白区域右击，发现提交默认变成了 提交到 Yu_V1
进入提交，输入备注，选中新建的文件四，在这个窗口可以看到当前所要提交的分支名称
2. 切换分支
这时，如果我们要回到主干怎么办呢，Git的分支切换非常方便
项目目录空白处右击，TortoiseGit=> 切换/检出
在切换窗口，我们可以很方便的切换到任一分支，假如我们切换到master
我们会发现，分支Yu_V1中第四个文件没有了，右击空白，会发现切换到了master.
第四个文件并不会丢失，当我们再次切换回分支Yu_V1的时候，第四个文件又会回来了
这就是Git强大的地方，他在服务器上存储了一个文件库(以元数据方式存储)，再存储了一个版本及分支更改等的变更信息库，每次我们切换的时候向服务端发送了一个请求，服务端则根据我们的请求变更我们的项目中的文件。
整个过程就是快速的传输，服务器上并不会一一存储各个分支的文件副本，这也是Git服务端版本库不会暴增的主要原因。
（我会在介绍过程中，慢慢把Git的工作原理切入进来）
3. 查看日志
项目目录空白处右击，TortoiseGit=> 显示日志
如上图，在打开的显示日志窗口中，我们可以看到如果创建了分支，日志信息中会在变更信息前显示一个分支名称，以方便我们了解是哪一个分支的变更
我们再次建一个文件，创建一个新分支Yu_V2,将新建的文件提交到该分支，再次查看日志
可以看到红色表示当前所在分支，绿色表示其他分支变更信息
4. 查看版本分支图
项目目录空白处右击，TortoiseGit=> 查看版本分支图
在打开的分支图窗口中，可以看到版本分支的创建历史流程
5. 合并分支
项目目录空白处右击，TortoiseGit=> 合并
在弹出的合并窗口中，我们先选择一个分支，合并至当前分支（这里一定要注意，合并关系，如果要最终合并到那个分支，先切换到该分支，再选一个合并目标）
提示合并完成，是不是非常简单。
6. 删除分支和分支更名
项目目录空白处右击，TortoiseGit=> 切换/检出
在切换界面中，分支选择后面的选择按钮打开，如上图右侧窗口，可以更新和删除某个分支，注意，不能删除当前分支，如果要删除当前分支，请换到到其他分支进行操作
7. 推送
项目目录空白处右击，TortoiseGit=> 推送
在推送窗口中，如果选择 推送所有分支，则本地库中所有分支都被推送到服务器，默认为推送当前分支。我们可以选择推送到其他分支，而提交只能提交到远程的对应分支或新建分支。
我们可以随时在服务器端GitStack中查看我们的项目提交情况
打开GitStack,找到我们创建的版本库"MyGitObject",点击右边的“浏览”按钮，如下图
在服务端，我们可以很方便的查看推送到服务器的文件及分支信息。
8. 更新版本库
前面我们已经熟悉了从远程服务器克隆一个版本库到本地及从本地推送给Git,在项目推进过程中，我们如何及时获取其它分支的更新内容呢，接下来将介绍这点。
关于更新本地库，这里有两个操作，如果你是中文版本的TortoiseGit很容易搞错，这就是语言差异。
中文版本 分别为 拉取和获取 对应英文版为 Pull(拉取)和Fetch(获取)
在这里一起介绍这两个指令，他们有什么区别呢？
拉取(Pull)会从远程取得最新版本然后合并（Merge）到本地库
获取(Fetch)则会从远程取得最新版本，并不会合并（Merge）到本地库
可以说 拉取（Pull）=获取（Fetch）+合并（Merge）
从安全角度来说，Fetch更安全，因为我们可以 先Fetch新版本，然后进行差异比较后，再选择性的 Merge 。这也是推荐做法，即先Fetch到一个本地副本分支，然后将该副本分支和本地版本比较，合并后，再提交到远程主机。
获取和拉取的操作很简单
项目目录空白处右击，TortoiseGit=> 拉取（Pull）
项目目录空白处右击，TortoiseGit=> 获取（Fetch）
9. 差异比较
9.1 比较分支版本差异
我们该如何查看分支1和分支2的差异呢？TortoiseGit为我们提供了很方便的功能
项目目录空白处右击，TortoiseGit=> 查看日志
9.2 比较同一分支当前版本和上一版本差异
项目目录空白处右击，TortoiseGit=> 比较与上一版本差异
9.3 比较两个文件差异
选中项目中两个文件 右击，TortoiseGit=> 比较差异
打开文件差异比较窗口，如下
也可以在某个文件上右击，选择”与上一版本差异“来查看某个文件的更改内容
10. 还原
如果某次操作我们后悔了，可以使用还原，将还原到上次提交前的状态。
项目目录空白处右击，TortoiseGit=> 还原
注意：还原只能还原到最近一次提交时的状态， 之前提交的的版本怎么还原呢，也是有办法的，如下：
项目目录空白处右击，TortoiseGit=> 查看日志
选中一个历史版本，右击，点”重置到这个版本“将把版本回退到之前的版本。
11. Git中解决冲突
使用Git这种非锁定式的版本控制系统以后，很多初学者都有解决冲突恐惧症，分布式的开发给我们带来便利的同时，产生冲突也是正常的。所谓防范胜于救灾，我们可以避免，如何避免呢？
(1)首先团队在开发过程中需要有明确规范;
(2)开发人员需要及时获取新版本；
(3)修改后，一定要及时递交；
即使做到以上三点，仍然会有冲突的存在，解决冲突并不可怕，通过上面的介绍，我们可以看到GIT给我们提供了许多辅助功能，比如文件差异比较，版本差异比较等。我们要充分利用这些便利解决问题。
一般冲突主要有三种：逻辑冲突、树冲突、内容冲突
这三种冲突如何应对呢?
(1)逻辑冲突
产生原因：比如A方法作用是返回从0-5的随机数1个，但是同事在没有更改方法名的情况下，改成了方法返回6-9的随机数1个。如果拉回同事提交的版本库，应用该方法后，就会出现程序逻辑错误。
解决办法：首先我们在使用获取一个副本支的方式更好，避免了这一问题，如果冲突，我们可以获取版本后，使用恢复功能，或修改冲突再提交。沟通很重要，一般这种BUG都是事先没有沟通好。
(2)树冲突
产生原因：两个人同时修改一个文件名
解决办法：其中一个人获取新版本，然后删除自己改过名的文件，双方协商好用什么名字，再由其中一人更改，另一人获取新版本即可。
(3)内容冲突
产生原因：两个人同时改了同一文件的同一位置内容
解决办法：提交文件产生这种冲突时，我们利用文件差异比较，查看两个文件内容冲突的位置手动更改，然后推送到服务器。
12. 分支管理策略
Git在分支创建和合并上为我们带来前所未有的便利，同时版本四处开花，分支遍地，很容易让初次使用者找不到主干发展方向。这就需要我们学习一下工作流，Git的工作流网上有很多大神介绍，本篇文章不能一一列举了。但是Vincent Driessen的分支管理策略得到了众多支持者。我们分享一下他的成果。
他的策略可以使版本库演进保持简洁、主干清晰、分支各司其职。
(1) Master分支（主分支）
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。我们可以给主分支上的每个版本库打上tag，为了更好的管理。
(2)开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
如果想正式对外发布，就在Master分支上，对Develop分支进行”合并”（merge）。
(3)临时性分支
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，
后者用于日常开
发。其实，常设分支只需要这两条就够了，不需要其他了。但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种： * 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
功能分支
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
修补Bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
合并完成以后的修补Bug分支要删除的。
对于分支管理策略，我推荐一篇文章，可以参考一下：http://www.cnblogs.com/cnblogsfans/p/5075073.html
13. 本篇要点
本篇主要介绍了Git的分支、合并、分支切换、差异比较、冲突解决等，使用TortoiseGit界面化的客户端工具，让我们在使用过程中更加简单了，先理解了Git的工作流程和使用方法，再慢慢了解一下命令行，也是不错的。其实界面化的工具每一步指令的本质还是命令行。在写这篇文章的同时，我也参考了很多博客，在此表示感谢。TortoiseGit还有很多功能没有一一介绍，相信有了本篇的基础，上手不是难事了。
