基于Git的分布式版本控制系统的设计与实现

2012-08-15刘悦之

科技传播 2012年22期

刘悦之

同济大学，上海 201804

0 引言

现在的软件项目开发中，必然涉及版本控制。

版本控制的功能在于跟踪记录整个软件的开发过程，包括软件本身和相关文档。在空间上可以保证完成集中统一管理，解决一致性和冗余问题。在时间上全程跟踪记录工具将会自动记录开发过程中的每个更改细节，和不同时期的不同版本，以便对不同阶段的软件及相关文档进行表示并进行差别分析，对软件代码进行可撤消的修改，便于汇总不同开发人员所做的修改，辅助协调和管理软件开发团队。

1 为什么选择Git

1.1 Git的优势

相对于其他流行的软件版本开源管理软件，Git的优势在哪里呢？

1.1.1 对网络的依赖性更低

虽然现在网络非常普及，但是并不是随时随地都有高速网络，低速的网络会让人心情烦躁，有时候就呆呆地盯着屏幕上的提交进度，什么事情也干不了。而Git的绝大部分操作在本地完成，不用和集中的代码管理服务器交互，只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。

1.1.2 方便的原子提交跟踪

Git的每次提交都会根据SHA-1算法生成唯一的commit id。而不像CVS那样都是对单个文件分别进行版本的更改。所以当你跟踪以前某次提交的代码时，不用考虑到底提交了哪些文件，所有的变动代码会一次性的取出来。

1.1.3 更方便的分支合并操作

Git的分支管理相对CVS 等系统容易多了，无论是建立新的分支，还是在分支之间切换都一条命令完成，不需要建立多余的目录。分支之间合并时，不仅代码会合并在一起，提交历史也会保留，这点非常有助于分支的管理与追踪。

1.2 Git的缺点

对于一个大型项目而言，在项目管理的过程中，只依靠Git原有的功能来进行版本控制管理是远远不够的。Git无法满足大型项目的管理要求。

1.2.1 对创建仓库、分支等操作的管理权限分级

Git是分布式版本控制工具，任何人都可以将自己的本地创建的分支、标签等注入到中央代码仓库中，极大的提高了中央仓库的维护成本。不利于大型项目的协同开发。

1.2.2 对多个仓库进行同步管理。

Git的每个仓库都是独立的，无法做到跟踪软件本身的同时，对软件相关文档也进行跟踪，无法对不同阶段的软件及相关文档进行差别分析，不利于团队协作和管理。

1.2.3 保护中央代码仓库以防污染

在用户从本地仓库向中央仓库提交代码的过程中，Git只是做了纯文本的合并，对代码规范、质量等不会做检查，无法避免中央代码仓库受到污染。

1.2.4 并行开发代码的提交冲突

并行开发带来的又一大问题就是代码提交冲突，Git需要手动解决冲突后再次提交，极大的降低了工作效率。

所以我们需要设计一个基于Git的分布式版本控制系统来弥补Git所存在的不足。

2 系统设计的主要思路

为了弥补Git的不足，本系统提出了一下方法来满足大型项目版本控制的需求。

2.1 多仓库同步分支管理

众所周知，对于一个大型项目，由于需求的不确定性风险、决策层沟通障碍风险或者技术路线风险都会使得项目发布日期的不断延迟并最终导致整个项目的失败，为了避免这种情况，大型项目往往采用了迭代式的开发模型，当开发到某一阶段就会发布一个版本给用户，然后根据用户体验，修改存在的问题或增加新的功能。

在大型项目的版本管理控制过程中，不仅需要管理项目源代码仓库，源代码对应的测试脚本仓库、环境配置文件仓库、与之相关的任何文件仓库都应该能被同时追踪，以此来保证项目生命周期内的任意时刻被追踪时，其相关的其他仓库代码也能被迅速定位。

为此，本系统提供了分支管理模块来让开发人员更好的管理各个发布版本并同步各代码仓库。

系统用主分支来维护团队内部日常代码开发的主线。每当要发布新版本时，系统管理员就可以选择各个仓库主分支上的某一次的原子提交，在这些原子提交上打上同一个标签，并在所有仓库中新建分支。这样，我们就可以根据标签同时追踪所有的仓库代码。

对于新建的分支，它已经包含主分支上直到所选择的原子提交的所有代码，当团队成员向本次准备发布的新版本提交特定的代码时，选择此版本的分支，新代码将只会提交到新分支上，而不会影响主分支上的代码。

如果提交的代码不仅仅需要用应用在此新版本上，在其他以后的版本或者已存在的版本也需要使用，比如修复了项目的某些BUG，那么开发人员可以使用代码合并模块来合并此次提交到特定的一些分支上。

2.2 多重代码审核减少污染

由于Git只是一个分布式的版本控制软件，它并不对代码质量进行审核，如何更有效的减少中央仓库污染对大型项目至关重要。对于一个大型项目，开发团队人数往往由几十人甚至几百人组成，每个人每天都要向中央代码库提交多次代码，在开发人员将代码提交到中央代码仓库之前，检查代码是否符合规范、是否有潜在的质量问题、避免互相影响造成额外的、非预期的错误是本系统的又一大主要功能。

首先，代码审核模块为管理员提供了配置项目子系统的功能。管理员可以将项目代码中不同目录下的文件划分不同的项目子系统，也可以称作模块。并设置一个或多个子系统审核员，他们可以是项目模块负责人、模块设计者等等。当开发人员提交了新代码后，系统将解析新代码对源代码中哪些文件做了修改，并根据文件路径辨识此次变动属于哪些子系统，然后，通知子系统审核员去审核新代码。如果审核人员发现代码存在问题，审核人员可以在系统中写下批注，拒绝提交成功，并退回给开发人员以供修改。

如果提交的代码通过了审核人员的审核，系统将把新代码文件上传至中央编译服务器，在中央编译服务器中，首先克隆一份最新的中央代码仓库的副本，将变动文件注入到副本中，如果在新代码提交的过程中，有别的开发者对同样的文件做了修改，并先一步提交到了中央代码仓库，那么此新代码将会和中央代码仓库中的文件产生冲突，系统将把冲突信息返回给开发人员，要求他基于最新的代码仓库提交变动代码。

当新代码通过了以上两步检验后，中央编译服务器将对新代码进行编译，以保证新的改动不会导致原程序编译失败。

2.3 减少代码提交冲突

本系统提供了一种名叫依赖补丁的选项，来尽量避免代码冲突产生，提高工作效。

当开发人员A提交了代码补丁文件后，系统会根据A的补丁文件记录的所有修改文件的历史记录，通知其相关的开发人员，并把A的补丁文件上传至服务器，此时B发现克隆到本地的最新中央代码仓库中不包含A的代码，他可以通过本系统下载A的补丁文件，并将补丁文件加载到本地仓库中，在此基础上进行开发。这样就可以大量避免代码冲突的产生。

但是，由于B的代码是基于A的补丁，如果B的代码被先审核，那么在补丁加载的过程中一定会失败，因为此时中央代码仓库中并不存在A的代码。所以B提交代码的时候必须选择A的补丁作为依赖项，在A的补丁没有通过审核流程时，B的补丁则不能被审核。以此来保证正确的审核顺序。

2.4 实时代码合并

随着项目的开发周期越来越长，分支和提交也会越来越多，也就不可避免的出现代码合并与分支合并。

根据本系统设计的理念，每个发布版本所对应的分支都是相对独立的，这样盲目的的分支合并存在的风险远远大于某次特定代码的合并。所以，我们通过实时的代码合并，来取代风险较大的分支合并。

根据系统设计，主分支是项目开发的主线，其他分支上的大部分的代码提交，除了那些与发布版本特性有关的代码，都应该被合并到主分支上。为此，系统在开发人员提交代码时，系统会默认当前提交需要被合并到主分支，同时会提醒开发人员，如果他的当前提交不需要合并到主分支，则应该取消该选项。新代码通过了子系统管理者的审核后，会在主分支和原目标分支上分别作冲突检查和编译检查。

正如我们前面提到过的，代码仓库中不仅有项目的核心代码，也会有测试脚本、配置文件等其他文件。由于编译检查是串行工作的，如果让脚本代码、配置文件这些变动更频繁的提交，每次合并都要对整个项目进行编译检查的话，会大大影响核心代码的提交效率，从而影响工作效率。所以本系统还提供了让管理员手动合并代码的功能。对于已经提交的代码，系统管理员可以将多次提交一次性地合并到多个分支上，这些合并只会做代码冲突检查，而不会做编译检查。