Git基本使用指南

一、概述

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）        稳定版本发布后即可删除所有临时分支。