CN111125743B - 权限管理方法、系统、计算机设备及计算机可读存储介质 - Google Patents

Abstract

本公开提供了一种权限管理方法，其特征在于，方法包括：响应于权限文件的提取信号，提取代码分支的权限文件，其中，权限文件中包括用于管理代码分支的权限角色；确定权限文件对应的权限存储路径；解析权限文件，得到权限解析结果，其中，权限解析结果包括权限角色；以及将权限存储路径和权限解析结果进行关联。本公开还提供了一种权限管理系统、一种计算机设备及一种计算机可读存储介质。

Description

权限管理方法、系统、计算机设备及计算机可读存储介质

技术领域

本发明涉及计算机技术领域，具体涉及权限管理方法、系统、计算机设备及计算机可读存储介质。

背景技术

目前，对于一个大仓库而言，只存在一个权限文件，这个权限文件中包括所有的权限角色和每个权限角色的权限。基于这种情况，现有技术在合并代码分支时，需要从这个仅有的权限文件中找到待合并的代码分支对应的权限角色，以判别本次合并是否是有效。

然而，在实现本发明构思的过程中，发明人发现相关技术中至少存在如下缺陷：现有技术中在合并代码分支时需要从唯一的权限文件中遍历出能够合并代码分支的权限角色，操作繁琐，工程量较大。

发明内容

本公开目的是提供一种权限管理方法、系统、计算机设备及计算机可读存储介质，以至少解决现有技术在合并代码分支时需要从唯一的权限文件中遍历出能够合并代码分支的权限角色，导致操作繁琐且工程量较大的缺陷。

本公开的一个方面提供了一种权限管理方法，其特征在于，上述方法包括：响应于权限文件的提取信号，提取代码分支的权限文件，其中，上述权限文件中包括用于管理上述代码分支的权限角色；确定上述权限文件对应的权限存储路径；解析上述权限文件，得到权限解析结果，其中，上述权限解析结果包括上述权限角色；以及将上述权限存储路径和上述权限解析结果进行关联。

根据本公开的实施例，上述代码分支源于代码仓库，上述确定上述权限文件对应的权限存储路径，包括：确定上述代码仓库的名称；确定上述代码分支的名称；确定上述权限文件源于的上述代码分支的目录层；以及将上述代码仓库的名称、上述代码分支的名称和上述目录层作为上述权限存储路径。

根据本公开的实施例，上述解析上述权限文件，得到权限解析结果，包括：从上述权限文件中确定出角色类型；从上述权限文件中获取与上述角色类型对应的权限角色；以及将上述角色类型和上述权限角色作为上述权限解析结果。

根据本公开的实施例，上述提取代码分支的上述权限文件，包括：确定上述代码分支的根目录，其中，上述根目录中包括至少一个对象，上述对象包括文件或者文件夹；以及若上述至少一个对象中存在上述权限文件，则从上述根目录中提取上述权限文件。

根据本公开的实施例，上述方法还包括：若上述至少一个对象中不存在上述权限文件，则判断上述至少一个对象中是否存在上述文件夹；若上述至少一个对象中存在至少一个上述文件夹，则判断上述至少一个上述文件夹中是否包括上述权限文件；以及若上述至少一个上述文件夹中存在上述权限文件，则提取上述权限文件。

根据本公开的实施例，上述代码分支包括一个或多个代码分支，各个上述代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层。

本公开的另一个方面提供了一种权限管理系统，其特征在于，上述系统包括：第一提取模块，用于响应于权限文件的提取信号，提取代码分支的权限文件，其中，上述权限文件中包括用于管理上述代码分支的权限角色；确定模块，用于确定上述权限文件对应的权限存储路径；解析模块，用于解析上述权限文件，得到权限解析结果，其中，上述权限解析结果包括上述权限角色；以及关联模块，用于将上述权限存储路径和上述权限解析结果进行关联。

根据本公开的实施例，上述代码分支源于代码仓库，上述确定模块包括：第一确定单元，用于确定上述代码仓库的名称；第二确定单元，用于确定上述代码分支的名称；第三确定单元，用于确定上述权限文件源于的上述代码分支的目录层；以及第四确定单元，用于将上述代码仓库的名称、上述代码分支的名称和上述目录层作为上述权限存储路径。

根据本公开的实施例，上述解析模块包括：第五确定单元，用于从上述权限文件中确定出角色类型；获取单元，用于从上述权限文件中获取与上述角色类型对应的权限角色；以及第六确定单元，用于将上述角色类型和上述权限角色作为上述权限解析结果。

根据本公开的实施例，上述提取模块包括：第七确定单元，用于确定上述代码分支的根目录，其中，上述根目录中包括至少一个对象，上述对象包括文件或者文件夹；以及提取单元，用于在上述至少一个对象中存在上述权限文件的情况下，从上述根目录中提取上述权限文件。

根据本公开的实施例，上述系统还包括：第一判断模块，用于在上述至少一个对象中不存在上述权限文件的情况下，判断上述至少一个对象中是否存在上述文件夹；第二判断模块，用于在上述至少一个对象中存在至少一个上述文件夹的情况下，判断上述至少一个上述文件夹中是否包括上述权限文件；以及第二提取模块，用于在上述至少一个上述文件夹中存在上述权限文件的情况下，提取上述权限文件。

根据本公开的实施例，上述代码分支包括一个或多个代码分支，各个上述代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层。

本公开的再一个方面提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，上述处理器执行上述计算机程序时用于实现如上任一项所述的权限管理方法的步骤。

本公开的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时用于实现如上任一项所述的权限管理方法的步骤。

本公开提供的权限管理方法，在合并代码分支之前，可以先将代码分支的权限文件提取出来，然后解析出权限文件中的权限角色，并且将解析出来的结果与权限文件的权限存储路径关联，这样，在合并代码分支时，通过查询权限存储路径就可以直接得到权限角色，而不必再去解析权限文件中，进而达到加速合并的技术效果，避免了现有技术在合并代码分支时需要从唯一的权限文件中遍历出能够合并代码分支的权限角色，导致操作繁琐且工程量较大的缺陷。

附图说明

图1示意性示出了根据本公开实施例的权限管理方案的系统架构图；

图2示意性示出了根据本公开实施例的权限管理方法的流程图；

图3示意性示出了根据本公开实施例的权限文件的作用域的示意图；

图4示意性示出了根据本公开实施例的权限文件的示意图；

图5示意性示出了根据本公开另一实施例的权限管理方法的流程图；

图6示意性示出了根据本公开实施例的权限管理系统的框图；以及

图7示意性示出了根据本公开实施例的适于实现权限管理方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本公开的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本公开进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本公开，并不用于限定本公开。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

考虑到现有技术在合并代码分支时需要从唯一的权限文件中遍历出能够合并代码分支的权限角色，导致操作繁琐且工程量较大的缺陷。本公开提供的权限管理方法，在合并代码分支之前，可以先将代码分支的权限文件提取出来，然后解析出权限文件中的权限角色，并且将解析出来的结果与权限文件的权限存储路径关联，这样，在合并代码分支时，通过查询权限存储路径就可以直接得到权限角色，而不必再去解析权限文件，进而达到加速合并的技术效果。

图1示意性示出了根据本公开实施例的权限管理方案的系统架构图。

在本公开的实施例中，一个分布式版本控制系统(又称为代码仓库，例如GIT、SVN)中可以包括多个代码分支，例如可以包括图1中所示的主干代码分支、修复代码分支、测试代码分支、开发代码分支、功能代码分支。其中，主干代码分支上可以包括用于发版的代码，如版本0.1、版本0.2、版本1.0等，且主干代码分支上的tag可以用于标识里程碑(即版本号)以及复制本次发版的代码。修复代码分支主要用于修复发版的分支，如版本0.1出现bug后，可以在tag0.1处创建修复分支，并基于tag0.1处复制的版本0.1修复bug，修复完成后，可以再次进行发版(如版本0.2)，并将修复后的代码合并到主干代码分支上，且在此处标记tag0.2。开发代码分支用于进行版本开发，例如基于主干代码分支上存储的版本0.1继续进行开发。功能代码分支可以是开发代码分支的临时分支，例如在本次开发中，可能涉及到两个功能，这时可以在开发代码分支的基础上拉取两个功能代码分支分别开发这两个功能，在功能开发完成后可以将功能代码分支合并到开发代码分支中。测试代码分支可以用于对开发代码分支上的代码进行测试，如在发版之前，开发代码分支将代码提交到测试代码分支中进行测试，若测试无问题则测试代码分支可以直接进行发版并将发版的代码合并到主干代码分支上；若测试有问题，则可以在该测试代码分支上直接修复bug，然后发版，并且可以将修复完bug的代码合并到开发代码分支上，同时测试代码分支还可以将本次发版的代码合并到主干代码分支上。

但是，在上述场景中，并不是所有人都有管理(例如合并、删除、修改)代码分支的权限。在现有技术中，通常是一个代码仓库中只有一个权限文件，这个权限文件中包括所有的权限角色和每个权限角色的权限。基于这种情况，现有技术在管理例如合并代码分支时，需要从这个仅有的权限文件中找到待合并的代码分支对应的权限角色，以判别本次合并是否是有效，导致操作十分繁琐，且工程量较大。

此时，便可以通过本公开的权限管理方案来克服上述缺陷，具体如下所述。

图2示意性示出了根据本公开实施例的权限管理方法的流程图。

如图2所示，该权限管理方法可以包括步骤S201～步骤S204，其中：

在步骤S201，响应于权限文件的管理信号，提取代码分支的权限文件，其中，所述权限文件中包括用于管理所述代码分支的权限角色。

需要说明的是，本公开的实施例并不是一个代码仓库中只有一个权限文件，而是代码仓库中的各个代码分支均有自己的权限文件，且各个代码分支可以有一个或多个权限文件。具体地，本公开实施例代码分支可以包括一个代码分支或者多个代码分支，且各个代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层，即该权限文件中的权限角色的作用域为该权限文件所在的目录层，其中，该目录层可以包括多个级别不同的目录(又称为文件夹)，例如，代码分支的根目录为root，根目录中包括目录a，目录a中包括目录b，目录b中包括权限文件e.md，则权限文件e.md的目录层为root/a/b，该权限文件e.md中的权限角色能够管理该目录层root/a/b。

应该理解，权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层也就是，权限文件中的权限角色能够管理该权限文件源于的目录本身以及该目录中包括的内容。

例如，将业务方以逻辑角度进行划分，得到例如评论、账号等业务方，并这些业务方通过物理划分成一个个独立的目录，权限文件可以在这些目录中标记作用域。如图3所示，图3示意性示出了根据本公开实施例的权限文件的作用域的示意图，在图3中，account(又称为账号业务方)目录下包括该account的权限文件CONTRIBUTORS.md，其中，该权限文件CONTRIBUTORS.md中的权限角色的能够管理该account目录本身以及该account目录中包括的code.go。reply(又称为评论业务方)目录下包括该reply的权限文件CONTRIBUTORS.md，其中，该权限文件CONTRIBUTORS.md能够管理该reply目录本身以及该reply目录中包括的code.go。

通过上述实施例中将权限文件下放到各个业务方目录中，可以实现分布式管理，且由于每个权限文件都有自己的作用域，因此还可以实现各个业务方自管理例如自配置自赋权等效果。另外，本公开的实施例通过代码分支对权限文件进行版本控制，可以使得分布式版本控制系统方便的回查、回滚。

进一步，为了克服现有技术在合并代码分支时需要从唯一的权限文件中遍历出代码分支对应的权限角色，导致操作繁琐且工程量较大的缺陷。本公开的实施例可以在合并代码分支之前，先将代码分支例如本次待合并的代码分支的权限文件解析出来，并将解析出的结果与权限文件源于的权限存路径进行关联，这样，在合并代码分支时，通过查询权限存储路径就可以直接得到权限角色，而不必再去权限文件中读取权限角色，进而达到加速合并的技术效果。具体地，可以通过执行步骤S201～步骤S204实现，首先可以通过步骤S201将代码分支的权限文件提取出来，例如将本次待合并的代码分支的权限文件提取出来，其中，本公开实施例中所述的代码分支可以包括一个或多个，每个代码分支可以包括至少一个权限文件。

根据本公开的实施例，提取代码分支的权限文件可以包括：确定代码分支的根目录，其中，根目录中包括至少一个对象，每个对象包括文件或者文件夹；以及若至少一个对象中存在权限文件，则从根目录中提取权限文件。若至少一个对象中不存在权限文件，则判断至少一个对象中是否存在文件夹；若至少一个对象中存在至少一个文件夹，则判断至少一个文件夹中是否包括权限文件；以及若该至少一个文件夹中存在权限文件，则提取该权限文件。

由于本公开的实施例需要将代码分支上的所有权限文件都提取出来，因此可以层级遍历该代码分支包括的目录，例如可以先遍历该代码分支根目录包括的第一个层级的文件或者文件夹中是存在权限文件，如果有，就将该权限文件提取出来。如果没有，则判断根目录中是否存在文件夹，如果存在至少一个文件夹，则依次判断文件夹中是否存在权限文件，若存在，则将权限文件从该文件夹中提取出来。

例如，对于代码分支master，其根目录root中存在一个文件a和两个文件夹分别是b、c。在提取master的权限文件时，可以先判断a、b、c中是否有一个是权限文件，假设a为权限文件，则将a提取出来；若a、b、c均不是权限文件，则可以先判断b中是否存在权限文件，假设b中不存在权限文件，则可以再判断c中是否存在权限文件，若c中存在权限文件，则可以从c中将权限文件提取出来。

在步骤S202，确定权限文件对应的权限存储路径。

在本公开的实施例中，每个权限文件可以对应一个三元组(仓库名，分支(即版本)名，仓库相对路径)，其中，该三元组可以用于表征该权限文件的权限存储路径(又称为权限域)。

根据本公开的实施例，代码分支源于代码仓库，确定权限文件对应的权限存储路径的具体步骤为：确定代码仓库的名称；确定代码分支的名称；确定权限文件源于的所述代码分支的目录层；以及将代码仓库的名称、代码分支的名称和目录层作为权限存储路径。其中，代码仓库的名称即为三元组中的仓库名，代码分支的名称即为三元组中的分支名，目录层即为三元组中的仓库相对路径。

例如，代码分支master源于的代码仓库为common，该代码分支的权限文件存放在biz/account中，则该权限存储路径可以为common_master_biz/account。

在步骤S203，解析权限文件，得到权限解析结果，其中，权限解析结果包括权限角色。

在本公开的实施例中，若权限文件中只包括权限角色，则解析结果也可以只包括权限角色；若权限文件中既包括权限角色又包括权限角色的角色类型，则该解析结果中可以包括权限角色和角色类型。其中，本公开实施例中的权限角色可以包括一个或多个。

若权限文件中既包括权限角色又包括角色类型，则解析权限文件得到权限解析结果的具体步骤为：从权限文件中确定出角色类型；从权限文件中获取与角色类型对应的权限角色；以及将角色类型和权限角色作为权限解析结果。具体地，角色类型可以包括Owner、Author、Reviewer，其中Owner表示主要负责人，Author表示贡献者、Reviewer表示检查者。在解析权限文件时，可以通过#<Owner|Author|Reviewer>代码，按照行排列从上到下的顺序，依次确定角色类型，然后再依次获取角色类型下的权限角色。

例如，权限文件中的内容如图4所示，在通过#<Owner|Author|Reviewer>代码解析权限文件时，可以先确定出角色类型Owner，再获取Owner下的权限角色Owner1；然后再确定出角色类型Author，获取Author下的权限角色Author1和Author2；进一步确定出角色类型Reviewer，获取Reviewer下的权限角色Reviewer1、Reviewer2和Reviewer3。

在步骤S204，将权限存储路径和权限解析结果进行关联。

在本公开的实施例中，可以将权限存储路径作为该权限文件的唯一标识key，将权限解析结果作为value，然后将权限存储路径和权限解析结果以key_value的形式进行关联，还可以将关联的key_value存储在hashmap中。

本公开提供的权限管理方法，在合并代码分支之前，可以先将代码分支的权限文件提取出来，然后解析出权限文件中的权限角色，并且将解析出来的结果与权限文件的权限存储路径关联，这样，在合并代码分支时，通过查询权限存储路径就可以直接得到权限角色，而不必再去权限文件中读取权限角色，进而达到加速合并的技术效果，尤其是随着代码仓库的增大，需要合并的代码分支数量越来越多时，本公开的实施例能更节省代码分支合并过程中所消耗的时间。通过本公开的实施例，可以避免现有技术在合并代码分支时需要从唯一的权限文件中遍历出代码分支对应的权限角色，导致操作繁琐且工程量较大的缺陷。

图5示意性示出了根据本公开另一实施例的权限管理方法的流程图。

如图5所示，该权限管理方法还可以包括步骤S501～步骤S509，其中：

在步骤S501，将代码仓库拉取到本地目录；

在步骤S502，将代码分支的根目录设置为当前目录；

在步骤S503，遍历当前目录下的文件；

在步骤S504，判断是否存在权限文件；

在步骤S505，若存在权限文件，则解析权限文件下的角色类型和权限角色；

在步骤S506，存储解析出的权限类型和权限角色；

在步骤S507，若不存在权限文件，则判断根目录下是否存在文夹；

在步骤S508，若存在文件夹，则依次将文件夹设置文件当前文件，并执行步骤S503；

在步骤S509，若不存在文件夹，则返回本次递归。

在本公开的实施例中，可以使用git提供的ssh鉴权方式，利用git clone shell命令将全量代码仓库拉取到本次文件系统中，然后将代码分支(可以是待合并的代码分支)的根目录设置为当前目录，遍历当前目录并判断当前目录包含的文件或者文件夹中是否存在CONTRIBUTORS.md，若存在CONTRIBUTORS.md，则可以按行从上到下匹配#<Owner|Author|Reviewer>，确定CONTRIBUTORS.md中的角色类型和权限角色，确定CONTRIBUTORS.md对应的权限存储路径，然后将权限存储路径作为CONTRIBUTORS.md的唯一标识key，将解析出的结果作为value值，并将key和value进行关联，以key_value的形式存到hashmap中。进一步，若不存在CONTRIBUTORS.md，则可以判断根目录中是否存在文件夹，若存在至少一个文件夹，则可以依次将这些文件夹作为当前目录，并继续判断当前目录中是否存在权限文件；若根目录中不存在文件夹，则本次递归结束。

图6示意性示出了根据本公开实施例的权限管理系统的框图。

如图6所示，该权限管理系统600可以包括第一提取模块610、确定模块620、解析模块630和关联模块640，其中：

第一提取模块610用于响应于权限文件的提取信号，提取代码分支的权限文件，其中，所述权限文件中包括用于管理所述代码分支的权限角色。

确定模块620用于确定所述权限文件对应的权限存储路径。

解析模块630用于解析所述权限文件，得到权限解析结果，其中，所述权限解析结果包括所述权限角色。

关联模块640用于将所述权限存储路径和所述权限解析结果进行关联。

本公开提供的权限管理方法，在合并代码分支之前，可以先将代码分支的权限文件提取出来，然后解析出权限文件中的权限角色，并且将解析出来的结果与权限文件的权限存储路径关联，这样，在合并代码分支时，通过查询权限存储路径就可以直接得到权限角色，而不必再去权限文件中读取权限角色，进而达到加速合并的技术效果，尤其是随着代码仓库的增大，需要合并的代码分支数量越来越多时，本公开的实施例能更节省代码分支合并过程中所消耗的时间。通过本公开的实施例，可以避免现有技术在合并代码分支时需要从唯一的权限文件中遍历出代码分支对应的权限角色，导致操作繁琐且工程量较大的缺陷。

作为一种可选的实施例，所述代码分支源于代码仓库，所述确定模块可以包括：第一确定单元，用于确定所述代码仓库的名称；第二确定单元，用于确定所述代码分支的名称；第三确定单元，用于确定所述权限文件源于的所述代码分支的目录层；以及第四确定单元，用于将所述代码仓库的名称、所述代码分支的名称和所述目录层作为所述权限存储路径。

作为一种可选的实施例，所述解析模块可以包括：第五确定单元，用于从所述权限文件中确定出角色类型；获取单元，用于从所述权限文件中获取与所述角色类型对应的权限角色；以及第六确定单元，用于将所述角色类型和所述权限角色作为所述权限解析结果。

作为一种可选的实施例，所述提取模块可以包括：第七确定单元，用于确定所述代码分支的根目录，其中，所述根目录中包括至少一个对象，所述对象包括文件或者文件夹；以及提取单元，用于在所述至少一个对象中存在所述权限文件的情况下，从所述根目录中提取所述权限文件。

作为一种可选的实施例，所述权限管理系统还可以包括：第一判断模块，用于在所述至少一个对象中不存在所述权限文件的情况下，判断所述至少一个对象中是否存在所述文件夹；第二判断模块，用于在所述至少一个对象中存在至少一个所述文件夹的情况下，判断所述至少一个所述文件夹中是否包括所述权限文件；以及第二提取模块，用于在所述至少一个所述文件夹中存在所述权限文件的情况下，提取所述权限文件。

作为一种可选的实施例，所述代码分支包括一个或多个代码分支，各个所述代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层。

图7示意性示出了根据本公开实施例的适于实现权限管理方法的计算机设备的硬件架构示意图。本实施例中，计算机设备700是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图所示，计算机设备700至少包括但不限于：可通过系统总线相互通信连接存储器710、处理器720、网络接口730。其中：

存储器710至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器710可以是计算机设备700的内部存储模块，例如该计算机设备700的硬盘或内存。在另一些实施例中，存储器710也可以是计算机设备700的外部存储设备，例如该计算机设备700上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器710还可以既包括计算机设备700的内部存储模块也包括其外部存储设备。本实施例中，存储器710通常用于存储安装于计算机设备700的操作系统和各类应用软件，例如权限管理方法的程序代码等。此外，存储器710还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器720在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器720通常用于控制计算机设备700的总体操作，例如执行与计算机设备700进行数据交互或者通信相关的控制和处理等。本实施例中，处理器720用于运行存储器710中存储的程序代码或者处理数据。

网络接口730可包括无线网络接口或有线网络接口，该网络接口730通常用于在计算机设备700与其他计算机设备之间建立通信连接。例如，网络接口730用于通过网络将计算机设备700与外部终端相连，在计算机设备700与外部终端之间的建立数据传输通道和通信连接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband CodeDivision Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图7仅示出了具有部件710-730的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器710中的权限管理方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器720)所执行，以完成本发明。

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的权限管理方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的权限管理方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (14)

1.一种权限管理方法，其特征在于，所述方法包括：

响应于权限文件的提取信号，提取代码分支的权限文件，其中，所述权限文件中包括用于管理所述代码分支的权限角色；

确定所述权限文件对应的权限存储路径；

解析所述权限文件，得到权限解析结果，其中，所述权限解析结果包括所述权限角色；以及

将所述权限存储路径和所述权限解析结果进行关联。

2.根据权利要求1所述方法，其特征在于，所述代码分支源于代码仓库，所述确定所述权限文件对应的权限存储路径，包括：

确定所述代码仓库的名称；

确定所述代码分支的名称；

确定所述权限文件源于的所述代码分支的目录层；以及

将所述代码仓库的名称、所述代码分支的名称和所述目录层作为所述权限存储路径。

3.根据权利要求1所述方法，其特征在于，所述解析所述权限文件，得到权限解析结果，包括：

从所述权限文件中确定出角色类型；

从所述权限文件中获取与所述角色类型对应的权限角色；以及

将所述角色类型和所述权限角色作为所述权限解析结果。

4.根据权利要求1所述方法，其特征在于，所述提取代码分支的权限文件，包括：

确定所述代码分支的根目录，其中，所述根目录中包括至少一个对象，所述对象包括文件或者文件夹；以及

若所述至少一个对象中存在所述权限文件，则从所述根目录中提取所述权限文件。

5.根据权利要求4所述方法，其特征在于，所述方法还包括：

若所述至少一个对象中不存在所述权限文件，则判断所述至少一个对象中是否存在所述文件夹；

若所述至少一个对象中存在至少一个所述文件夹，则判断所述至少一个所述文件夹中是否包括所述权限文件；以及

若所述至少一个所述文件夹中存在所述权限文件，则提取所述权限文件。

6.根据权利要求1所述方法，其特征在于，所述代码分支包括一个或多个代码分支，各个所述代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层。

7.一种权限管理系统，其特征在于，所述系统包括：

第一提取模块，用于响应于权限文件的提取信号，提取代码分支的权限文件，其中，所述权限文件中包括用于管理所述代码分支的权限角色；

确定模块，用于确定所述权限文件对应的权限存储路径；

解析模块，用于解析所述权限文件，得到权限解析结果，其中，所述权限解析结果包括所述权限角色；以及

关联模块，用于将所述权限存储路径和所述权限解析结果进行关联。

8.根据权利要求7所述系统，其特征在于，所述代码分支源于代码仓库，所述确定模块包括：

第一确定单元，用于确定所述代码仓库的名称；

第二确定单元，用于确定所述代码分支的名称；

第三确定单元，用于确定所述权限文件源于的所述代码分支的目录层；以及

第四确定单元，用于将所述代码仓库的名称、所述代码分支的名称和所述目录层作为所述权限存储路径。

9.根据权利要求7所述系统，其特征在于，所述解析模块包括：

第五确定单元，用于从所述权限文件中确定出角色类型；

获取单元，用于从所述权限文件中获取与所述角色类型对应的权限角色；以及

第六确定单元，用于将所述角色类型和所述权限角色作为所述权限解析结果。

10.根据权利要求7所述系统，其特征在于，所述第一提取模块包括：

第七确定单元，用于确定所述代码分支的根目录，其中，所述根目录中包括至少一个对象，所述对象包括文件或者文件夹；以及

提取单元，用于在所述至少一个对象中存在所述权限文件的情况下，从所述根目录中提取所述权限文件。

11.根据权利要求10所述系统，其特征在于，所述系统还包括：

第一判断模块，用于在所述至少一个对象中不存在所述权限文件的情况下，判断所述至少一个对象中是否存在所述文件夹；

第二判断模块，用于在所述至少一个对象中存在至少一个所述文件夹的情况下，判断所述至少一个所述文件夹中是否包括所述权限文件；以及

第二提取模块，用于在所述至少一个所述文件夹中存在所述权限文件的情况下，提取所述权限文件。

12.根据权利要求7所述系统，其特征在于，所述代码分支包括一个或多个代码分支，各个所述代码分支均对应有权限文件，其中，对于任一权限文件，该权限文件中的权限角色能够管理该权限文件源于的代码分支的目录层。

13.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时用于实现权利要求1至6任一项所述方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时用于实现权利要求1至6任一项所述方法的步骤。

Images