一、概述
1. Git与SVN比较
目前用到最广泛的版本控制软件就是SVN和Git,那么这两者之间有什么不同之处呢？
1) SVN（Subversion）是集中式管理的版本控制器，而Git是分布式管理的版本控制器！
2) SVN只有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
3) Git每一个终端都是一个仓库，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。每一次的提取操作，实际上都是一次对代码仓库的完整备份。
4) Git具备强大的分支管理功能，SVN实际上不具备。
2. 为什么选择Git
SVN的优点：
1) 管理方便，逻辑明确，符合一般人思维习惯。
2) 易于管理，集中式服务器更能保证安全性。
3) 代码一致性高。
SVN的缺点：
1) 提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类；
2) 冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。
Git更适合分布式开发，离线工作，强调个体，任意两个开发者之间可以很容易的解决冲突。最重要的是Git具备强大的分支管理功能，非常适合产品开发。
二、基本操作
1. 获取帮助
通过git命令可以查看所有命令的介绍
2. 仓库的克隆
git获取仓库的命令是clone而不是checkout，从这就可以看出Git和SVN的区别。
Git获取的是整个库的信息，可以查看所有日志信息。
3. 提交代码
在文件夹下运行commit命令，将文件提交到本地版本库。
由于本地仓库只有你一个人在使用，所以请放心提交，不需要考虑BUG等因素。PUSH时就要小心了。
有些文件是不需要提交到版本管理的，比如 .vs 文件夹、bin、obj文件夹等，应该将其加入忽略列表中。
Git提交时要求输入关于本次提交的说明，请认真填写，这样就不用维护额外的版本修改日志了。对于确实无关紧要的提交，可以团队约定输入一个字符，如“#”。
4. 同步仓库
同步操作有两种：
1、 PULL：将远程服务器代码同步到本地
2、 PUSH：将本地代码同步到远程服务器
具体的操作流程应该如下：
1、 commit的操作应该是频繁进行的，和远程库无关；
2、 执行PULL操作获取团队最新代码；
3、 本地确认编译成功后PUSH到远程库，以便分享个人代码。PUSH前应该确认个人版本是可以编译通过的。
模拟一个操作场景：
1） A用户早上PULL了最新版本，然后在此版本基础上进行了一天的开发，下班时进行了PUSH操作，没有发生任何问题；（应该先PULL再PUSH）
2） B用户早上也PULL最新版本，开发了一天，此时B进行PUSH会报错（本地库版本和远程库不一致），必须先进行PULL获得最新版本后才能进行PUSH。（PUSH前应保证版本可以编译）
3） 如果两个用户修改了同一个文件，当B用户在进行PULL时会进行合并，一般不会发生冲突。A用户会在下次PULL时获得合并后的版本。
4） 如果两个用户修改了同一个文件的两个地方就会引起冲突。
5. 解决冲突
版本冲突在两个用户修改同一个文件的同一个位置时发生。修改同一个文件的不同的位置会自动合并，不会冲突。二进制文件没有合并功能，任何同时修改都会冲突。
一个冲突解决的示例：
这是代码的原始版本：
|
static void Main(string[] args) { Console.WriteLine("Hello");
Console.ReadLine(); } |
A用户修改后：
|
static void Main(string[] args) { Console.WriteLine("Hello"); Console.WriteLine("Hello:I'm Good Boy!"); Console.ReadLine(); } |
B用户修改后：
|
static void Main(string[] args) { Console.WriteLine("Hello"); Console.WriteLine("Hello:I'm BAD Boy!"); Console.ReadLine(); } |
首先A用户率先进行了commit 和 PUSH，成功。B用户此时也准备提交，提交前，要进行一次PULL，此时发生冲突：自动合并失败！
CONFLICT (content): Merge conflict in ConsoleApp1/ConsoleApp1/Program.cs
Automatic merge failed; fix conflicts and then commit the result.
打开冲突文件，可以看到：
|
static void Main(string[] args) { Console.WriteLine("Hello"); <<<<<<< HEAD Console.WriteLine("Hello:I'm BAD Boy!"); ======= Console.WriteLine("Hello:I'm Good Boy!"); >>>>>>> 129dfb44dd2978700d82493d9fa966e598b85535 Console.ReadLine(); } } |
可以看到冲突内容包含在<<<<<<<与>>>>>>>之间，通过======隔开，前面是本地版本，后面是远程版本。
处理办法：直接修改这个文件，然后commit、PULL、PUSH即可。
还有一种冲突是版本库删除了一个文件，本地还进行了修改，这也形成冲突。
AA.txt deleted in 777b20bb5a04b3c3489318c5e7d6723d5d38d50f and modified in HEAD. Version HEAD of DOC/AA.txt left in tree.
处理办法：先将冲突文件移开，commit后再PULL就可以成功，如果还需要这个文件，再重新commit即可。
三、进阶操作
1. 版本标记
为了合并、回退等操作方便，我们会对重要版本进行标记。在log界面找到指定版本，右键选择：“create tag at this version…”。
2. 恢复误删除的文件
如果文件（或文件夹）被误删除，并且已经清空回收站，可以从本地版本库取得最新提交的文件，注意：只有提交过的版本才能恢复，没有提交的内容是不可能找回的，所以要经常提交。
首先通过日志找到删除之前的某个版本，在其文件上右键选择“Revert to this version”即可，对于不想要的文件，如果想恢复到之前版本，也可以通过这个方法处理。
3. 获取指定版本库
可能近期写的代码一团糟，已经无法走上正轨了，希望恢复到某个稳定的版本重新开发，这就需要重置版本。首先在日志窗口找到要恢复的点，右键选择：”reset XXX to this version…”
重置类型选择“Hard”：
Hard表示强制恢复到指定版本，Mixed表示保留修改的文件。
如果在回退前没有PUSH过版本，回退后需要PUSH的话直接PUSH就可以了，如果回退的版本早于最后一次PUSH的版本，则需要进行强制PUSH（Hard）。
需要说明的是，远程版本回退应该是一个集体行为，不存在项目组某个人进行版本回退，但其他人继续使用当前版本的情况，回退点之后的版本是要抛弃掉的。
四、分支管理
1. 分支管理概述
一般来说主线版本（master）是不会用来开发的，只用来进行版本发布，如果一个项目采用master单线版本进行开发，建议不要采用Git进行版本管理，采用SVN会更加方便一点。
下面介绍一下版本分支管理的主要流程与意图：
某公司1号发布了产品版本V1.0，15号开发人员在开发V1.1过程中接到客户反馈，发现重大BUG需要紧急修复，假设采用单分支开发，就必须在当前分支进行修复并发布，造成的问题是本次发布的版本包含未经验证的V1.1版本的内容。
正确的做法应该是：master主分支发布V1.0版本后，创建分支V1.1进行下一个版本开发，当收到用户BUG反馈时，创建V1.0_DEBUG分支进行修复，并发布。当V1.1版本开发完成并验证通过后，将V1.1分支合并到master分支，同时合并V1.0_DEBUG分支修复的BUG。
版本合并后，继续创建V1.2版本进行下一个版本开发。V1.1版本发现的BUG可以继续在原来V1.1分支上进行修复，V1.0_DEBUG版本可以不用继续维护了，之前发出的版本如果发现问题，可以在V1.1版本进行修改，并将客户版本升级到V1.1 。
2. 创建分支
一般通过Git管理平台创建分支，并为分支设置权限，也可以在本地创建分支，然后Push到远程服务器。如果要在某个时间点创建分支，在日志窗口找到指定的时间点，右键选择“Create Branch at this version…”即可。本地创建分支后，需要切换到该分支并执行PUSH操作才能将分支同步到服务器。
3. 在某分支上进行开发
在固定的某个分支上进行开发，参照本文第二、第三部分的描述即可。本地克隆了版本库之后，立即切换到开发分支，第一次切换时会在本地建立相同名称的本地分支。
4. 分支的合并
通过Fetch命令获取其他分支内容。Fetch命令把远程服务器上所有版本同步到本地，但不做进一步操作。
通过Merge命令进行版本合并，合并时需要选择对方分支的名称。
5. Fetch与Pull的区别
Pull命令相当于 Fetch + Merge ，就是把远程库同步到本地并自动进行合并。如果要合并其他分支，Pull时需要选择其他远程分支的名称。
采用PULL或Fetch + Merge没有本质区别，唯一的区别就是在进行分支合并时Fetch后可以先观察一些修改的内容在进行合并。建议在同一个分支工作时就采用Pull，在分支之间进行合并时，采用Fetch + Merge。
6. 分支冲突
合并版本后，对所有冲突进行手动修改，修改完成后Commit、PUSH即可。
需要注意几点：
1、 永远以master分支为发布分支；
2、 master会合并develop和fixbug版本，develop也会合并fixbug版本，不要有其他方向的合并；
3、 master版本合并其他版本后，通过新建分支的方式继续开发，原来其他分支可以删除掉。
4、 如果develop合并fixbug时有冲突，master在合并develop和fixbug时可能任然会冲突，如果develop版本已经合并了所有fixbug，那么master版本在合并develop后可以不用重复合并fixbug。
五、Git版本管理最佳实践
以下是一个常见的版本管理的流程：
具体流程描述如下：
1） 首先建立版本库，自动创建master版本，在master版本上持续开发，直到发布V1.0版本；
2） V1.0版本发布后同时面临两个任务：V1.1版本开发和V1.0版本的Bug修复。此时创建V1.1_develop分支和V1.0_bugfix两个分支，相关的开发团队应该立即Fetch库后Switch到各自的库上开展工作；
3） 新版本V1.1_develop研发完成并验证后，合并到master库，同时master库合并V1.0_bugfix分支，经验证后发布V1.1版本；
4） 删除V1.1_develop和V1.0_bugfix分支；
5） 创建新分支，循环以上过程。
需要注意几点：
1） 如果更严谨一些的话，应该还要具备测试分支，测试分支从develop分支创建，测试通过后合并到主分支。
2） 以上第三个过程的操作，可以更积极一点，master版本可以更频繁地合并两个版本以及时处理冲突，develop分支也可以积极合并fixbug分支，但fixbug分支不能合并其他分支。
3） 稳定版本发布后即可删除所有临时分支。