一、概述

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