基于分布式的工程管理方法、装置、设备以及存储介质

技术领域

本申请涉及软件开发技术领域，特别是涉及一种基于分布式的工程管理方法、装置、设备以及存储介质。

背景技术

随着计算机技术持续发展，软件开发成为热门工作之一。为了提升开发效率，在软件开发的工程项目中几乎离不开工程管理。

因此，用于工程管理的工具和方法则显得相当重要，例如Git是一个开源的分布式版本控制系统，可以有效、高速地进行各种规模的项目版本管理。

但在基于此类系统进行软件开发的过程中，当主团队需要向其它团队提供源代码信息时，难以通过权限设置对其它团队屏蔽项目中需要隐藏的涉密信息，容易产生一系列安全问题。

发明内容

本申请至少提供一种基于分布式的工程管理方法、装置、设备以及计算机可读存储介质。

本申请第一方面提供了一种基于分布式的工程管理方法，包括：响应于接收到的用户端针对初始工程的分支工程申请，对应创建所述初始工程的分支工程仓库；基于所述分支工程申请获取所述初始工程中的分支工程文件；将所述分支工程文件迁移至所述分支工程仓库中，得到目标分支工程；将所述目标分支工程的工程权限赋予至发起所述分支工程申请的用户端，所述工程权限用于所述用户端进行工程开发。

在一实施例中，所述将所述分支工程文件迁移至所述分支工程仓库中，得到目标分支工程的步骤，包括：获取所述初始工程的初始仓库链接，所述初始仓库链接用于访问所述初始工程；基于所述初始仓库链接将所述分支工程文件克隆至本地仓库中；将所述本地仓库的初始仓库链接修改为分支仓库链接，所述分支仓库链接用于访问所述分支工程仓库；基于所述分支仓库链接将所述本地仓库中的分支工程文件提交至所述分支工程仓库中，得到所述目标分支工程。

在一实施例中，在所述基于所述初始仓库链接将所述分支工程文件克隆至本地仓库中的步骤之后，所述方法还包括：判断所述分支工程仓库中是否包含所述分支工程文件；若是，则暂停或停止本次分支工程申请；若否，则将所述本地仓库的初始仓库链接修改为所述分支仓库链接。

在一实施例中，所述响应于接收到的用户端针对初始工程的分支工程申请，对应创建所述初始工程的分支工程仓库的步骤，包括：判断所述分支工程申请是否为通过审核端进行审核的分支工程申请；若是，则创建所述分支工程仓库；若否，则暂停或停止创建所述分支工程仓库。

在一实施例中，在所述将所述目标分支工程的工程权限赋予至发起所述分支工程申请的用户端的步骤之后，所述方法还包括：响应于接收到的所述用户端针对所述目标分支工程的工程合并申请，确定所述工程合并申请对应的待合并分支工程；判断所述目标分支工程和所述待合并分支工程是否为同源分支；若是，则将所述目标分支工程与所述待合并分支工程进行合并处理；若否，则暂停或停止本次工程合并申请。

在一实施例中，所述判断所述目标分支工程和所述待合并分支工程是否为同源分支的步骤，包括：验证所述目标分支工程和所述待合并分支工程是否存在相同的验证信息；若是，则判定所述目标分支工程和所述待合并分支工程为所述同源分支；若否，则判定所述目标分支工程和所述待合并分支工程不为所述同源分支。

在一实施例中，所述将所述目标分支工程与所述待合并分支工程进行合并处理的步骤，包括：获取所述目标分支工程和本地仓库之间的目标仓库链接；基于所述目标仓库链接将所述目标分支工程中的目标工程文件克隆至所述本地仓库中；将所述本地仓库的目标仓库链接修改为和所述待合并分支工程之间的待合并链接；基于所述待合并链接将所述本地仓库中的目标工程文件提交至所述待合并分支工程中，使所述目标工程文件和所述待合并分支工程中的待合并文件合并归档。

本申请第二方面提供了一种基于分布式的工程管理装置，包括：工程创建模块，用于响应于接收到的用户端针对初始工程的分支工程申请，对应创建所述初始工程的分支工程仓库；获取模块，用于基于所述分支工程申请获取所述初始工程中的分支工程文件；迁移模块，用于将所述分支工程文件迁移至所述分支工程仓库中，得到目标分支工程；权限赋予模块，用于将所述目标分支工程的工程权限赋予至发起所述分支工程申请的用户端，所述工程权限用于所述用户端进行工程开发。

本申请第三方面提供了一种电子设备，包括存储器和处理器，处理器用于执行存储器中存储的程序命令，以实现上述基于分布式的工程管理方法。

本申请第四方面提供了一种计算机可读存储介质，其上存储有程序命令，程序命令被处理器执行时实现上述基于分布式的工程管理方法。

上述方案，通过响应于接收到的用户端针对初始工程发起的分支工程申请，创建对应的分支工程仓库；基于分支工程申请获取初始工程中对应的分支工程文件；将分支工程文件迁移至分支工程仓库中，得到目标分支工程；将目标分支工程的工程权限赋予至发起分支工程申请的用户端，以使用户端能基于获取到的工程权限进行工程开发，由此能够有效地管理工程项目的开发过程，确保工程的安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

图1是本申请的基于分布式的工程管理方法的一示例性实施例的流程示意图；

图2是本申请的基于分布式的工程管理方法中一示例性地系统结构图；

图3是本申请的基于分布式的工程管理方法的一示例性的工程命名示意图；

图4是本申请的基于分布式的工程管理方法中一示例性地应用场景示意图；

图5是本申请的一示例性实施例示出的基于分布式的工程管理装置的框图；

图6是本申请电子设备一实施例的结构示意图；

图7是本申请计算机可读存储介质一实施例的结构示意图。

具体实施方式

下面结合说明书附图，对本申请实施例的方案进行详细说明。

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

为便于理解，现对本申请的技术方案能够应用的场景进行示例性地说明。本申请的工程管理方法可基于相应的工程管理系统实现，本申请提供的工程管理系统是基于Git并采用集成命令和API接口交互实现了能够定制工程项目的仓库管理系统，其中，Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

在传统的基于Git的项目定制开发过程中，当主团队需要向其它团队提供源代码信息时，难以通过权限设置对其它团队屏蔽项目中需要隐藏的涉密信息，容易产生一系列安全问题。虽然目前存在其它版本控制软件如SVN系统（Subversion）等，可以基于SVN权限特性根据分支分配权限；但Git系统相比SVN系统，能显著提高开发效率，在不放弃Git的实用性前提上，本申请基于Git系统提出新的开发规范和方案解决这样的问题。此外，在解决以上问题的同时还不能破坏Git的仓库管理能力，即不仅仅可以做到定制工程的权限控制，还应该在后续开发生产过程中，若出现合理的定制需求代码时，此部分代码还能归档到原本的基线工程中，实现工程合并。

请参阅图1，图1是本申请的基于分布式的工程管理方法的一示例性实施例的流程示意图。具体而言，本申请的工程管理方法应用于服务端，服务端中运行有基于Git的工程管理系统，具体方法可以包括如下步骤：

步骤S110，响应于接收到的用户端针对初始工程的分支工程申请，对应创建初始工程的分支工程仓库。

可参考图2，图2是本申请的基于分布式的工程管理方法中一示例性地系统结构图；其中，用户端可以是Web端或其它类型的终端，用户端和服务端之间存在交互，以实现通过用户端访问服务端上运行的工程管理系统。

示例性地，开发人员可通过其用户端针对需要开发的初始工程，向服务端发起分支工程申请，其中，分支工程申请可包括申请原因、需要申请的工程信息等（例如工程名称、工程路径等一系列可以确定需要开发的工程的相关信息）；初始工程可以是经过开发的工程也可以是未经过开发的工程，此处不做限定。

进一步地，服务端响应于接收到的用户端针对初始工程发起的分支工程申请，利用Gitlab接口对应地创建初始工程的分支工程仓库，此外还会形成新的工程分组、新的工程以及新的分支等；其中，新分组与原分组（初始工程的分组）存在能对应的关系，新工程与原工程（初始工程）存在能对应的关系，新分支名称与原分支名称（初始工程中的分支名称）存在能对应的关系。

需要说明的是，为了便于工程管理和项目开发，本申请还提供一种工程定制过程中的命名规范以使初始工程和新创建的分支工程之间的对应关系能够直接体现，例如，可参考图3所示，图3是本申请的基于分布式的工程管理方法的一示例性的工程命名示意图：新的工程的分组应当是与原工程的分组在同一层级的不同分组，例如原工程的路径为/Group1/Group2/……，则新的工程的路径可为/Group1/Project/，两者都属于Group1分组的下一层级且两者是不同分组；新工程在新的分组下与原工程同名，例如新工程基于原工程的名称相应地命名为Test；此外，新分支名称中可由原分支名称加项目名称XM加团队名称TD构成，用于表示不同的版本，例如原工程的分支名称为V1.0.0.2310，则新工程的分支名称可为V1.0.0.2310.XM.TD；由此，得到新工程的路径和名称等，完成对分支工程仓库的创建。

具体地，此步骤涉及的接口创建可如下：创建工程接口:/api/v4/projects；创建分组接口：/api/v4/groups；创建分支接口：/api/v4/projects/PROJECT_ID/repository/branches?ref=REF_BRANCH。

步骤S120，基于分支工程申请获取初始工程中的分支工程文件。

结合前述步骤，工程管理系统在接收到分支工程申请后，根据分支工程申请中填写的工程信息确定该开发人员在初始工程中需要负责开发的全部或部分工程项目，得到初始工程中的分支工程文件。

步骤S130，将分支工程文件迁移至分支工程仓库中，得到目标分支工程。

具体地，根据分支工程申请将获取到的分支工程文件迁移至分支工程申请对应的分支工程仓库中，则得到开发人员需要开发的目标分支工程，实现将目标分支工程和初始工程进行剥离，保证了初始工程的安全性。

示例性地，结合前述步骤以及图2中所示的工程项目为例进行说明，服务端利用JGIT开发插件创建初始工程P到服务端运行的服务器文件夹之间的初始仓库链接，使用clone命令根通过初始仓库链接将工程P的V1.0数据（分支工程文件）克隆到服务器文件夹下（即服务端的本地仓库）；服务端利用JGIT的集成命令修改本地仓库到初始工程P的链接为本地仓库到分支工程P1的链接，使用commit和push命令将本地仓库中的V1.0数据进行提交推送，此时本地仓库中从P工程clone而来的数据就完全push到了P1工程中，在push完成后的工程P1里存在一个和工程P相同的分支V1.0，其分支信息例如文件内容、分支提交记录等与原工程P下的V1.0分支都相同；在push成功后还可删除本地仓库；再调用Gitlab接口修改工程P1下的分支名称V1.0为目标分支名称V1.0.XM.TD，得到目标分支工程。

步骤S140，将目标分支工程的工程权限赋予至发起分支工程申请的用户端，工程权限用于用户端进行工程开发。

结合前述步骤，示例性地，在目标分支工程建立完成之后，则服务端可调用Gitlab的API接口（/api/v4/projects/PROJECT_ID/members）将目标分支工程的工程权限赋予给发起前述分支工程申请的用户端，以使开发人员可以通过拥有工程权限的用户端对目标分支工程进行工程开发；同时，也避免了传统方案中负责分支工程的开发人员能够对原工程进行访问和修改，确保了信息安全问题。

进一步地，若是开发人员对目标分支工程完成开发工作之后，还可提交工程合并申请，将自身用户端的分支工程合并至原工程中；对于多方参与的协同开发工作场景而言，本申请提供的方法实现了有效地工程管理。

可以看出，本申请通过响应于接收到的用户端针对初始工程发起的分支工程申请，创建对应的分支工程仓库；基于分支工程申请获取初始工程中对应的分支工程文件；将分支工程文件迁移至分支工程仓库中，得到目标分支工程；将目标分支工程的工程权限赋予至发起分支工程申请的用户端，以使用户端能基于获取到的工程权限进行工程开发，由此能够有效地管理工程项目的开发过程，确保工程的安全性。

在上述实施例的基础上，本申请实施例对将分支工程文件迁移至分支工程仓库中，得到目标分支工程的步骤进行说明。具体而言，本实施例方法包括以下步骤：

获取初始工程的初始仓库链接，初始仓库链接用于访问初始工程；基于初始仓库链接将分支工程文件克隆至本地仓库中；将本地仓库的初始仓库链接修改为分支仓库链接，分支仓库链接用于访问分支工程仓库；基于分支仓库链接将本地仓库中的分支工程文件提交至分支工程仓库中，得到目标分支工程。

结合前述实施例进行说明，在做好前序工作之后，服务端开始将用户端申请的分支工程文件迁移至分支工程仓库中。其中，主要可通过利用JGIT的Java开发插件，采用集成命令语句的方式拉取原工程到目标工程。

示例性地，例如根据分支工程申请确定需要将原工程P中分支为V1.0的分支工程文件迁移到分支工程仓库中，得到迁移完成后的分支工程P1中的V1.0.XM.TD。其中，具体过程可为：服务端通过如数据库等途径获取开发人员发起的分支工程申请，其可以是开发人员在Web端页面填写的迁移信息等，例如：原工程P路径，原分支名称V1.0，原分支提交的SHA（Secure Hash Algorithm）记录信息，以及目标工程P1路径等；服务端利用JGIT开发插件创建原工程P到服务端运行的服务器文件夹之间的初始仓库链接，使用clone命令根通过初始仓库链接将工程P的V1.0数据克隆到本地仓库；服务端利用JGIT的集成命令修改本地仓库到初始工程P的链接为本地仓库到分支工程P1的分支仓库链接，使用commit和push命令将本地仓库中的V1.0数据进行提交推送，此时本地仓库中从P工程clone而来的数据就完全push到了P1工程中，push完成后工程P1里存在一个和工程P相同的分支V1.0，其分支信息例如文件内容、分支提交记录等与原工程P下的V1.0分支都相同；在push成功后还可删除本地仓库；再调用Gitlab接口修改工程P1下的分支名称V1.0为目标分支名称V1.0.XM.TD，得到目标分支工程。后续可以再将目标分支工程的权限赋给对应的用户端，由此，开发人员可通过授权的用户端对目标分支工程进行查看和修改，而不会影响到初始工程的其它分支。需要说明的是，初始工程仓库和分支工程仓库都运行在Git上。

在上述实施例的基础上，本申请实施例对在基于初始仓库链接将分支工程文件克隆至本地仓库中之后的步骤进行说明。具体而言，本实施例方法包括以下步骤：

判断分支工程仓库中是否包含分支工程文件；若是，则暂停或停止本次分支工程申请；若否，则将本地仓库的初始仓库链接修改为分支仓库链接。

结合前述实施例进行说明，本申请的工程管理方法除了可应用于初次创建目标分支工程外，还可以是对已有的目标分支工程做进一步的修改更新等，即开发人员可通过用户端基于已有的分支工程发起分支工程申请，以获得额外的分支工程文件加入到已有的分支工程中，其过程可同理参考前述实施例，此处不再赘述。

其中，为了防止工程文件冗余，在基于初始仓库链接将分支工程文件克隆至本地仓库中之后，需要判断分支工程仓库中是否包含同样的分支工程文件，以避免对重复的分支工程文件进行获取；因此，基于初始仓库链接clone工程P的V1.0的数据到本地仓库后，服务端可利用Gitlab的API接口（/projects/PROJECT_ID/repository/branches?search=keyword）判断P1工程的分支工程仓库中是否存在V1.0.XM.TD（即是否存在相同的分支工程文件），若已经存在，则本次迁移不满足迁移条件，暂停或停止本次对分支工程的申请流程；若不存在，则本次迁移满足迁移条件，将本地仓库的初始仓库链接修改为分支仓库链接（本地仓库和P1工程之间的链接），继续进行本次对分支工程的申请流程。

在上述实施例的基础上，本申请实施例对响应于接收到的用户端针对初始工程的分支工程申请，对应创建初始工程的分支工程仓库的步骤进行说明。具体而言，本实施例方法包括以下步骤：

判断分支工程申请是否为通过审核端进行审核的分支工程申请；若是，则创建分支工程仓库；若否，则暂停或停止创建分支工程仓库。

需要说明的是，在本申请的工程管理方法所能应用的场景中，除了涉及到用户端和服务端的交互，还可以设置审核端对分支工程的申请流程进行审核；其中，审核端可以是Web端或者其它类型的终端，审核端和用户端的作用不同，审核端和用户端可以是通过不同电子设备予以区分或者是通过不同类型（不同权限）的账户予以区分（即审核端和用户端可以是在同一电子设备上运行的不同账户），此处不做限定。为便于说明，本实施例中以用户端和审核端为不同电子设备为例进行说明，具体可参考图4所示，图4是本申请的基于分布式的工程管理方法中一示例性地应用场景示意图，本申请的用户端主要指开发人员所使用的终端设备，开发人员可通过用户端进行工程项目开发等流程（包括发起工程申请）；本申请的审核端主要指审核人员所使用的终端设备，审核人员可通过审核端对开发人员发起的工程申请进行审核，若审核通过，则将该工程申请流转至服务端中并执行前述实施例中记载的方法，其中，工程管理系统可至少包括权限管理模块和仓库管理模块，权限管理模块可用于管理工程申请过程中的权限，仓库管理模块可用于管理工程申请过程中的仓库。

因此，服务端在响应接收到的分支工程申请时，还需要判断分支工程申请是否通过审核端的审核；若通过审核服务端才会继续进行后续步骤；若未通过审核则服务端会暂停或停止本次工程申请，防止违规的工程申请操作，也避免外界设备对本服务端和/或本工程发起网络攻击、窃取研发机密等。

可选地，在结合用户端、审核端和服务端的整体应用环境中，可在审核端设置判断流程，即若是审核人员未将开发人员的工程申请通过审核，则直接在审核过程中暂停或停止本次工程申请流程，无需再将本次工程申请交由服务端进行判断，减少服务端的交互压力。

示例性地，审核过程可以是工程管理系统将开发人员通过客户端提交的工程申请转达到负责对应工程的审核人员，以使审核人员能在审核端查看来自开发人员申请的数据库数据；在审核人员确认该工程申请无误后，即可将该工程申请的状态设置为审核通过，还可以在该工程申请中附上审核端对应的密钥或其它验证信息，以向服务端表示该工程申请已通过验证。

在上述实施例的基础上，本申请实施例对在将目标分支工程的工程权限赋予至发起分支工程申请的用户端之后的步骤进行说明。具体而言，本实施例方法包括以下步骤：

响应于接收到的用户端针对目标分支工程的工程合并申请，确定工程合并申请对应的待合并分支工程；判断目标分支工程和待合并分支工程是否为同源分支；若是，则将目标分支工程与待合并分支工程进行合并处理；若否，则暂停或停止本次工程合并申请。

结合前述实施例进行说明，前述实施例中已说明开发人员如何通过工程申请获取对应的工程项目及权限，并对工程项目进行开发；但在实际项目开发中，开发人员将自己负责的分支工程项目开发完成之后，需要将完成后的分支工程项目与其它分支工程项目进行合并，以得到完整的工程项目文件；因此，本实施例对开发人员获取到目标分支工程的工程权限之后的步骤进行说明。

需要说明的是，本实施例中所记载的目标分支工程可以是前述实施例中获取到的目标分支工程，也可以是在前述实施例中获取到的目标分支工程的基础上进行修改后的分支工程，具体情况视开发人员是否对本目标分支工程进行修改而定，但不论何种情况其本质上仍是同一工程，因此为便于说明，本实施例中仍以“目标分支工程”为名进行说明，并未对目标分支工程中的数据是否变化作出限定。

示例性地，本实施例以将新工程P1合并至原工程P中的过程为例进行说明；首先需要拥有目标分支工程的工程权限的开发人员发起工程合并申请，其中，工程合并申请可包括需要合并的目标分支工程P1信息（如工程名称P1和工程分支branch1），以及想要合并的待合并分支工程P信息（如工程名称P和工程分支branch）；服务端在接收到工程合并申请后，确定对应的待合并分支工程，并判断目标分支工程和待合并分支工程是否为同源分支（用于表示目标分支工程和待合并分支工程是否属于同一工程项目）；若是，则将目标分支工程与待合并分支工程进行合并处理；若否，则暂停或停止本次工程合并申请。

可选地，服务端在接收到工程合并申请后，还可以判断该工程合并申请是否通过审核；若通过审核服务端才会继续进行后续步骤；若未通过审核则服务端会暂停或停止本次工程合并申请，防止违规的工程合并申请操作，也避免外界设备对本服务端和/或本工程发起网络攻击、窃取研发机密等。具体审核过程可同理参考前述实施例对分支工程申请的审核过程，此处不再赘述。

在上述实施例的基础上，本申请实施例对判断目标分支工程和待合并分支工程是否为同源分支的步骤进行说明。具体而言，本实施例方法包括以下步骤：

验证目标分支工程和待合并分支工程是否存在相同的验证信息；若是，则判定目标分支工程和待合并分支工程为同源分支；若否，则判定目标分支工程和待合并分支工程不为同源分支。

验证信息指的是SHA信息，是一种密码学哈希函数，可作为分支每次commit提交数据时的唯一标识。

示例性地，服务端调用Gitlab的API接口校验工程P1以及分支branch1，工程P以及分支branch是否存在；若存在，则再调用Gitlab的API接口（如commit相关的接口）校验工程P1的分支和工程P的分支是否存在相同的commit记录（即判断两者是否存在相同的SHA值）；若是，则判定目标分支工程和待合并分支工程属于同源分支；若否，则判定目标分支工程和待合并分支工程不为同源分支。

需要说明的是，若是根据前述实施例方法中所记载的迁移流程所产生的分支工程则必然是同源分支的工程；因此，对于此类分支工程的判断，可通过查询数据库判断两者分支工程之间是否存在对应的迁移信息，以此来判断是否满足合并；进而可以省去同源分支的判断过程，提升工程合并的效率。

在上述实施例的基础上，本申请实施例对将目标分支工程与待合并分支工程进行合并处理的步骤进行说明。具体而言，本实施例方法包括以下步骤：

获取目标分支工程和本地仓库之间的目标仓库链接；基于目标仓库链接将目标分支工程中的目标工程文件克隆至本地仓库中；将本地仓库的目标仓库链接修改为和待合并分支工程之间的待合并链接；基于待合并链接将本地仓库中的目标工程文件提交至待合并分支工程中，使目标工程文件和待合并分支工程中的待合并文件合并归档。

结合前述实施例进行说明，服务端创建工程P1到本地仓库的链接，clone分支branch1的目标工程文件到本地仓库；利用JGIT修改工程P1和本地仓库之间的目标仓库链接为工程P和本地仓库之间的待合并链接，基于待合并链接commit并且push本地仓库中的目标工程文件到工程P，并在push成功后删除本地仓库；此时工程P中含有新的分支branch1和原分支branch，由于branch1和branch存在相同的SHA，服务端利用JGIT的merge命令操作，将工程P下分支branch1合并（merge）到分支branch，完成对本工程项目的合并归档。

进一步需要说明的是，基于分布式的工程管理方法的执行主体可以是基于分布式的工程管理装置，例如，基于分布式的工程管理方法可以由终端设备或服务器或其它处理设备执行，其中，终端设备可以为用户设备（User Equipment，UE）、电脑、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理（Personal Digital Assistant，PDA）、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该基于分布式的工程管理方法可以通过处理器调用存储器中存储的计算机可读命令的方式来实现。

图5是本申请的一示例性实施例示出的基于分布式的工程管理装置的框图。如图5所示，该示例性的基于分布式的工程管理装置500包括：工程创建模块510、获取模块520、迁移模块530和权限赋予模块540。具体地：

工程创建模块510，用于响应于接收到的用户端针对初始工程的分支工程申请，对应创建初始工程的分支工程仓库。

获取模块520，用于基于分支工程申请获取初始工程中的分支工程文件。

迁移模块530，用于将分支工程文件迁移至分支工程仓库中，得到目标分支工程。

权限赋予模块540，用于将目标分支工程的工程权限赋予至发起分支工程申请的用户端，工程权限用于用户端进行工程开发。

在该示例性的基于分布式的工程管理装置中，通过响应于接收到的用户端针对初始工程发起的分支工程申请，创建对应的分支工程仓库；基于分支工程申请获取初始工程中对应的分支工程文件；将分支工程文件迁移至分支工程仓库中，得到目标分支工程；将目标分支工程的工程权限赋予至发起分支工程申请的用户端，以使用户端能基于获取到的工程权限进行工程开发，由此能够有效地管理工程项目的开发过程，确保工程的安全性。

其中，各个模块的功能可参见基于分布式的工程管理方法实施例，此处不再赘述。

请参阅图6，图6是本申请电子设备一实施例的结构示意图。电子设备600包括存储器601和处理器602，处理器602用于执行存储器601中存储的程序命令，以实现上述任一基于分布式的工程管理方法实施例中的步骤。在一个具体的实施场景中，电子设备600可以包括但不限于：微型计算机、服务器，此外，电子设备600还可以包括笔记本电脑、平板电脑等移动设备，在此不做限定。

具体而言，处理器602用于控制其自身以及存储器601以实现上述任一基于分布式的工程管理方法实施例中的步骤。处理器602还可以称为CPU（Central Processing Unit，中央处理单元）。处理器602可能是一种集成电路芯片，具有信号的处理能力。处理器602还可以是通用处理器、数字信号处理器（Digital Signal Processor, DSP）、专用集成电路（Application Specific Integrated Circuit, ASIC）、现场可编程门阵列（Field-Programmable Gate Array, FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器602可以由集成电路芯片共同实现。

在上述方案提供的电子设备中，通过响应于接收到的用户端针对初始工程发起的分支工程申请，创建对应的分支工程仓库；基于分支工程申请获取初始工程中对应的分支工程文件；将分支工程文件迁移至分支工程仓库中，得到目标分支工程；将目标分支工程的工程权限赋予至发起分支工程申请的用户端，以使用户端能基于获取到的工程权限进行工程开发，由此能够有效地管理工程项目的开发过程，确保工程的安全性。

请参阅图7，图7是本申请计算机可读存储介质一实施例的结构示意图。计算机可读存储介质710存储有能够被处理器运行的程序命令711，程序命令711用于实现上述任一基于分布式的工程管理方法实施例中的步骤。

在上述方案提供的计算机可读存储介质中，运行其中的程序命令时会通过响应于接收到的用户端针对初始工程发起的分支工程申请，创建对应的分支工程仓库；基于分支工程申请获取初始工程中对应的分支工程文件；将分支工程文件迁移至分支工程仓库中，得到目标分支工程；再将目标分支工程的工程权限赋予至发起分支工程申请的用户端，以使用户端能基于获取到的工程权限进行工程开发，由此能够有效地管理工程项目的开发过程，确保工程的安全性。

在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干命令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。