TortoiseGit升级操作说明
一、安装
下载安装 Git Windows 版：
请参考《TortoiseGit安装说明》。
下载安装 Git Linux 版：
Linux下可以直接用yum install或者apt-get install 安装。
二、开始使用
请参考《TortoiseGit常用操作说明》
注：这篇手册所有git操作在命令行下执行，windows下可以右键Git Bash Here打开命令行（UI工具有相应的选项）。
如果有人提供某项目的git地址：
git clone http://192.168.3.124/xxx/test1121.git
或者：
三、版本控制
1.本地版本库
要提交代码到git仓库需要两个命令：
git add
git commit -m “代码提交信息”
要撤销提交：
git reset HEAD
要从从版本库恢复文件：
git checkout —
在git文件夹中实际存在三个区域：
实际目录：实际修改的文件。
待提交区：暂存准备提交的内容，提交之后被清空。(也叫做index区）
已提交区：提交到本地git版本库的内容，有版本号。
对这三个区域的操作都可以在本地离线完成。
完整一些的状态图如下：
查看文件状态：
git status
文件总共四种状态：
与git repository一致
与git repository不一致，已缓存
与git repository不一致，未缓存
还未添加到git repository
2.远程版本库
从远程更新：
git pull （拉取）
提交到远程：
git push （推送）
远程git与本地git的关系大概是这样：
其中：remotes/origin是git用来管理远程版本库的的隐藏分支，一般不用理会。
四、分支与标记
1.分支
分支是用来将特性开发绝缘开来的。在创建仓库的时候， master 是“默认的”。在其他分支上进行开发，完成后再将它们合并到主分支上。
创建一个叫CRT的分支，并切换过去：
git branch CRT
git checkout CRT
或者：
切换回主分支：
git checkout master
再把新建的分支删掉：
git branch -d CRT
除非将分支推送到远端仓库，不然该分支就是不为他人所见的：
git push origin
2.合并
要合并其他分支到当前分支（例如 master），执行：
git merge
两种情况下，git 都会尝试去自动合并改动。但是自动合并并非次次都能成功，并可能导致冲突（conflicts）。
这时候就需要修改这些文件来手动合并这些冲突（conflicts）。修改之后，需要执行如下命令以将它们标记为合并成功：
git add
在合并改动之前，也可以使用如下命令查看：
git diff
3.标签
在软件发布时创建标签，是极好的习惯。这个概念，在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0 的标签：
git tag 1.0.0
或者：
五、工作流与规范化
在工作中，用一个分支来处理开发、测试、发布、线上hotfix等等流程是难以控制的：
项目上线前只想让其他人提交一个小修改，结果fetch（获取）来的是另一个人为下次上线提交上来的几百个文件修改。
这里介绍利用git分支的特性避免这种情况的一种做法：
1.永久分支
首先，git远程版本库有两个永久分支，master与develop。
develop分支包含开发过程中最新的提交变更。有人会称之为“集成分支”。该分支是自动化每日构建的代码源。
当develop分支上的源码到达一个稳定的状态时，就可以发布版本。所有develop上的变更都应该以某种方式合并回master分支，并且使用发布版本号打上标签。
每次有变化被合并到master分支时，这就是一次新的产品版本发布。
这里将master分支状态启用protect(保护)状态，以便控制merge(合并)权限：
更多project members权限请查看：Dashboard/help/permissions
2.临时分支
临时分支是开发或者发布过程中被创建、一段时间后再删掉的分支，同一时间内可能会有多个临时分支在并行工作。
1). feature
作用：开发新的功能
分支来源：develop
分支结束时合并到：develop
特性分支（有时也被称作topic分支）是用来为下一发布版本开发新特性。当开始开发一个特性的时候，该特性会成为哪个发布版本的一部分，往往还不知道。特性分支的重点是，只要特性还在开发，该分支就会一直 存在，不过它最终会被合并回develop分支（将该特性加入到发布版本中），或者被丢弃（如果试验的结果不符要求）。特性分支往往只存在于开发者的本地仓库中。
2).release
作用：准备发布新版本
可能的分支来源：develop
分支结束时合并到：develop和master
发布分支为准备新的产品版本发布做支持。它允许在最后时刻检查所有的细节。此外，它还允许修复小bug以及准备版本发布的元数据（例如版本号，构建日期等等）。在发布分支做这些事情之后，develop分支就会显得比较干净，也方便为下一大版本发布接受特性。
develop分支创建发布分支的时间通常是develop分支反映新版本所期望状态的时候。至少说，这时候版本发布所计划的特性都已经合并回了develop分支。而未来其它版本发布计划的特性则不应该合并，它们必须等到当前的版本分支创建好之后才能合并。
正是在发布分支创建的时候，对应的版本发布才获得一个版本号——不能更早。在该时刻之前，develop分支反映的是“下一版本”的相关变更，但不知道这“下一版本”到底会成为0.3还是1.0，直到发布分支被创建。版本号是在发布分支创建时，基于项目版本号规则确定的。
3). hotfix
作用：修复发行版bug
分支来源：master
分支结束时合并到：develop和master
热补丁分支和发布分支十分类似，它的目的也是发布一个新的产品版本，尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候，就需要理解着手处理，这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候，我们从对应版本的标签创建出一个热补丁分支。
使用热补丁分支的主要作用是（develop分支上的）团队成员可以继续工作，而另外的人可以在热补丁分支上进行快速的产品bug修复。
4). 流程图
3.gitlab与code review
在了解如何review之前先明确几个观点：
a).master分支中的任何版本都认为是可以立即部署的。
b).每一次master分支的变更都来自于其它分支向master的合并操作。
c).对master的修改需要review。
借助于gitlab的merge request机制，与上面说的工作流程，我们可以在release或者develop分支正式合并到master分支之前建立merge request，在master或者owner review完成这次合并请求之后再正式进行合并。
1). 如何review
a).将需要合并到master的分支push到gitlab。
b).进入工程merge request →create new merge request。
c).选择源分支、目标分支，添加信息，然后确定。
d).review负责人(owner 或者 master)将会收到merge request的邮件，进入merge request，确认没有问题之后选择Auto Merge（或者手动在本地合并之后再push到gitlab），并关闭这个merge request，完成合并，merge request关闭后request的发起人会收到邮件提示Merge Request was closed。
查看merge request：
点击
查看修改的内容并且可以添加评论：
e)如果发现问题那么在有问题的行下注释，并提醒request的发起人及时修改。
六、更进一步
常用命令：
git reset
A). –hard：重设（reset） index和working directory，自从
B). –soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向
C). –mixed：仅reset index，但是不reset working directory。这个模式是默认模式，即当不显示告知git reset模式时，会使用mixed模式。
git checkout
-b 签出并创建分支
-t 签出并追踪远程分支
git rebase
合并/修改提交
git remote -av
显示所有远程仓库
git push -u
设置分支对应的远程仓库
七、参考资料
git-the simple guide
《Pro Git》
A successful git branching model
Github-flow
参考链接：http://www.tuicool.com/articles/BZJRj2