绿色，已经加入控制暂未提交红色，未加入版本控制蓝色，加入，已提交，有改动白色，加入，已提交，无改动灰色：版本控制已忽略文件

1.TestDirector(大而全)2.jira(简单好用)3.Quality Center(复杂，收费)4.禅道(简单好用)5.bugzilla(功能简单)6.svn(代码和文档管理工具)7.vss类似svn8.git，同svn，但是多分支管理比svn好9.Note(大而全，费用太贵)10.CQ(ClearQuest-IBM产品-大而全)

冲冲冲

每天学习SVN直到灵活运用基础操作

svn是集中式版本控制系统，git是分布式版本控制系统。svn就是所有人修改的都是服务器上的程序，如果有人修改了同样的部分，那就冲突了。所以呢，一般团队会约定，对于公共部分的程序，尽量标注出开发人员特有标识，又或者A从上添加，B从下添加。git就是开发人员创建自己的分支，这个分支就相当于将源码copy一份在本机上，之后修改的都是本地的代码，可随时拉取服务器的代码进行同步，git可创建无数分支，开发人员只需将自己修改的代码提交就可以了，这样冲突的几率会小很多。svn是直接与服务器进行交互，git是将项目缓存在本地再推送到服务器。svn必须在联网的情况下工作，git可不联网开发。svn易冲突，git不易冲突。svn旨在项目管理，git旨在代码管理。svn适用于多项目并行开发，git适用于单项目开发。svn适用于企业内部，由项目经理协调多个项目统筹开发，git适用于通过网络多人开发同一项目。

svn是集中式版本控制系统，git是分布式版本控制系统。svn就是所有人修改的都是服务器上的程序，如果有人修改了同样的部分，那就冲突了。所以呢，一般团队会约定，对于公共部分的程序，尽量标注出开发人员特有标识，又或者A从上添加，B从下添加。git就是开发人员创建自己的分支，这个分支就相当于将源码copy一份在本机上，之后修改的都是本地的代码，可随时拉取服务器的代码进行同步，git可创建无数分支，开发人员只需将自己修改的代码提交就可以了，这样冲突的几率会小很多。svn是直接与服务器进行交互，git是将项目缓存在本地再推送到服务器。svn必须在联网的情况下工作，git可不联网开发。svn易冲突，git不易冲突。svn旨在项目管理，git旨在代码管理。svn适用于多项目并行开发，git适用于单项目开发。svn适用于企业内部，由项目经理协调多个项目统筹开发，git适用于通过网络多人开发同一项目。

什么是DevOps？DevOps概述DevOps，即Development and Operations，是一组过程、方法与系统的统称，用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。DevOps可看作开发、运维和质量保障（QA）三者的交集。DevOps运动源自于提高IT服务交付敏捷性的需要，早期出现在许多大型公有云服务提供商中，并被其认可。支撑DevOps的理念基础是敏捷宣言，它强调人（和文化），致力于改善开发和运维团队之间的协作。从生命周期的角度来看，DevOps的实施者也试图更好地利用技术，尤其是自动化工具，来支撑越来越多的可编程的动态的基础设施。DevOps的技术实践一、配置管理软件配置管理的核心功能是版本控制。版本控制系统是一种软件，可以管理代码的所有版本并跟踪代码中的更改。1、分布式Git VS 集中式SVN版本控制系统分为集中式和分布式两种工作模式，Git和SVN是最为广泛被使用的代表，Git由于其诸多特点，更适合DevOps。安全性——Git是分布式，而SVN是集中式，存在单点故障风险。分支功能——Git分支功能强大，便于查询和追溯分支间的提交历史，且支持双向合并。发布控制——Git发布控制相当灵活，而SVN并没有明确的发布控制配置。开发审核——Git支持团队成员自建分支和版本库，从提交说明、代码规范等方面对提交逐一审核；而SVN则不具备这些功能。合并支持——Git基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，避免不必要的冲突，提高了工作效率。存储方式——Git把内容按元数据方式存储，而SVN是按文件。分布式Git VS 集中式SVN版本控制系统分为集中式和分布式两种工作模式，Git和SVN是最为广泛被使用的代表，Git由于其诸多特点，更适合DevOps。       2、包文件包文件通常不放在源码库中管理，而是使用专门的包文件仓库（repository）进行存储，并配合包文件依赖管理工具（Maven、npm、Ivy等）进行使用。包文件仓库可以大致分为本地仓库、私服仓库、中央仓库三种。本地仓库是指开发者个人PC中包文件的存储；私服仓库通常是企业为了提升包文件使用性能而搭建的局域网内共用的包文件仓库，通常使用开源的Nexus、artifactory等工具搭建；中央仓库是指开源包文件的共享社区。开发人员对包文件的使用集中在下载、搜索、发布上传几个操作上。开发和构建时，开发人员通过包依赖管理工具定义好需要使用的私有及开源包文件，在构建或运行时自动从私服仓库或开源中央仓库中下载依赖包文件来提升开发效率。二、持续集成（Continuous Integration）持续集成（CI）是一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次——这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快地检测出集成错误。持续集成过程中的角色与职责如下：角色职责开发人员完成开发任务，并在向版本控制库提交代码之前，先在本地环境完成一次私有构建。修改反馈回来的代码问题，保持集成构建的绿灯状态。测试人员根据项目进展随时更新自动化测试脚本，并保证代码覆盖率达到团队要求。运维人员根据开发人员的需要，及时更新维护自动化构建脚本。维护整个CI流水线的正常运行。  三、持续交付（Continuous Delivery）持续交付（CD）是从构建环境到生产环境的构建、测试、配置和部署的过程。持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。  四、基础设施即代码（Infrastructure as Code）作为代码的基础设施（IaC）是描述性模型中的基础设施（网络、虚拟机、负载平衡器和连接拓扑）的管理，使用与DevOps团队用于源代码相同的版本。与同一源代码生成相同二进制文件的原则一样，IaC模型在每次应用时都会生成相同的环境。IaC是DevOps的关键实践，与持续交付结合使用 。实施IaC的团队可以快速、大规模地提供稳定的环境。团队通过代码表示环境的期望状态，从而避免手动配置环境并强制实现一致性。使用IaC进行基础架构部署是可重复的，可防止因配置偏差或缺少依赖性而导致的运行时问题。DevOps团队可以与一组统一的实践和工具协同工作。快速，可靠，大规模地交付应用程序及其支持基础架构。DevOps转型的研发工具链快速交付的关键是“自动”与“可靠”。自动是一个很宽泛的词汇，在软件交付中代表着测试自动化、交付自动化、运维自动化等等，而可靠讲的是每一次交付要保证是当前的交付是稳定的或可回滚到稳定版本的。为了解决“自动”与“可靠”的问题，敏捷开发鼻祖Martin Fowler提出了持续集成与持续交付的概念，它所描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。通过这种小步快跑的方式，将小功能快速迭代、验证、交付，通过自动化的工具，将测试、部署、运维自动化，减少需求在软件生命周期中流动的时间。华为将自身积累的先进研发能力与优秀实践开放，融合敏捷、精益、DevOps等先进研发理念，打造开放完整的云端开发生态，推出了一站式、全流程、安全可信的DevOps云平台——DevCloud。

本帖最后由 DevCloud 于 2017-9-22 14:43 编辑

对于软件开发人员来说，版本控制系统他们再熟悉不过了，所谓版本控制系统就是软件项目开发过程中用于储存开发人员所写代码所有修订版本的软件。它的主要目的是实现开发团队并行开发、提高开发效率，对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，从而减轻开发人员的负担，节省时间，同时降低人为错误。而目前常见的版本控制系统分为集中式版本控制系统和分布式版本控制系统两种。 SVN和Git 在集中式版本控制系统中，目前比较常用的是SVN，而说起SVN就不能不谈CVS，CVS是一个C/S系统，主要在开源软件管理中使用。多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。CVS版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。但是由于CVS编码存在一些问题，大多数软件开发公司都使用SVN替代了CVS。SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。 而在分布式版本控制系统中，Git逐渐占据了上风，目前，国外最大的社交编程及代码托管网站Github，Bitbucket，Gitlab，国内的码云、Coding、华为软件开发云（DevCloud）中的配置管理等代码托管平台均支持Git。Git是一款免费、开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是Linux内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper 的许可证并不适合开放源码社区的工作，因此Torvalds决定着手研究许可证更为灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了Git。 而随着拥有分布式版本控制系统优势的Git的快速发展，越来越多的开发者准备从集中式版本控制系统SVN迁移到Git上，这其中，Git相对SVN表现出来的更有利于开发者版本控制管理的特点自然是最重要的原因。 Git vs. SVN 因为从属于不同的集中和分布式模式，因此，从工作模式来看，Git和SVN存在着比较明显的不同，如下图所示。 1.png (27.29 KB, 下载次数: 1) 下载附件 保存到相册 4 天前 上传 集中式版本控制系统工作模型 2.png (22.04 KB, 下载次数: 1) 下载附件 保存到相册 4 天前 上传 分布式版本控制模型从两者的工作模式可以看到，分布式相比于集中式的最大区别在于开发者可以提交代码到本地，每个开发者通过克隆（Git clone），在本地机器上拷贝一个完整的Git仓库。而SVN则必须将代码提交到中心控制器。而由此产生的差异性，则决定了Git和SVN的各自的特性。 安全性 首先在安全性方面，由于采用分布式系统，每个用户就相当于一个Git库的备份，同时，通过SHA1哈希保证数据的完整性，防止恶意篡改，因此，具有很高的安全性。而SVN由于采用集中式，因此，所有代码版本库均存储在中央服务器中，因此，存在很大的单点故障的风险，同时，当服务器端历史数据被篡改时，客户端难以发现。 分支功能 在分支功能方面，由于Git采用本质上指向Commit对象的可变指针，因此，便于查询和追溯分支间的提交历史，并能够支持双向合并。而SVN分支不支持提交隔离，虽然一次提交可同时更改主线和分支的内容，但无法查询和追溯分支间的提交历史。 发布控制 在Git中，可以设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护，还可以设置只有项目经理、模块管理员才有权推送的版本库或者分支，用于整合测试，因此，发布控制相当灵活，而SVN并没有明确的发布控制配置，更多的还是依靠用户自己的习惯。 开发审核 在开发审核方便，Git支持团队成员自建分支和版本库。通过合并请求或从成员个人版本库、分支获取提交，从提交说明、代码规范等方面对提交逐一审核。而SVN则不具备这些功能。 合并支持 Git基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，避免不必要的冲突，提高了工作效率。而Git基于对内容的追踪而非对文件名追踪，所以遇到一方或双方对文件名更改时，能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突，解决起来很麻烦。 因此，从以上的对比可以看出，Git相对于SVN具有不少的优势，因此，从SVN迁移到Git成为了众多开发者的选择。 从SVN到Git 那么，从SVN到底如何切换到Git呢？实际上，方法有很多种，也都并不是很复杂，其中，CSDN博主UrChen提供了一种切换的方法，只需要简单的几步，即可完成从SVN完美切换到Git。 1.使用git svn clone 拷贝SVN仓库 cd ~/test_repo git svn clone file:///home/*/Desktop/SVN/svn_repo/ -T trunk -b branches -t tags 2.新建一个Git的bare仓库 cd .. mkdir test.git cd test.git git init --bare 3.将Git的默认分支和SVN的默认分支trunk对应起来 git checkout trunk 4.将test_repo推送到test.git中 cd ~/test_repo git remote add bare ~/test.git git push bare 此时就完成了推送，可以删除test_repo了 5.将Git repo中的trunk重命名为master cd ~/test.git git branch -m trunk master 6.将SVN repo中的tags移动到git repo的相应位置 使用git svn clone导出版本库的时候会将svn中的tags保存成git中的tags/**，而并不是默认的tag，所以要进行移动。（注意：此脚本仅示例tag是单级目录的情况，如果 tag 是包含目录的两级或者多级tag，请自行重新撰写脚本） cd ~/test.git git for-each-ref --format=´%(refname)´ refs/heads/tags | cut -d / -f 4 | while read ref do git tag "$ref" "refs/heads/tags/$ref"; git branch -D "tags/$ref"; done 7.完成迁移，得到test.git 进入工作文件夹，执行 git clone ~/test.git OK，大功告成，使用Git进行版本管理吧。 除此之外，还有几个问题需要说明： 1、通过git-svn工具可以在SVN迁移到Git上，保留仓库历史记录。 2、切换到Git后推荐策略建议采用长期分支、特性分支。 3、目前Git还没法做到像SVN中对特定文件夹的细分权限控制，但可通过分仓或建立多分支的方式引导用户使用。 4、切换到Git后遇到合并冲突时，分两种情况： 类型1：修改了同一个文件的同一行 解决方法：确认正确的修改，然后用命令行解决，示例如下： 4.png (53.17 KB, 下载次数: 1) 下载附件 保存到相册 4 天前 上传 类型2：文件被重命名为不同的名字（树冲突） 解决办法：确认哪个名字是正确的，删除错误的，示例如下： 5.png (38.04 KB, 下载次数: 1) 下载附件 保存到相册 4 天前 上传 DevCloud与Git 前面已经说过，华为软件开发云（DevCloud）中的配置管理服务全面支持Git，并对Git进行了全面优化。而实际上，这个配置管理服务就是面向软件开发者提供的基于Git的在线代码托管服务。对于管理员和项目经理，它提供了仓库管理、权限管理、成员管理、分支保护、安全管控及统计服务，对于开发者，它则提供了代码托管、代码仓库、在线客户端等服务。配置管理服务的产品架构图，如下图所示： 3.png (178.25 KB, 下载次数: 1) 下载附件 保存到相册 4 天前 上传 DevCloud的配置管理服务对Git的优化主要体现在以下几点： 1）支持跨地域协同开发、本地离线操作、代码合入评审。 2）支持在线客户端、代码在线浏览、修改、提交、在线创建分支、比较分支、新建合并请求。 3）具有代码加密传输、仓库权限管理、分支保护等多种安全措施。 4）提供了大量的仓库模板、通用模板，以方便开发者提高创建效率。 5）提供基于代码的统计分析、仓库提交信息统计、贡献者统计等相关统计数据。 总结 总之，从SVN切换到Git目前来看，是利多弊少，也是一个趋势，建议有条件的开发人员可以尝试一下，此外，DevCloud中的配置管理针对开发人员使用Git做了大量的优化工作，感兴趣的朋友也可以登录http://www.hwclouds.com/devcloud/网站下载试用，体验一把用优化了的Git进行版本控制的感受！

对于软件开发人员来说，版本控制系统他们再熟悉不过了，所谓版本控制系统就是软件项目开发过程中用于储存开发人员所写代码所有修订版本的软件。它的主要目的是实现开发团队并行开发、提高开发效率，对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，从而减轻开发人员的负担，节省时间，同时降低人为错误。而目前常见的版本控制系统分为集中式版本控制系统和分布式版本控制系统两种。 SVN和Git 在集中式版本控制系统中，目前比较常用的是SVN，而说起SVN就不能不谈CVS，CVS是一个C/S系统，主要在开源软件管理中使用。多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。CVS版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。但是由于CVS编码存在一些问题，大多数软件开发公司都使用SVN替代了CVS。SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。 而在分布式版本控制系统中，Git逐渐占据了上风，目前，国外最大的社交编程及代码托管网站Github，Bitbucket，Gitlab，国内的码云、Coding、华为软件开发云（DevCloud）中的配置管理等代码托管平台均支持Git。Git是一款免费、开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是Linux内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper 的许可证并不适合开放源码社区的工作，因此Torvalds决定着手研究许可证更为灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了Git。 而随着拥有分布式版本控制系统优势的Git的快速发展，越来越多的开发者准备从集中式版本控制系统SVN迁移到Git上，这其中，Git相对SVN表现出来的更有利于开发者版本控制管理的特点自然是最重要的原因。 Git vs. SVN 因为从属于不同的集中和分布式模式，因此，从工作模式来看，Git和SVN存在着比较明显的不同，如下图所示。 169 集中式版本控制系统工作模型170 分布式版本控制模型从两者的工作模式可以看到，分布式相比于集中式的最大区别在于开发者可以提交代码到本地，每个开发者通过克隆（Git clone），在本地机器上拷贝一个完整的Git仓库。而SVN则必须将代码提交到中心控制器。而由此产生的差异性，则决定了Git和SVN的各自的特性。 安全性 首先在安全性方面，由于采用分布式系统，每个用户就相当于一个Git库的备份，同时，通过SHA1哈希保证数据的完整性，防止恶意篡改，因此，具有很高的安全性。而SVN由于采用集中式，因此，所有代码版本库均存储在中央服务器中，因此，存在很大的单点故障的风险，同时，当服务器端历史数据被篡改时，客户端难以发现。 分支功能 在分支功能方面，由于Git采用本质上指向Commit对象的可变指针，因此，便于查询和追溯分支间的提交历史，并能够支持双向合并。而SVN分支不支持提交隔离，虽然一次提交可同时更改主线和分支的内容，但无法查询和追溯分支间的提交历史。 发布控制 在Git中，可以设置只有发布管理员才有权限推送的版本库或者分支，用于稳定发布版本的维护，还可以设置只有项目经理、模块管理员才有权推送的版本库或者分支，用于整合测试，因此，发布控制相当灵活，而SVN并没有明确的发布控制配置，更多的还是依靠用户自己的习惯。 开发审核 在开发审核方便，Git支持团队成员自建分支和版本库。通过合并请求或从成员个人版本库、分支获取提交，从提交说明、代码规范等方面对提交逐一审核。而SVN则不具备这些功能。 合并支持 Git基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，避免不必要的冲突，提高了工作效率。而Git基于对内容的追踪而非对文件名追踪，所以遇到一方或双方对文件名更改时，能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突，解决起来很麻烦。 因此，从以上的对比可以看出，Git相对于SVN具有不少的优势，因此，从SVN迁移到Git成为了众多开发者的选择。 从SVN到Git 那么，从SVN到底如何切换到Git呢？实际上，方法有很多种，也都并不是很复杂，其中，CSDN博主UrChen提供了一种切换的方法，只需要简单的几步，即可完成从SVN完美切换到Git。 1.使用git svn clone 拷贝SVN仓库 cd ~/test_repo git svn clone file:///home/*/Desktop/SVN/svn_repo/ -T trunk -b branches -t tags 2.新建一个Git的bare仓库 cd .. mkdir test.git cd test.git git init --bare 3.将Git的默认分支和SVN的默认分支trunk对应起来 git checkout trunk 4.将test_repo推送到test.git中 cd ~/test_repo git remote add bare ~/test.git git push bare 此时就完成了推送，可以删除test_repo了 5.将Git repo中的trunk重命名为master cd ~/test.git git branch -m trunk master 6.将SVN repo中的tags移动到git repo的相应位置 使用git svn clone导出版本库的时候会将svn中的tags保存成git中的tags/**，而并不是默认的tag，所以要进行移动。（注意：此脚本仅示例tag是单级目录的情况，如果 tag 是包含目录的两级或者多级tag，请自行重新撰写脚本） cd ~/test.git git for-each-ref --format='%(refname)' refs/heads/tags | cut -d / -f 4 | while read ref do git tag "$ref" "refs/heads/tags/$ref"; git branch -D "tags/$ref"; done 7.完成迁移，得到test.git 进入工作文件夹，执行 git clone ~/test.git OK，大功告成，使用Git进行版本管理吧。 除此之外，还有几个问题需要说明： 1、通过git-svn工具可以在SVN迁移到Git上，保留仓库历史记录。 2、切换到Git后推荐策略建议采用长期分支、特性分支。 3、目前Git还没法做到像SVN中对特定文件夹的细分权限控制，但可通过分仓或建立多分支的方式引导用户使用。 4、切换到Git后遇到合并冲突时，分两种情况： 类型1：修改了同一个文件的同一行 解决方法：确认正确的修改，然后用命令行解决，示例如下： 173 类型2：文件被重命名为不同的名字（树冲突） 解决办法：确认哪个名字是正确的，删除错误的，示例如下： 174 DevCloud与Git 前面已经说过，华为软件开发云（DevCloud）中的配置管理服务全面支持Git，并对Git进行了全面优化。而实际上，这个配置管理服务就是面向软件开发者提供的基于Git的在线代码托管服务。对于管理员和项目经理，它提供了仓库管理、权限管理、成员管理、分支保护、安全管控及统计服务，对于开发者，它则提供了代码托管、代码仓库、在线客户端等服务。配置管理服务的产品架构图，如下图所示： 171 DevCloud的配置管理服务对Git的优化主要体现在以下几点： 1）支持跨地域协同开发、本地离线操作、代码合入评审。 2）支持在线客户端、代码在线浏览、修改、提交、在线创建分支、比较分支、新建合并请求。 3）具有代码加密传输、仓库权限管理、分支保护等多种安全措施。 4）提供了大量的仓库模板、通用模板，以方便开发者提高创建效率。 5）提供基于代码的统计分析、仓库提交信息统计、贡献者统计等相关统计数据。 总结 总之，从SVN切换到Git目前来看，是利多弊少，也是一个趋势，建议有条件的开发人员可以尝试一下，此外，DevCloud中的配置管理针对开发人员使用Git做了大量的优化工作，感兴趣的朋友也可以登录http://www.hwclouds.com/devcloud/网站下载试用，体验一把用优化了的Git进行版本控制的感受！