代码分支管理方法及装置与流程

本发明涉及计算机
技术领域：
，特别涉及一种代码分支管理方法及装置。
背景技术：
：目前比较主流的代码分支管理方法有三种，即主干开发(trunk-baseddevelopment,tbd)、gitflow、githubflow。其中主干开发分支适合敏捷的小规模团队合作，通过频繁的合并保持主干代码的健壮性；gitflow较为复杂，对特性分支的管理要求较高，如果不按照约定规则提交和合并代码，极易发生代码冲突；githubflow需要浓厚的敏捷意识，类似主干开发，强调频繁提交、频繁合并，更适合开源社区等专业团体。主干开发代码分支管理方法，简述如下：在采用"主干开发"时，代码一般提交到主干的头部，保证了所有用户看到的都是同一份代码的最新版本。"主干开发"避免了合并分支时的麻烦。大多数时候，发布分支是主干某个时点的快照。以后的除错和功能增强，都是提交到主干，必要时cherry-pick(挑拣提交)到发布分支。由于不采用"分支开发"，引入新功能一般在代码中使用开关控制。这避免了另起一个分支，也使得通过配置切换功能变得容易，一旦新功能发生故障很容易切换回旧功能。等到新功能稳定再彻底删除旧代码。但在实际开发工作中，单一主干开发的代码管理在项目新建立期间问题不大，但是如果项目进入到维护期时，容易引起如下问题：在版本连续开发中，项目开发和代码测试存在时间差，导致代码无法及时检测，从而会导致无法快速发布稳定的可商用的版本的问题。gitflow代码分支管理方法，简述如下：gitflow支持如下特性：1.并行开发：gitflow可以很方便的实现并行开发。每个新功能都会建立一个新的feature分支(即特性分支)，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的feature分支才会合并到develop分支上。另外，如果你正在开发某个功能，同时又有一个新的功能需要开发，你只需要提交当前feature(功能)的代码，然后创建另外一个feature分支并完成新功能开发。然后再切回之前的feature分支即可继续完成之前功能的开发；2.协作开发：gitflow还支持多人协同开发，因为每个feature分支上改动的代码都只是为了让某个新的feature可以独立运行。同时我们也很容易知道每个人都在干啥；3.发布阶段：当一个新feature开发完成的时候，它会被合并到develop分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的feature，我们只需要从develop分支创建新分支，即可包含所有已经完成的feature；4.支持紧急修复：gitflow还包含了hotfix分支(热修复分支)。这种类型的分支是从某个已经发布的tag上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的tag，而不会影响到你正在开发的新feature。但目前思特沃克(thoughtworks)公司，在月刊里曾多次表明了gitflow背后的featurebranch(特性分支)模型在生产实践中的危害。gitflow有如下版本开发后合并困难的缺点：gitflow重视管理，强调多分支开发，会造成集成滞后，合并困难，影响持续集成。long-livedfeaturebranch(持久的特性分支)是一个常见的持续交付反模式。这是因为如果项目拥有多个长期彼此独立演进的分支，往往需要等到最后发布时才合并代码，这与持续集成的最佳实践背道而驰。如果能做到频繁的合并，那么gitflow没有问题。然而经常出现的一个问题是，许多人开始使用git来逃避可怕的合并冲突。无论开发人员使用的源代码管理工具或模式如何，一旦开发人员等了一两天才进行合并工作，就可能会遇到一场大的合并冲突。如果开发人员有不止一个人在等待合并，则可能会有严重的瓶颈。引入像gitflow这样的模式需要经常合并才能成功。gitflow背后是一套featurebranch(特性分支)模型。featurebranch最明显的两个好处是：其一是各个feature之间的代码是隔离的，可以独立地开发、构建、测试；其二是当feature的开发周期长于release(发布)周期，可以避免未完成的feature进入生产环境。但在坚持持续集成实践的情况下，featurebranch存在着如下问题：持续集成在鼓励更加频繁的代码集成和交互，让冲突越早解决越好，而featurebranch的代码隔离策略却在尽可能推迟代码的集成。延迟集成所带来的恶果在软件开发的历史上已经多次出现，每个团队撰写自己的代码很顺畅，但到最后不同团队进行联调集成的时候就暴露了问题，常会造成开发团队写两个月代码，但却需花一个月时间集成，质量还无法保证的情况发生。githubflow代码分支管理方法，简述如下：githubflow针对的场景是每天发布几次产品代码的场景，以敏捷的方式每天多次解决小问题。githubflow只有master分支(即主分支)和feature分支，相当于把gitflow的master分支和develop分支合(即开发分支)并为一个分支。githubflow以部署为中心的开发模式，通过简单的功能和规则，持续且高速安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。但在使用githubflow时，对开发团队规模有限制，最好控制在15-20人之内。综上，目前比较主流的三种代码分支管理方法，为主干开发(trunk-baseddevelopment,tbd)、gitflow、githubflow。但主干开发有着代码检测难以及时进行的问题，gitflow有着在项目开发时代码分支难以合并的问题，而githubflow则有着开发人员人数受限的问题。在大型企业对代码管理强度的要求逐渐增加的情况下，并未出现一种能良好解决上述问题的代码管理方式。技术实现要素：本发明实施例提供了一种代码分支管理方法，用以支持多人同时进行项目开发，以及及时地进行代码检测和代码分支合并，该方法包括：从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；对完成开发的个人开发分支进行本地集成测试；若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；若用户验收测试通过，将发布分支的代码合并到主分支。本发明实施例还提供了一种代码分支管理装置，用以支持多人同时进行项目开发，以及及时地进行代码检测和代码分支合并，该装置包括：个人开发分支创建模块，用于从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；本地集成测试模块，用于对完成开发的个人开发分支进行本地集成测试；系统集成测试模块，用于若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；用户验收测试模块，用于若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；主分支合并模块，用于若用户验收测试通过，将发布分支的代码合并到主分支，对主分支的代码进行投产使用。本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述所述方法。本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述所述方法的计算机程序。本发明实施例中，从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；对完成开发的个人开发分支进行本地集成测试；若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；若用户验收测试通过，将发布分支的代码合并到主分支，从而通过允许创建个人开发分支，可同时支持众多开发人员同时进行项目开发；通过将个人开发分支的代码合并到开发分支，可将开发人员的代码及时地合并到开发分支，提高了代码合并的时效性；通过本地集成测试和系统集成测试，可对代码分支及时地进行检测，与现有技术对比，在系统集成测试之前，可先进行本地集成测试，提高了代码检测的效率。附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本发明实施例提供的一种代码分支管理方法的流程示意图；图2是本发明实施例提供的一个代码分支管理方法的实例的流程示意图；图3是本发明实施例提供的一种代码分支管理装置的结构示意图；图4是本发明实施例提供的一种代码分支管理装置的结构示意图；图5是本发明实施例提供的一种代码分支管理装置的结构示意图。具体实施方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本发明实施例涉及如下名词，下面对涉及的名词作出解释：git：git是一个分布式的版本控制工具。git在用户本地就能进行完整的版本控制工作，对文件修改的版本信息进行保存、修改和回滚等。不同用户之间，可以通过git服务器进行协作。branch(分支)：分支可以把部分工作从开发主线上分离开来，以免影响开发主线。sit(系统集成测试)：sit，英文systemintegrationtest的简写，即系统集成测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。uat(用户验收测试)：uat，英文useracceptancetest的简写，即用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。目前比较主流的三种代码分支管理方法，为主干开发(trunk-baseddevelopment,tbd)、gitflow、githubflow。如表1所示，是三种代码分支管理的对比表格。但主干开发有着代码检测难以及时进行的问题，gitflow有着在项目开发时代码分支难以合并的问题，而githubflow则有着开发人员人数受限的问题。在大型企业对代码管理强度的要求逐渐增加的情况下，并未出现一种能良好解决上述问题的代码管理方式。表1：分支管理方式对比在本发明实施例中，提供了一种代码分支管理方法，用以支持多人同时进行项目开发，以及及时地进行代码检测和代码分支合并，如图1所示，该方法包括：步骤101：从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；步骤102：对完成开发的个人开发分支进行本地集成测试；步骤103：若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；步骤104：若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；步骤105：若用户验收测试通过，将发布分支的代码合并到主分支。本发明实施例提供了一种代码分支管理方法及装置，该方法包括：项目开发中，从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；对完成开发的个人开发分支进行本地集成测试；若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；若用户验收测试通过，将发布分支的代码合并到主分支，对主分支的代码进行投产使用。本发明实施例，从而通过允许创建个人开发分支，可同时支持众多开发人员同时进行项目开发；通过将个人开发分支的代码合并到开发分支，可将开发人员的代码及时地合并到开发分支，提高了代码合并的时效性；通过本地集成测试和系统集成测试，可对代码分支及时地进行检测，与现有技术对比，在系统集成测试之前，可先进行本地集成测试，提高了代码检测的效率。在一实施例中，从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发。个人开发分支，用于开发人员个人开发使用，支持读写，是基于develop分支创建，包含所有要部署到个人测试环境的代码，用于开发人员在本地进行项目开发；个人开发分支视情况可创建多条，个人开发分支存在的意义在于让每个人可以持续集成自己的代码。具体实施时，对完成开发的个人开发分支进行本地集成测试，可以包括：对开发人员完成开发的多个个人开发分支进行本地集成测试。对个人开发分支进行本地集成测试，可以更好更及时地对代码进行检测，如开发人员在本地代码完成后即可初步对代码进行本地集成测试，避免在后续的代码检测过程中引起更大的误差。具体实施时，若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试。开发(develop)分支，不直接提交代码，开发分支一直作为功能最新最全的分支，对应sit环境，长期存在，读写格式为只读；开发分支有且仅有一条。而进行系统集成测试，时在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。具体实施时，若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试。发布(release)分支基于最新版本的develop分支创建，对应uat环境，用于对项目进行投产发布，读写格式为只读。当新功能足够发布一个新版本，从develop分支创建一个release分支作为新版本的起点，对应uat环境或预发环境。而进行用户验收测试(也可称作用户可接受测试)，是由相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收，用于让系统用户决定是否接收系统。具体实施时，若用户验收测试通过，将发布分支的代码合并到主分支。主(master)分支存放所有生产环境发布过的版本，作为项目历史版本记录分支，不直接提交代码。主(master)分支始终对应生产环境服务版本。主分支不做任何测试、开发、修复，仅用于保持一个对应线上运行代码的codebase(代码源)。主分支长期存在，读写格式为只读，主分支有且仅有一条。具体实施时，本发明实施例提供的一种代码分支管理方法还包括：从个人开发分支获取代码，创建特性分支；将特性分支的代码合并到个人开发分支。特性(feature)分支基于develop分支创建，主要用于新功能的开发，支持多人合作开发新功能，支持读写，可以按照功能点命名，举例如dashboard(仪表板)；特性分支也可称为功能开发分支，完成的功能开发完毕后合到develop分支。feature分支可同时存在多个，用于团队中多个功能同时开发；属于临时分支，功能完成后应删除。具体实施时，本发明实施例提供的代码分支管理方法还可以包括：若用户验收测试不通过，则从发布分支获取代码，创建热修复分支；修复完成后，将热修复分支的代码合并到开发分支，重新对开发分支进行系统集成测试，若重新测试通过，重新创建发布分支。热修复(hotfix)分支，也可称作补丁分支或bug(漏洞)修复分支，基于release分支创建，主要用于对线上的版本进行bug修复。修复完毕后合并到release分支和develop分支，重新发布新release版本，并打好新的tag(标签)。热修复(hotfix)分支属于临时分支，同一时间只有1个，生命周期较短，补丁修复上线后删除。对比现有技术中代码分支管理方法中的主干开发方法，主干开发方法在实际开发工作中，单一主干的代码管理在项目新建立期间问题不太大，但是如果项目进入到维护期时，容易引起在紧急修复的即时性和版本开发的周期性间造成矛盾。本申请实施例提供的代码分支管理方法可在出现代码错误需紧急修复时，及时地创建热修复(hotfix)分支，及时地对代码修复，不需要等待较长时间，且流程不复杂，不存在紧急修复的即时性和版本开发的周期性的矛盾。具体实施时，本发明实施例提供的代码分支管理方法还可以包括：在对主分支的代码进行投产使用后，若出现代码错误，则从合并到主分支的发布分支获取代码，创建热修复分支；修复完成后，将热修复分支的代码合并到开发分支，重新对开发分支进行系统集成测试，若重新测试通过，重新创建发布分支。在经过用户验收测试后，可以对该完成的项目打上版本号可以进行投产发布。生产环境中发现的bug不能在本分支直接进行修复，而需要在hotfix分支进行修复后再合并入release进行提测，然后发布新的release分支版本。具体实施时，本发明实施例提供的代码分支管理方法还可以包括：将个人开发分支的代码合并到开发分支时，更新开发分支的版本号；将发布分支的代码合并到主分支时，更新开发分支的版本号。举一例，提供一种对应版本号的标签的使用方式，标签是某一个关键的版本，规定个分支的命名规范为《v主版本号.次版本号.修订号-先行版本号》，版本号递增规则如下：1.主版本号：做了不兼容的api(applicationprogramminginterface，应用程序接口)修改；2.次版本号：做了向下兼容的功能性新增；3.修订号：做了向下兼容的问题修正；4.先行版本号：可以加到“主版本号.次版本号.修订号”的后面，作为延伸，如：v1.5.3-alpha1；v2.3.14-beta3。如v1.5.3-alpha1，v代表这是一个版本，1为主要版本号，代表了一个大的版本；5代表次要版本号，通常是增加了某些新功能；3为修订号，通常表示一些问题的修复；-为分隔符，alpha说明当前版本属于内测阶段，1为内测环境或小内测版本变动；如，v2.3.14-beta3，v代表这是一个版本，2为主要版本号，代表了一个大的版本；3代表次要版本号，通常是增加了某些新功能；14为修订号，通常表示一些问题的修复；-为分隔符，beta说明当前版本属于公测阶段，3为内测环境或公测小版本变动。具体实施时，本发明实施例提供的代码分支管理方法还可以包括：设置一种git提交代码规范。在git提交代码规范，针对基本语法，每次本地代码改动提交到远程，需要注明提交说明，否则不允许提交到远程。<type>(<scope>:<risk>):<story><subject><blankline><body><blankline><footer>代码含义如下：类型(影响范围：风险)：关联用户故事概述空行修改信息空行备注在git提交代码规范，还包括一套代码语法的说明，如表2所示，表2是本发明实施例提供的代码分支管理方法中的git提交代码规范。在每次提交版本到代码仓库时，根据本次提交的信息套用此提交模板，如本次开发人员修改了说明文件，即readme.md文件，且这个开发任务的编号是#106，那么开发人员在提交时需要编写：doc(loation:a):#106修改了说明文件末尾处增加了新增模块的说明信息本次修改成员b提供了意见表2：本发明实施例提供的一种代码分支管理方法中的git提交代码规范针对上述的git提交代码规范，本申请实施例还提供了一个实例，代码如下所示：上述代码含义如下：feat(location:a):#453:sangjingaddadatefile本次提交的是新功能，影响范围较小，风险较低，关联的用户故事编号是453，做的操作是增加了一个日期文件。这是一段详细描述本次的操作，上传了一个日期文件20190909.txt，这个文件非常重要，是用了管理员的账号。todayisfri.备注是今天是周五。本发明实施例还提供了一个代码分支管理方法的实例，如图2所示，图2是本发明实施例提供的一个代码分支管理方法的实例的流程示意图。有开发成员abc三人，需要各自修改一些代码，并且合作做两个功能，其中一个功能基于开发者a的模块，另一个功能是个全新的特性，部署三套环境，当前项目版本v0.1.0。开发人员a和开发人员c各自创建了各自的个人开发分支，并分别从最新的测试通过的开发分支的节点中获取代码，也是就对应线上的v0.1.0版本，随即进行日常的项目开发。当涉及多人共同开发一个功能时，开发人员a基于自己当前的个人开发分支创建了临时的特性分支，并且邀请开发人员bc一起开发此分支，此特性开发完成后，将特性分支合并到了开发者a的个人开发分支并，将个人开发分支标记v0.1.1版本，此时开发人员a删除了临时特性分支。在对个人开发分支进行本地集成测试后，将个人开发分支合并到开发分支进行系统集成测试，但是测试失败了，于是开发人员a在自己的个人开发分支上修改了一个版本，并标记了v0.1.2版本，后又将修改后的个人开发分支合并到开发分支，并对开发分支进行系统集成测试，这次测试通过。开发人员c一直在本地进行日常开发，此时他想将自己的个人开发分支的代码merge(合并)到开发分支进行测试，所以他先执行了pull(拉取)操作，来将远程开发分支最新的代码合并到本地，随即再进行合并，此处合并的步骤是先从开发分支获取代码，对个人开发分支合并，然后再将个人开发分支合并到开发分支，因代码合并是有可能产生代码冲突，所以开发人员先从开发分支获取最新的代码到本地，如果有冲突就在本地解决了，然后再往仓库里面合并即可避免冲突。在通过系统集成测试后，此时认为可以发布版本了，于是对最新的通过测试的开发分支节点打了标签v0.2.0，并创建了发布分支release-v0.2.0，发布后进入用户验收测试环境，但是发现这个版本有重大bug，于是在此版本的开发分支上创建了临时hotfix分支进行bug修复，修复完成后合并到了develop主开发分支上并通过了测试，此时对最新的通过测试的节点打了标签v0.2.2，并创建了发布分支release-v0.2.2，发布后进入用户验收测试环境，测试通过。此时应删除废弃的原发布分支release-v0.2.0和临时的hotfix分支。这时基于release-v0.2.2版本进行投产上线，发布到生产测试没有问题后代码合并到了主分支，但是运行了几天后出现生产事故，由代码bug引起。此时进行紧急修复，基于最新的release分支创建hotfix分支，修复完成后将hotfix分支代码直接合并到release分支和develop分支。release测试没有问题后打上新标签v0.2.7，发布生产环境，并将代码合并到master。开发人员a继续新的开发工作，将个人开发分支的代码合并到develop分支，系统集成测试通过后基于develop分支创建了新的发布分支release-v0.3.0，并标记为版本v0.3.0，且成功通过了用户验收测试，此时最终将发布分支release-v0.3.0合并到master分支。由上述实施例可知，本发明实施例通过允许创建个人开发分支，可同时支持众多开发人员同时进行项目开发；通过将个人开发分支的代码合并到开发分支，可将开发人员的代码及时地合并到开发分支，提高了代码合并的时效性；通过本地集成测试和系统集成测试，可对代码分支及时地进行检测，与现有技术对比，在系统集成测试之前，可先进行本地集成测试，提高了代码检测的效率。实施例中，可以通过对大规模团队的使用习惯和实施规范来确定常驻分支和临时分支。其中常驻分支为主分支和开发分支；临时分支为性能分支，热修复分支，个人开发分支和合并分支。由于开发人员数量较多，有测试流水线需求，所以有各自的个人开发分支；由于有多人协同开发的模块，所以有临时的特性分支；基于集成环境创建了用于集成部署的develop分支；基于验收环境的release分支，验收通过保留该分支，未通过删除该分支；以及始终和生产环境对应的master分支。本发明实施例允许存在用户个人分支，并以部署环境驱动分支管理，如个人分支对应本地集成测试、develop分支对应sit环境(系统集成测试)、release分支对应uat环境(用户验收测试)。本发明实施例中master分支始终与线上运行代码一致，始终由release分支合并而来，并且在发布完成后才进行合并。本发明实施例hotfix分支只修复release分支和develop分支。基于同一发明构思，本发明实施例中还提供了一种代码分支管理装置，如下面的实施例所述。由于代码分支管理装置解决问题的原理与代码分支管理方法相似，因此代码分支管理装置的实施可以参见代码分支管理方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图3是本发明实施例的代码分支管理装置的一种结构框图，如图3所示，包括：个人开发分支创建模块01，用于从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；本地集成测试模块02，用于对完成开发的个人开发分支进行本地集成测试；系统集成测试模块03，用于若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；用户验收测试模块04，用于若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；主分支合并模块05，用于若用户验收测试通过，将发布分支的代码合并到主分支，对主分支的代码进行投产使用。在一实施例中，还包括：特性分支创建模块，用于：从个人开发分支获取代码，创建特性分支；将特性分支的代码合并到个人开发分支。在一实施例中，还包括：热修复分支创建模块，用于：在用户验收测试不通过时，从发布分支获取代码，创建热修复分支；所述系统集成测试模块还用于：在修复完成后，将热修复分支的代码合并到开发分支，重新对开发分支进行系统集成测试；所述用户验收测试模块还用于：在重新系统集成测试通过后，重新创建发布分支。在一实施例中，还包括投产后修改模块06，如图4所示，图4是本发明实施例提供的一种代码分支管理装置的结构示意图。投产后修改模块用于：在对主分支的代码进行投产使用后，若出现代码错误，则从合并到主分支的发布分支获取代码，创建热修复分支；所述系统集成测试模块还用于：在修复完成后，将热修复分支的代码合并到开发分支，重新对开发分支进行系统集成测试；所述用户验收测试模块还用于：在重新系统集成测试通过后，重新创建发布分支。在一实施例中，还包括：版本号更新模块06，如图5所示，图5是本发明实施例提供的一种代码分支管理装置的结构示意图。版本号更新模块用于：将个人开发分支的代码合并到开发分支时，更新开发分支的版本号；将发布分支的代码合并到主分支时，更新开发分支的版本号。本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述所述方法。本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述所述方法的计算机程序。综上所述，本发明实施例中，从开发分支获取代码，创建个人开发分支；所述个人开发分支用于开发人员在本地进行项目开发；对完成开发的个人开发分支进行本地集成测试；若本地集成测试通过，将个人开发分支的代码合并到开发分支，对开发分支进行系统集成测试；若系统集成测试通过，从开发分支获取代码，创建发布分支，对发布分支进行用户验收测试；若用户验收测试通过，将发布分支的代码合并到主分支，对主分支的代码进行投产使用，从而通过允许创建个人开发分支，可同时支持众多开发人员同时进行项目开发；通过将个人开发分支的代码合并到开发分支，可将开发人员的代码及时地合并到开发分支，提高了代码合并的时效性；通过本地集成测试和系统集成测试，可对代码分支及时地进行检测，与现有技术对比，在系统集成测试之前，可先进行本地集成测试，提高了代码检测的效率。本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。当前第1页12