CN118132139A - 代码整合方法与装置 - Google Patents

Abstract

本申请提供了一种代码整合方法与装置、电子设备及存储介质，方法包括：将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库，能将厂商提供的系统源码进行整合，生成统一代码仓库，从而方便设备制造商对代码仓库进行管理与维护。

Description

代码整合方法与装置

技术领域

本发明涉及计算机领域，特别涉及一种代码整合方法与装置、电子设备及存储介质。

背景技术

AOSP作为Android系统的开源代码项目，随着代码版本的不断迭代，各个手机/设备厂商在升级AOSP代码版本的开发工作量较大，并且繁琐。为了解决这个问题，AOSP项目在Android 8.0以后进行了多项代码仓库的重构，其重点思路在于分离原生AOSP和厂商实现这两个部分。

实际在厂商开发Android设备时，其代码基本遵循AOSP的设计理念，从概念上包含了以下几个部分：

（1）原生的AOSP系统部分，这部分代码原则上是官方AOSP项目中拉取的代码，厂商不进行修改，随着AOSP代码更新而同步更新。但实际上厂商会对这部分做少量改动，作为与厂商实现系统部分所交互依赖的接口。

（2）厂商的AOSP系统部分，包括HAL层的实现，以及相关的运行时库，预置的程序和应用等。

（3）内核部分，包括开源的Linux内核源码，遵循GKI（通用内核映像）通用内核设计理念，分为common部分和厂商部分，其中common部分是通用的内核源码，仅包含Linux内核源码和Android所必须的内核构建配置；而厂商部分则加入了很多厂商的内核构建配置，甚至厂商的内核代码。

（4）厂商的底层实现，这部分不属于Android系统，因此不在AOSP中。这部分包含与设备相关的其它程序或数据，例如各个厂商的可信执行环境通常实现在这部分。

在设备制造商集成Android系统时，需要从厂商获取系统源码或预编译的镜像，进行设备制造商的定制开发后，应用在Android设备上。厂商的系统源码会提供给大量的设备制造商，所涉及的硬件组成也非常复杂，通常会针对不同的硬件进行单独的项目开发，因此其提供的系统源码会将大量的单独项目集成为一整套系统源码，代码的目录结构复杂，从而对于从厂商获取的系统源码，要在设备制造商内部维护一套代码仓库是非常繁琐的，并且难以对历史代码仓库做兼容。

因此，如何提供一种代码整合的方案，实现将厂商提供的系统源码进行整合，生成统一代码仓库，以方便设备制造商对代码仓库进行管理与维护，成为亟待解决的技术问题。

发明内容

针对现有技术存在的技术问题，本申请实施例提供一种代码整合方法与装置、电子设备及存储介质。

第一方面，本申请实施例提供了一种代码整合方法，包括：

将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

第二方面，本申请实施例还提供了一种代码整合装置，包括：

合并单元，用于将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

第一生成单元，用于基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

第二生成单元，用于基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

第三方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面所述的代码整合方法的步骤。

第四方面，本申请实施例还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面所述的代码整合方法的步骤。

通过上述方案，能够将厂商提供的系统源码进行整合，生成统一代码仓库，该代码仓库是一个repo仓库，该repo仓库管理多个git仓库，目录结构较为规范，从而设备制造商在基于该代码仓库进行定制化开发，构建出自己的系统源码仓库后，可以方便地对其版本进行向前兼容和迭代开发。

附图说明

图1为本申请实施例提供的一种代码整合方法一实施例的流程示意图；

图2为系统源码目录中除.repo目录和.git目录外的目录结构示意图；

图3为本申请实施例提供的一种代码整合装置一实施例的结构示意图；

图4为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

由于厂商提供的系统源码往往包含多个部分，每个部分由以下五种类型代码中的一种组成：

（1）一个git仓库；

（2）一个repo仓库管理的多个git仓库；

（3）多个repo仓库管理的多个git仓库；

（4）无git仓库和repo仓库管理的文件；

（5）以上任意方式混合在一起。

从而厂商提供的整套系统源码就是由多个repo仓库所管理的大量git仓库、非repo管理的大量git仓库以及一些无管理的文件所构成。因此，对于从厂商获取的系统源码，要在设备制造商内部维护一套代码仓库是非常繁琐的，并且难以对历史代码仓库做兼容和迭代开发。

参照图1所示，为本申请实施例提供的一种代码整合方法的流程示意图，该代码整合方法，包括：

S10、将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

本实施例中，需要说明的是，从厂商获取的系统源码可以是系统源码，或者预编译的系统镜像。为了将所有的代码整合到一个repo仓库去管理，设备制造商在从厂商获取系统源码后，需要按照传统Android系统源码的目录结构对系统源码进行合并，生成统一的系统源码目录。需要说明的是，系统源码中不属于Android系统的部分需要放在新增的目录中，该新增的目录为Android系统源码的目录结构中新增的目录，比如可以新增一个与Android系统源码中system目录、kernel目录、vendor目录等同级的目录作为新增的目录。

S11、基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

本实施例中，需要说明的是，每一个repo仓库都对应有一个清单配置文件（即manifest.xml文件），该清单配置文件中定义了该repo仓库所管理的所有git仓库，为了让整套系统源码能够遵循由一个repo仓库管理的目标，在生成统一的系统源码目录后，需要基于系统源码目录罗列出所有的git仓库的路径，生成包含所有的git仓库的路径的清单配置文件。该清单配置文件需要遵循的原则是没有git嵌套的情况以及所有的git仓库能够覆盖整套系统源码。

S12、基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

本实施例中，需要说明的是，在生成清单配置文件后，为了对齐清单配置文件中定义的全部git仓库，需要重新初始化每个git仓库，最终生成一个管理多个git仓库的repo仓库。

本申请实施例提供的代码整合方法，能够将厂商提供的系统源码进行整合，生成统一代码仓库，该代码仓库是一个repo仓库，该repo仓库管理多个git仓库，目录结构较为规范，从而设备制造商在基于该代码仓库进行定制化开发，构建出自己的系统源码仓库后，可以方便地对其版本进行向前兼容和迭代开发。

在前述方法实施例的基础上，所述将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，可以包括：

将系统源码中厂商的内核目录放入AOSP原生的内核目录；

将系统源码中厂商的vendor目录放入AOSP原生的vendor目录；

将系统源码中厂商的其它代码放入AOSP原生的代码目录中新增的目录，其中，系统源码中厂商的代码包括厂商的内核目录中的代码、厂商的vendor目录中的代码和其它代码。

本实施例中，需要说明的是，从厂商获取的系统源码从组成上包含AOSP原生的系统源码和厂商的源码，在进行源码合并时，需要将厂商的源码合并进AOSP原生的系统源码目录中。具体地，可以将厂商的源码中的相应部分合并进AOSP原生的系统源码目录中对应的目录中。比如，如果厂商的源码中包含vendor部分和kernel部分，则可以将该vendor部分放入AOSP原生的系统源码的vendor目录，以及将该kernel部分放入AOSP原生的系统源码的kernel目录；而厂商的源码中除了vendor部分和kernel部分外的其它代码部分与AOSP原生的系统源码目录中的目录不对应，则可以将其它代码部分放入AOSP原生的系统源码目录中新增的目录。

在前述方法实施例的基础上，所述基于系统源码目录生成一份清单配置文件，可以包括：

合并系统源码目录中所有repo仓库的清单配置文件，得到新的清单配置文件，其中，新的清单配置文件中包含多个git仓库的相对路径；

本实施例中，需要说明的是，在合并repo仓库的清单配置文件时，可以先查看该repo仓库是使用单独的manifest.xml文件还是使用多个manifest.xml文件合并而成的文件，如果是使用单独的manifest.xml文件，直接取该manifest.xml文件，否则如果是使用多个manifest.xml文件合并而成的文件，则取该repo仓库的由repo合并后的清单配置文件（比如snap_combined_manifest.xml文件）。将每个repo仓库按照上述方式取到manifest.xml文件或由repo合并后的清单配置文件后，可以进行文件遍历，对每个文件中的git仓库的路径进行合并，并基于合并后的git仓库的路径重新生成manifest.xml文件，作为新的整套系统源码的manifest文件。manifest.xml文件和由repo合并后的清单配置文件中可以包含git仓库的相对路径，此相对路径指的是git仓库相对相应repo仓库根目录的相对路径。在合并manifest.xml文件和由repo合并后的清单配置文件时，需要根据repo仓库的合并目录视情况修正（可以修正或不修正）repo仓库管理的git仓库的相对路径，比如AOSP原生的系统源码目录中存在一个git仓库记为gitA，清单配置文件中gitA的相对路径为gitA，厂商的源码中有一个repo仓库（记为repoM，repoM管理1个git仓库，记该git仓库为gitM1，清单配置文件中gitM1的相对路径为gitM1）合并进gitA，则在进行清单配置文件合并时， gitM1的相对地址需要修正为gitA/repoM/gitM1；再比如AOSP原生的系统源码目录中存在一个git仓库记为gitB，清单配置文件中gitB的相对路径为gitB，厂商的源码中有一个repo仓库（记为repoN，repoN管理1个git仓库，记该git仓库为gitN1，清单配置文件中gitN1的相对路径为gitN1）合并后与gitB处于相同的目录层级，则在进行清单配置文件合并时，gitN1的相对地址仍为gitN1，不需要修改。

需要说明的是，从厂商获取的系统源码的repo仓库的清单配置文件中还可以包含各个git仓库的地址（即git仓库在厂商服务器的存储地址），则在进行清单配置文件合并时，需要将该地址修正为在设备制造商本地机器的存储地址（比如可以修正为修正后的git仓库的相对路径）。

之后可以基于合并后的git仓库的相对路径/存储地址，重新生成manifest.xml文件，作为新的整套系统源码的清单配置文件。

遍历新的清单配置文件中的每一个git仓库的相对路径，检查系统源码目录中是否存在该相对路径，若存在，则保留该相对路径，否则，则删除新的清单配置文件中的该相对路径；

本实施例中，需要说明的是，对于新的整套系统源码的清单配置文件，需要遍历该清单配置文件中的git仓库，并检查每个git仓库的相对路径是否存在，如果不存在，需要在新的整套系统源码的清单配置文件中将该git仓库删除。

遍历系统源码目录中的每一个git仓库，检查新的清单配置文件中是否存在该git仓库的信息，若存在，则保留新的清单配置文件中该git仓库的信息，否则，则在新的清单配置文件中添加该git仓库的相对路径；

本实施例中，需要说明的是，需要遍历新系统源码根目录，搜索出所有git仓库，并查找该git仓库是否在新系统源码的清单配置文件中存在，如果不存在，则需要将该git仓库添加到新系统源码的清单配置文件中。

将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，并将所述至少一个git仓库的相对路径添加到新的清单配置文件中。

本实施例中，需要说明的是，对于无git仓库或repo仓库管理的这部分厂商提供的代码，需要按照repo仓库的git仓库划分的原则，生成最优的（集合个数最少的）git仓库，并添加到新系统源码的清单配置文件中。

在前述方法实施例的基础上，所述将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，可以包括：

获取系统源码目录中除.repo目录和.git目录外的其它所有目录和文件的相对路径（指的是相对repo仓库根目录的相对路径），将其它所有目录和文件的相对路径保存到第一集合all_files_set中；

获取新的清单配置文件中的各个git仓库的相对路径，将各个git仓库的相对路径、相对路径下包含的除.repo目录和.git目录外的其它所有目录和文件的相对路径，以及相对路径的所有父路径保存到第二集合managed_files_set中（注意需要去重，保证managed_files_set集合中的项是唯一的）；

计算第二集合managed_files_set在第一集合all_files_set中的补集，得到第三集合unmanaged_files_set；

遍历第三集合unmanaged_files_set中的每一个相对路径，从该相对路径开始，依次遍历该相对路径以及该相对路径的每一级父路径，直至找到一个属于第二集合managed_files_set的相对路径，将本次遍历过的且属于第二集合managed_files_set的相对路径的下一级相对路径添加到第四集合unmanaged_git_projects中；

将第四集合unmanaged_git_projects中的项添加到新的清单配置文件中。

下面以具体的例子说明本实施例中的过程。

假设系统源码目录中除.repo目录和.git目录外的部分如图2所示，图2中示出的repo仓库的repo根目录包含P文件夹，P文件夹中包含1个git仓库（记为P1）和1个文件（记为P2），P1中包含2个文件，分别记为P11和P12，P2中包含2个git仓库，分别记为P21和P22，P21中又包含一个文件夹（记为P211），P22是厂商源码，重新生成的清单配置文件中包含{P/P1，P/P2/P21}。则all_files_set={P，P/P1，P/P1/P11，P/P1/P12，P/P2，P/P2/P21，P/P2/P21/P211，P/P2/P22}，managed_files_set={P，P/P1，P/P1/P11，P/P1/P12，P/P2，P/P2/P21，P/P2/P21/P211}，unmanaged_git_projects=all_files_set-managed_files_set={P/P2/P22}，因为P/P2/P22的上一级目录为P/P2属于managed_files_set，P/P2/P22不属于managed_files_set，则需要将P/P2/P22添加进unmanaged_git_projects中。

在前述方法实施例的基础上，所述方法还可以包括：

在新的清单配置文件中清除嵌套进其它git仓库的git仓库的相对路径。

本实施例中，需要说明的是，厂商提供的系统源码中，可能因为不规范或者合并多个部分的代码导致存在git仓库嵌套的问题。对于这类问题，在新系统源码的清单配置文件中，需要保留一个最大git仓库，并删除其余嵌套的git仓库。

在前述方法实施例的基础上，所述基于清单配置文件生成代码仓库，可以包括：

删除系统源码目录中的所有.repo目录和.git目录；

遍历新的清单配置文件中的每一个git仓库的相对路径，基于该相对路径重新生成该git仓库的.git目录，将该git仓库的代码添加进该git仓库，并提交。

本实施例中，需要说明的是，为了对齐新系统源码的清单配置文件中定义的全部git仓库，需要重新初始化每个git仓库，具体可以包括如下步骤：

（1）清除从厂商下载代码拼凑后的不统一的代码管理结构，即删除新系统源码中所有.repo和.git目录；

（2）遍历新系统源码的清单配置文件中定义的全部git仓库，进入其每个git仓库的相对路径，重新初始化git工程，创建分支，将所有代码文件添加并提交（需强制全部添加提交）。

至此已经创建好统一的系统源码仓库，需要验证该仓库是否可用。具体可以在本地使用repo工具拉取该仓库的代码，验证拉取的代码和系统源码仓库中的代码是否一致，如果一致，则说明系统源码仓库创建成功，否则，说明创建过程中存在问题。

参照图3所示，为本申请实施例提供的一种代码整合装置的结构示意图，该装置包括：

合并单元30，用于将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

第一生成单元31，用于基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

第二生成单元32，用于基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

本申请实施例提供的代码整合装置，能够将厂商提供的系统源码进行整合，生成统一代码仓库，该代码仓库是一个repo仓库，该repo仓库管理多个git仓库，目录结构较为规范，从而设备制造商在基于该代码仓库进行定制化开发，构建出自己的系统源码仓库后，可以方便地对其版本进行向前兼容和迭代开发。

在前述装置实施例的基础上，所述第一生成单元，具体可以用于：

合并系统源码目录中所有repo仓库的清单配置文件，得到新的清单配置文件，其中，新的清单配置文件中包含多个git仓库的相对路径；

遍历新的清单配置文件中的每一个git仓库的相对路径，检查系统源码目录中是否存在该相对路径，若存在，则保留该相对路径，否则，则删除新的清单配置文件中的该相对路径；

遍历系统源码目录中的每一个git仓库，检查新的清单配置文件中是否存在该git仓库的信息，若存在，则保留新的清单配置文件中该git仓库的信息，否则，则在新的清单配置文件中添加该git仓库的相对路径；

将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，并将所述至少一个git仓库的相对路径添加到新的清单配置文件中。

本申请实施例提供的代码整合装置，其实现过程与本申请实施例提供的代码整合方法一致，所能达到的效果也与本申请实施例提供的代码整合方法相同，在此不再赘述。

如图4所示，本申请实施例提供的一种电子设备，包括：处理器40、存储器41和总线42，所述存储器41存储有所述处理器40可执行的机器可读指令，当电子设备运行时，所述处理器40与所述存储器41之间通过总线42通信，所述处理器40执行所述机器可读指令，以执行如上述代码整合方法的步骤。

具体地，上述存储器41和处理器40能够为通用的存储器和处理器，这里不做具体限定，当处理器40运行存储器41存储的计算机程序时，能够执行上述代码整合方法。

对应于上述代码整合方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述代码整合方法的步骤。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种代码整合方法，其特征在于，包括：

将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

2.如权利要求1所述的方法，其特征在于，所述将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，包括：

将系统源码中厂商的内核目录放入AOSP原生的内核目录；

将系统源码中厂商的vendor目录放入AOSP原生的vendor目录；

将系统源码中厂商的其它代码放入AOSP原生的代码目录中新增的目录，其中，系统源码中厂商的代码包括厂商的内核目录中的代码、厂商的vendor目录中的代码和其它代码。

3.如权利要求1或2所述的方法，其特征在于，所述基于系统源码目录生成一份清单配置文件，包括：

合并系统源码目录中所有repo仓库的清单配置文件，得到新的清单配置文件，其中，新的清单配置文件中包含多个git仓库的相对路径；

遍历新的清单配置文件中的每一个git仓库的相对路径，检查系统源码目录中是否存在该相对路径，若存在，则保留该相对路径，否则，则删除新的清单配置文件中的该相对路径；

遍历系统源码目录中的每一个git仓库，检查新的清单配置文件中是否存在该git仓库的信息，若存在，则保留新的清单配置文件中该git仓库的信息，否则，则在新的清单配置文件中添加该git仓库的相对路径；

将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，并将所述至少一个git仓库的相对路径添加到新的清单配置文件中。

4.如权利要求3所述的方法，其特征在于，所述将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，包括：

获取系统源码目录中除.repo目录和.git目录外的其它所有目录和文件的相对路径，将其它所有目录和文件的相对路径保存到第一集合all_files_set中；

获取新的清单配置文件中的各个git仓库的相对路径，将各个git仓库的相对路径、相对路径下包含的除.repo目录和.git目录外的其它所有目录和文件的相对路径，以及相对路径的所有父路径保存到第二集合managed_files_set中；

计算第二集合managed_files_set在第一集合all_files_set中的补集，得到第三集合unmanaged_files_set；

遍历第三集合unmanaged_files_set中的每一个相对路径，从该相对路径开始，依次遍历该相对路径以及该相对路径的每一级父路径，直至找到一个属于第二集合managed_files_set的相对路径，将本次遍历过的且属于第二集合managed_files_set的相对路径的下一级相对路径添加到第四集合unmanaged_git_projects中；

将第四集合unmanaged_git_projects中的项添加到新的清单配置文件中。

5.如权利要求3所述的方法，其特征在于，还包括：

在新的清单配置文件中清除嵌套进其它git仓库的git仓库的相对路径。

6.如权利要求1所述的方法，其特征在于，所述基于清单配置文件生成代码仓库，包括：

删除系统源码目录中的所有.repo目录和.git目录；

遍历新的清单配置文件中的每一个git仓库的相对路径，基于该相对路径重新生成该git仓库的.git目录，将该git仓库的代码添加进该git仓库，并提交。

7.一种代码整合装置，其特征在于，包括：

合并单元，用于将从厂商获取的系统源码按照传统Android系统源码的目录结构进行合并，得到系统源码目录，其中，系统源码目录中新增有用于存放系统源码中厂商底层实现代码的目录；

第一生成单元，用于基于系统源码目录生成一份清单配置文件，其中，所述清单配置文件中包含多个git仓库的路径；

第二生成单元，用于基于清单配置文件生成代码仓库，其中，代码仓库是一个repo仓库，repo仓库管理所述多个git仓库。

8.如权利要求7所述的装置，其特征在于，所述第一生成单元，具体用于：

合并系统源码目录中所有repo仓库的清单配置文件，得到新的清单配置文件，其中，新的清单配置文件中包含多个git仓库的相对路径；

遍历新的清单配置文件中的每一个git仓库的相对路径，检查系统源码目录中是否存在该相对路径，若存在，则保留该相对路径，否则，则删除新的清单配置文件中的该相对路径；

遍历系统源码目录中的每一个git仓库，检查新的清单配置文件中是否存在该git仓库的信息，若存在，则保留新的清单配置文件中该git仓库的信息，否则，则在新的清单配置文件中添加该git仓库的相对路径；

将系统源码目录中无repo仓库和git仓库管理的代码按照repo仓库的git仓库划分的原则生成至少一个git仓库，并将所述至少一个git仓库的相对路径添加到新的清单配置文件中。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至6任一项所述的代码整合方法的步骤。

10.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至6任一项所述的代码整合方法的步骤。