基于Git分布式版本控制系统设计及实现.docVIP

基于Git分布式版本控制系统设计及实现摘要 本文简要介绍了版本控制管理在软件项目开发过程中的重要性，以及主流版本控制工具Git在大型软件项目版本控制管理中的优点与缺点，并在保留Git原有优势的前提下，设计了一套版本控制系统，弥补Git的不足，使它能满足大型软件项目版本控制的需求。 关键词 版本控制；Git；分支管理；代码审核 中图分类号TP31 文献标识码A 文章编号 1674-6708（2012）79-0197-02 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多仓库同步分支管理 众所周知，对于一个大型项目，由于需求的不确定性风险、决策层沟通障碍风险或者技术路线风险都会使得项目发布日期的不断延迟并最终导致整个项目的失败，为了避免这种情况，大型项目往往采用了迭代式的开发模型，当开发到某一阶段就会发布一个版本给用户，然后根据用户体验，修改存在的问题或增加新的功能。 在大型项目的版本管理控制过程中，不仅需要管理项目源代码仓库，源代码对应的测试脚本仓库、环境配置文件仓库、与之相关的任何文件仓库都应该能被同时追踪，以此来保证项目生命周期内的任意时刻被追踪时，其相关的其他仓库代码也能被迅速定位。 为此，本系统提供了分支管理模块来让开发人员更好的管理各个发布版本并同步各代码仓库。 系统用主分支来维护团队内部日常代码开发的主线。每当要发布新版本时，系统管理员就可以选择各个仓库主分支上的某一次的原子提交，在这些原子提交上打上同一个标签，并在所有仓库中新建分支。这样，我们就可以根据标签同时追踪所有的仓库代码。 对于新建的分支，它已经包含主分支上直到所选择的原子提交的所有代码，当团队成员向本次准备发布的新版本提交特定的代码时，选择此版本的分支，新代码将只会提交到新分支上，而不会影响主分支上的代码。 如果提交的代码不仅仅需要用应用在此新版本上，在其他以后的版本或者已存在的版本也需要