java源码管理与版本控制工具？

java项目一般都是团队开发，当多人共同编写一个项目的时候。代码的整合就需要用到专门的源码管理工具了。另外java项目版本的不断更新，也需要版本的管理。所以源码管理与版本控制工具也是每个java程序员必须要熟练掌握的。目前比较流行的java版本控制工具主要有svn、git这两款软件。霍营北大青鸟认为这两种工具也是每个java程序员必须要熟练掌握的。

SVN

SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。SVN的缺陷是过分依赖网络，不适合分布式开发。

使用svn的工作流程如下：1、早上从从服务器下载项目组最新代码。

2、进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。

3、下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。

Git

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。

Git是LinusTorvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。与常用的版本控制工具CVS,Subversion等不同，它采用了分布式版本库的方式，不必服务器端软件支持（ps：这得分是用什么样的服务端，使用>

目前GIT已经可以在windows下使用，主要方法有二：msysgit和Cygwin。Cygwin和Linux使用方法类似，Windows版本的GIT提供了友好的GUI(图形界面)，安装后很快可以上手使用。

封版本的目的在于给开发定一个阶段性的目标，否则很有可能会出现开发过程无休止。封版本之后是可以修改代码的，但是无论是出于什么目的修改代码，那都是下一阶段的事情了。

版本控制基本流程如下：

1、创建配置项。

项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0YZ。

2、修改状态为“草稿”的配置项目。

项目成员使用配置管理软件的Check in/check out功能，可以自由修改处于“草稿”状态的配置项，版本号格式为0YZ。

3、技术评审或领导审批。

如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理(或上级领导)的审批。若配置项通过了技术评审或领导审批，则转向下一步·否则转回上一步。

4、正式发布。

配置项通过技术评审或领导审批之后。则配置项的状态从“草稿”变为“正式发布”，版本号格式为XY。

5、变更。

修改处于“正式发布”状态的配置项，必须按照“变更控制流程”执行。

常用工具

1．开源版本控制工具

开放源码的版本控制工具有很多，如Concurrent Versions System( CVS)、Subversion( SVN)、Vesta、Revision Control System( RCS)、Source Code Control System( SCCS)等。比较常用的两个工具是CVS和SVN。

CVS是Dick Grune在1984年～1985年基于RCS开发的一个客户一服务器架构的版本控制软件，长久以来一直是免费版本控制软件的主要选择。SVN的一个重要开发目标是修正CVS中广为人知的缺点，提供一个新的版本控制软件。

对于中小规模团队，SVN是一个比较好的开源版本控制工具，SVN常用客户端工具为TortoiseSVN。

2．成熟的商业工具

商业工具提供了比开源版本控制工具更多的，尤其是和软件配置管理有关的功能。

IBM公司的Rational ClearCase是一款重量级的软件配置管理软件，为大中型软件开发企业提供了版本控制、工作空间管理、平行开发支持以及版本审计，可以为拥有上千开发者的大型项目提供全面配置管理支持。

以上内容参考 百度百科-版本控制

通过划分版本，分阶段递进式实现项目目标2、版本控制的表现形式：
21、通过一个版本号可以取得与此版本相关的所有工作产品22、项目活动与版本号相关联3、版本控制管理的项目活动范围：
在项目的招投标、立项、预研、需求、开发、测试、发布、实施、运营等活动中，至少应将需求、开发、测试、发布、实施活动纳入版本控制的范围。4、版本控制管理的工作产品范围：
41、配置库中工程活动的所有工作产品42、需求跟踪表考虑到实际需要，需求跟踪表中需求状态记录部分也应纳入版本控制，以方便获取此部分信息5、版本控制使用的工具：
51、cvs、svn、vss等工具管理工作产品版本。52、bugzilla、mantis、TD等6、版本的划分：
61、版本的划分工作在项目计划中进行，在项目工作实际进行过程中，如频繁出现内部版本（主要指内部测试β版），为保证项目计划的可视性，可在wbs中进行此部分版本划分工作。62、版本划分方法版本按是否通过验证分为β版本和正式版本。β版本通过测试和评审后成为相应的正式版本。所有β版本隶属于其对应的正式版本。正式版本按以下维度划分：621、按最终交付对象的不同可分为内部版本和交付用户的版本。622、按与上一版本的不同可分为功能增加版本、功能优化版本、bug修复版本等。623、按重要程度不同可分为一般版本，重要版本，里程碑版本。交付用户的版本必须为里程碑版本或重要版本。不同重要程度的版本投入的资源不同，包括评审、测试活动的范围、力度不同。63、版本号规则正式版本：对于Bug修复版本，版本号的第三位发生变化，对于其他版本，版本号的第一和第二位发生变化β版本：版本号为对应的正式版本号加β1、β2、β3等，按数字大小顺序编排7、版本控制活动
71、项目经理在项目计划中编制正式版本任务，明确其重要性为一般、重要或里程碑，明确是否需对外发布，明确与上个版本的不同。72、在wbs中将正式版本任务拆分为多个β版本任务，同一个正式版本对应的不同β版本间仅仅存在bug修复的差异。73、在wbs中将β版本任务拆分为涵盖需求、开发、测试、发布、实施、反馈等不同阶段的子任务。74、监控每个子任务按流程执行。

---