git使用实践

这篇文章将从开发者和管理者两方面介绍如何使用git进行团队合做开发。

1.git 和svn的差别

git和svn 最大的差别在于git是分布式的管理方式而svn是集中式的管理方式。若是不习惯用代码管理工具，可能比较难理解分布式管理和集中式管理的概念。下面介绍两种工具的工做流程（团队开发），经过阅读下面的工做流程，你将会很好的理解以上两个概念。

集中式管理的工做流程以下图（图2.1）：

　　集中式代码管理的核心是服务器，全部开发者在开始新一天的工做以前必须从服务器获取代码，而后开发，最后解决冲突，提交。全部的版本信息都放在服务器上。若是脱离了服务器，开发者基本上是不能够工做。下面举例说明：

开始新一天的工做：

1：从服务器下载项目组最新代码。

2：进入本身的分支，进行工做，每隔1个小时向服务器本身的分支提交一次代码（不少人都有这个习惯。由于有时候本身对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时本身修改了哪些代码，就须要这样作了）。

3：下班时间快到了，把本身的分支合并到服务器主分支上，一天的工做完成，并反映给服务器。

这就是经典的svn工做流程，从流程上看，有很多缺点，但也有优势。

缺点：

一、服务器压力太大，数据库容量暴增。

二、若是不能链接到服务器上，基本上不能够工做，看上面第二步，若是服务器不能链接上，就不能提交，还原，对比等等。

三、不适合开源开发（开发人数很是很是多，可是Google app engine就是用svn的）。可是通常集中式管理的有很是明确的权限管理机制（例如分支访问限制），能够实现分层管理，从而很好的解决开发人数众多的问题。

优势：

一、管理方便，逻辑明确，符合通常人思惟习惯。

二、易于管理，集中式服务器更能保证安全性。

三、代码一致性很是高。

四、适合开发人数很少的项目开发。

五、大部分软件配置管理的大学教材都是使用svn 和vss。

下面是分布式管理的工做流程，以下图（图2.2）：

　　分布式和集中式的最大区别在于开发者能够在本地提交。每一个开发者机器上都有一个服务器的数据库。

　　图2.2就是经典的git开发过程。步骤以下：

通常开发者的角度：

1：从服务器上克隆数据库（包括代码和版本信息）到单机上。

2：在本身的机器上建立分支，修改代码。

3：在单机上本身建立的分支上提交代码。

4：在单机上合并分支。

5：新建一个分支，把服务器上最新版的代码fetch下来，而后跟本身的主分支合并。

6：生成补丁（patch），把补丁发送给主开发者。

7：看主开发者的反馈，若是主开发者发现两个通常开发者之间有冲突（他们之间能够合做解决的冲突），就会要求他们先解决冲突，而后再由其中一我的提交。若是主开发者能够本身解决，或者没有冲突，就经过。

8：通常开发者之间解决冲突的方法，开发者之间可使用pull命令解决冲突，解决完冲突以后再向主开发者提交补丁。

主开发者的角度（假设主开发者不用开发代码）：

1：查看邮件或者经过其它方式查看通常开发者的提交状态。

2：打上补丁，解决冲突（能够本身解决，也能够要求开发者之间解决之后再从新提交，若是是开源项目，还要决定哪些补丁可用，哪些不用）。

3：向公共服务器提交结果，而后通知全部开发人员。

优势：

适合分布式开发，强调个体。

公共服务器压力和数据量都不会太大。

速度快、灵活。

任意两个开发者之间能够很容易的解决冲突。

缺点：

资料少（起码中文资料不多）。

学习周期相对而言比较长。

不符合常规思惟。

代码保密性差，一旦开发者把整个库克隆下来就能够彻底公开全部代码和版本信息。

2.git经常使用命令介绍

git init

建立一个数据库

git clone

复制一个数据到制定文件夹

git add 和git commit

把想提交的文件add上，而后commit这些文件到本地数据库。

git pull

从服务器下载数据库，并跟本身的数据库合并。

git fetch

从服务器下载数据库，并放到新分支，不跟本身的数据库合并。

git whatchanged

查看两个分支的变化

git branch

建立分支，查看分支，删除分支

git checkout

切换分支

git merge

合并分支，把目标分支合并到当前分支

git config

配置相关信息，例如email和name

git log

查看版本历史

git show

查看版本号对于版本的历史，若是参数是HEAD查看最新版本。

git tag

标定版本号

git reset

恢复到以前的版本

--mixed是git-reset的默认选项，它的做用是重置索引内容，将其定位到指定的项目版本，而不改变你的工做树中的全部内容，只是提示你有哪些文件还未更新。

--soft选项既不触动索引的位置，也不改变工做树中的任何内容。该选项会保留你在工做树中的全部更新并使之处于待提交状态。至关于在--mixed基础上加上git add。

--hard 把整个目录还原到一个版本，包括全部文件。

git push

向其余数据库推送本身的数据库

git status

显示当前的状态

git mv

重命名文件或者文件夹

git rm

删除文件或者文件夹

git help

查看帮助，还有几个可有可无的命令，请本身查看帮助。

3.git开发模式

1：大项目开发模式（如图4.1）

对于项目负责人

1：初始化

对于最终项目负责人：

使用git init --bare在公共服务器上创建一个空数据库，在本身的机器上经过

或者数据库（这里须要设置一下访问权限，因为git没有提供权限管理功能，因此要经过ssh设置，具体是对下一级子项目项目可读不可写，对本身可读可写）。

新建一些必要的文件夹和文件放到本身的数据库上

而后使用

提交到公共服务器上，做为原始版本。

告诉下级公共服务器的地址。

对于子项目负责人：

在子公共服务器上克隆一个数据库

设置访问权限，对下级可读不可写，对本身可读可写。
在本身的计算机中克隆一个数据库

告诉下级子公共服务器地址。

对于最底层的开发人员：
在上级公共服务器中克隆一个数据库

2：开展工做
对于最终项目负责人
收来自下级的邮件
在本身的数据库上建分支，并转到分支上

重复上述步骤，直到全部补丁打完。
若是发如今合并分支的时候发现有些冲突须要下级项目负责人协助解决的话，能够通知下级项目负责人。
对于子项目负责人：
若是上级项目负责人须要他们之间合做解决某些冲突，他们能够经过

解决冲突。
若是上级项目负责人没有要求合做解决冲突，那项目负责人应该作如下事情：

而后项目负责人就开始接收邮件，而后打补丁

重复上述工做，直到补丁所有打完。
下面是向上级提交更新的过程

对于最底层的开发人员：
若是上级要求解决冲突，一样是要解决冲突，而后再提交补丁

若是不用，就从上级服务器更新

而后建分支，并开发代码

而后是向上级提交代码

以上就是git在大项目开发中的应用。
可是明显是不适合咱们实验室的。
缘由有三：
一、咱们学生中没有专门的维护人员。
二、咱们学生中没有对全局都很了解架构师。
三、咱们的老师能够担当此重任也只有咱们的老师有这样的实力，可是老师太忙，没时间天天作这些杂事。
因此咱们须要一种新的合做模式（一种没有项目负责人的模式）。

这种模式对开发人员的素质要求很高。
合做模式以下图（图4.2）：（适合咱们实验室使用）

 

这种模式的开发流程以下： 一、由其中一个开发者这服务器上创建一个数据库。 全部开发者均可以向数据库提交和下载东西，这里必须规定必定的时间间隔（一周或者一天）必须提交一次，否则之后解决冲突时是个大问题。 若是每一个人的开发耦合度很高，咱们可在服务器上创建分支，而后每人每次提交到本身的分支上，过一段时间以后（不能过久）有一我的去合并分支。而后全部人更新本身的数据库的master分支，使之跟服务器上的master分支同步。 二、这样服务器会有很是多的版本信息，集合了每一个人的版本信息。 过了一段时间以后，例若有里程碑的出现。再由一我的把全部改动打补丁到最终服务器上。这样最终服务器的版本信息就会很精练。 三、当咱们的服务器无限膨胀到必定程度的时候咱们能够把它删除，而后用最终服务器上的一个版本做为起始版本。