Git基本使用指南

1、概述

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具有强大的分支管理功能，很是适合产品开发。

 

2、基本操做

1.    获取帮助

经过git命令能够查看全部命令的介绍

 

  

2.    仓库的克隆

git获取仓库的命令是clone而不是checkout，从这就能够看出Git和SVN的区别。

Git获取的是整个库的信息，能够查看全部日志信息。

   

3.    提交代码

在文件夹下运行commit命令，将文件提交到本地版本库。

因为本地仓库只有你一我的在使用，因此请放心提交，不须要考虑BUG等因素。PUSH时就要当心了。

有些文件是不须要提交到版本管理的，好比 .vs 文件夹、bin、obj文件夹等，应该将其加入忽略列表中。

Git提交时要求输入关于本次提交的说明，请认真填写，这样就不用维护额外的版本修改日志了。对于确实可有可无的提交，能够团队约定输入一个字符，如“#”。

 

    

4.    同步仓库

同步操做有两种：

一、 PULL：将远程服务器代码同步到本地

二、 PUSH：将本地代码同步到远程服务器

具体的操做流程应该以下：

一、        commit的操做应该是频繁进行的，和远程库无关；

二、        执行PULL操做获取团队最新代码；

三、        本地确认编译成功后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便可。

 

3、进阶操做

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）。

须要说明的是，远程版本回退应该是一个集体行为，不存在项目组某我的进行版本回退，但其余人继续使用当前版本的状况，回退点以后的版本是要抛弃掉的。

 

4、分支管理

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.    在某分支上进行开发

在固定的某个分支上进行开发，参照本文第2、第三部分的描述便可。本地克隆了版本库以后，当即切换到开发分支，第一次切换时会在本地创建相同名称的本地分支。

 

4.    分支的合并

经过Fetch命令获取其余分支内容。Fetch命令把远程服务器上全部版本同步到本地，但不作进一步操做。

经过Merge命令进行版本合并，合并时须要选择对方分支的名称。

 

  

5.    Fetch与Pull的区别

Pull命令至关于 Fetch + Merge ，就是把远程库同步到本地并自动进行合并。若是要合并其余分支，Pull时须要选择其余远程分支的名称。

   

采用PULL或Fetch + Merge没有本质区别，惟一的区别就是在进行分支合并时Fetch后能够先观察一些修改的内容在进行合并。建议在同一个分支工做时就采用Pull，在分支之间进行合并时，采用Fetch + Merge。

 

6.    分支冲突

合并版本后，对全部冲突进行手动修改，修改完成后Commit、PUSH便可。

须要注意几点：

一、 永远以master分支为发布分支；

二、 master会合并develop和fixbug版本，develop也会合并fixbug版本，不要有其余方向的合并；

三、 master版本合并其余版本后，经过新建分支的方式继续开发，原来其余分支能够删除掉。

四、 若是develop合并fixbug时有冲突，master在合并develop和fixbug时可能任然会冲突，若是develop版本已经合并了全部fixbug，那么master版本在合并develop后能够不用重复合并fixbug。

 

5、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）        稳定版本发布后便可删除全部临时分支。