Code library item synchronization method and device, storage medium and electronic equipment

Abstract

The invention relates to a code library item synchronization method and device, a storage medium and electronic equipment. The method comprises the steps that after a parent code library project is updated, a new submission identifier and an old submission identifier of each sub-code library project of the parent code library project are obtained, the new submission identifier is recorded in a first G-it warehouse of the parent code library project, and the old submission identifier is recorded in a second G-it warehouse of each sub-code library project; determining at least one item to be updated from all the sub-code library items of the parent code library item according to the new submission identifier and the old submission identifier of each sub-code library item; determining an access state of the to-be-updated item, and synchronizing the to-be-updated item according to the access state and the compiling file of the parent code library item; and according to the new submission identifier of the to-be-updated project, synchronizing the old submission identifier of the to-be-updated project. According to the method and the device, the technical problems of low synchronization efficiency, high error rate and poor safety of manual synchronization code library items are solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a method, device, storage medium and electronic device for synchronizing a code library project. Background Art

[0002] In the Yocto (an open source project for embedded system development that provides a set of tools and frameworks to help developers build embedded Linux systems that meet specific hardware and application requirements) compilation system, Repo (Repository) allows the definition of a list of all related repositories and provides a simple way to synchronize and manage these Git repositories. When a set of Repo codes needs to create a sub-project, and some of the code of the sub-project needs to be closed source, and when the parent project is updated, the Git repository codes in the parent project are usually synchronized manually to the Git repository of the sub-project, resulting in low synchronization efficiency, high error rate, and poor security of the code library project. Summary of the invention

[0003] The present application provides a method, device, storage medium and electronic device for synchronizing a code base project to solve the technical problems of low synchronization efficiency, high error rate and poor security of manually synchronizing code base projects.

[0004] In a first aspect, the present application provides a method for synchronizing a code base project, comprising: after a parent code base project is updated, obtaining a new submission identifier and an old submission identifier of each child code base project of the parent code base project, wherein the new submission identifier is recorded in a first Git repository of the parent code base project, and the old submission identifier is recorded in a second Git repository of each child code base project; according to the new submission identifier and the old submission identifier of each child code base project, determining at least one project to be updated from all child code base projects of the parent code base project; determining an access status of the project to be updated, and synchronizing the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status; synchronizing the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated.

[0005] In the second aspect, the present application provides a synchronization device for a code base project, including: an acquisition module, used to obtain the new submission identifier and the old submission identifier of each child code base project of the parent code base project after the parent code base project is updated, wherein the new submission identifier is recorded in the first Git repository of the parent code base project, and the old submission identifier is recorded in the second Git repository of each child code base project; a determination module, used to determine at least one project to be updated from all child code base projects of the parent code base project according to the new submission identifier and the old submission identifier of each child code base project; a first synchronization module, used to determine the access status of the project to be updated, and synchronize the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status; a second synchronization module, used to synchronize the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated.

[0006] As an optional example, the apparatus further includes: a compilation module, configured to compile the parent code base project to obtain the compiled file before obtaining the new submission identifier and the old submission identifier of each child code base project of the parent code base project.

[0007] As an optional example, the acquisition module includes: a first processing unit, used to take each child code base project of the parent code base project as the current child code base project, and perform the following operations on the current child code base project: obtain the new submission identifier of the current child code base project from the first Git repository of the parent code base project; obtain the old submission identifier of the current child code base project from the second Git repository of the current child code base project.

[0008] As an optional example, the determination module includes: a second processing unit, used to take each child code base project of the parent code base project as a current child code base project, and perform the following operations on the current child code base project: compare the new submission identifier and the old submission identifier of the current child code base project; when the new submission identifier and the old submission identifier of the current child code base project are different, determine that the current child code base project is a project to be updated; when the new submission identifier and the old submission identifier of the current child code base project are the same, determine that the current child code base project is a project not to be updated.

[0009] As an optional example, the first synchronization module includes: a first synchronization unit, configured to copy the compiled file to the project to be updated when the access status of the project to be updated is a closed source status.

[0010] As an optional example, the above-mentioned first synchronization module includes: a determination unit, which is used to determine the difference file of the above-mentioned project to be updated from the above-mentioned compiled file according to the new submission identifier and the old submission identifier of the above-mentioned project to be updated when the access status of the above-mentioned project to be updated is an open source status; and a first synchronization unit, which is used to copy the above-mentioned difference file to the above-mentioned project to be updated.

[0011] As an optional example, the above-mentioned second synchronization module includes: an acquisition unit, used to obtain the new submission identifier of the above-mentioned project to be updated from the first Git repository of the above-mentioned parent code base project; a second synchronization unit, used to modify the old submission identifier of the above-mentioned project to be updated recorded in the second Git repository of the above-mentioned project to be updated to the new submission identifier of the above-mentioned project to be updated.

[0012] In a third aspect, the present application provides a storage medium storing a computer program, wherein the computer program executes the synchronization method of the above-mentioned code library project when executed by a processor.

[0013] In a fourth aspect, the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-mentioned code library project synchronization method through the computer program.

[0014] In an embodiment of the present application, after the parent code library project is updated, the new submission identifier and the old submission identifier of each child code library project of the above-mentioned parent code library project are obtained, wherein the above-mentioned new submission identifier is recorded in the first Git repository of the above-mentioned parent code library project, and the above-mentioned old submission identifier is recorded in the second Git repository of each of the above-mentioned child code library projects; according to the new submission identifier and the old submission identifier of each of the above-mentioned child code library projects, at least one project to be updated is determined from all the child code library projects of the above-mentioned parent code library project; the access status of the above-mentioned project to be updated is determined, and the above-mentioned project to be updated is updated according to the above-mentioned access status and the compiled file of the above-mentioned parent code library project. The method is to synchronize the project, wherein the access status includes an open source status and a closed source status; according to the new submission identifier of the project to be updated, the old submission identifier of the project to be updated is synchronized. In the above method, the sub-code library project to be updated is determined by automatically obtaining and comparing the new and old submission identifiers, and different synchronization update operations are performed according to the access status of the sub-code library project to ensure that all sub-code library projects can be synchronized to the latest version, thereby realizing the purpose of automatically executing code synchronization operations without manual intervention, improving the efficiency of synchronization work, and further solving the technical problems of low synchronization efficiency, high error rate and poor security of manually synchronizing code library projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0016] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0017] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0018] Figure 1 is a flowchart of an optional method for synchronizing a code base project according to an embodiment of the present application;

[0019] Figure 2 It is a specific implementation flow chart of an optional method for synchronizing a code base project according to an embodiment of the present application;

[0020] Figure 3 is a schematic structural diagram of an optional device for synchronizing a code library project according to an embodiment of the present application;

[0021] Figure 4 is a schematic diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0023] The disclosure below provides many different embodiments or examples to realize the different structures of the present application. In order to simplify the disclosure of the present application, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0024] According to a first aspect of an embodiment of the present application, a method for synchronizing a code base project is provided. Optionally, as follows: Figure 1 As shown, the above method includes:

[0025] S102, after the parent code base project is updated, obtaining a new commit identifier and an old commit identifier of each child code base project of the parent code base project, wherein the new commit identifier is recorded in the first Git repository of the parent code base project, and the old commit identifier is recorded in the second Git repository of each child code base project;

[0026] S104, determining at least one project to be updated from all sub-code library projects of the parent code library project according to the new submission identifier and the old submission identifier of each sub-code library project;

[0027] S106, determining the access status of the project to be updated, and synchronizing the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status;

[0028] S108: Synchronize the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated.

[0029] Optionally, in this embodiment, the code base project (Repo project) is a place for storing and managing code, files, and documents, which is usually managed by a version control system (such as Git). A code base project can include source code, configuration files, documents, and historical versions of the project. The Git repository is a place where the Git version control system is used to store and manage project code and related files. It contains all the files of the project and the historical records of each file. In Git, the relationship between the parent Repo project and the child Repo project is usually implemented through submodules. The submodule allows a Git repository (parent Repo project) to contain other independent Git repositories (child Repo projects), thereby embedding and managing multiple code bases in one project. The child Repo project is an independent project embedded in a larger parent Repo project. Each child Repo project is an independent Git repository containing its own code and historical records. The parent Repo project manages these child Repo projects through a submodule mechanism. The commit identifier, that is, Commit ID, is a hash value used to uniquely identify a commit in Git. It is usually a 40-bit SHA-1 hash string. Each time you submit code to a Git repository, Git generates a unique commit ID, which is an encrypted hash of the commit content, ensuring that each commit is unique. With the commit ID, you can accurately find any commit, including the specific content, author, time, and other detailed information of the commit. If there is a problem with the code, you can use the commit ID to roll back to a previous version or restore the specific content of a commit. Using the commit ID, you can compare two different versions of the code, view the differences, and then synchronize updates.

[0030] Optionally, in this embodiment, after the parent code base project is updated, each sub-code base project is automatically updated according to the updated situation of the parent code base project. Specifically, the new submission mark of each sub-code base project of the parent code base project is obtained from the first Git repository of the parent code base project, and the old submission mark of each sub-code base project is obtained from the second Git repository of each sub-code base project. According to the new submission mark and the old submission mark of each sub-code base project, it is determined which sub-code base projects need to be updated, that is, the new submission mark and the old submission mark are compared. If the two are different, it means that the sub-code base project has been updated and subsequent synchronization operations are required. Determine the access status of the project to be updated, that is, determine whether the project is open source or closed source. If it is open source, determine the difference file of the project from the compiled file of the parent code base project according to the new submission mark and the old submission mark of the project to be updated, and then copy the difference file to the project to be updated. If it is closed source, directly copy the compiled file of the parent code base project to the project to be updated. At the same time, obtain the new commit identifier of the project to be updated from the first Git repository of the parent code base project, and modify the old commit identifier recorded in the second Git repository of the project to be updated to the new commit identifier, so as to ensure that all sub-code base projects can be synchronized to the latest version.

[0031] Optionally, in this embodiment, by automatically obtaining and comparing new and old submission identifiers, the sub-code library project that needs to be updated is determined, and different synchronization update operations are performed according to the access status of the sub-code library project, ensuring that all sub-code library projects can be synchronized to the latest version, thereby achieving the purpose of automatically executing code synchronization operations without manual intervention, thereby improving the efficiency of synchronization work, and further solving the technical problems of low synchronization efficiency, high error rate and poor security of manually synchronizing code library projects.

[0032] As an optional example, before obtaining the new submission identifier and the old submission identifier of each child code base project of the parent code base project, the above method further includes:

[0033] Compile the parent code base project to obtain the compiled files.

[0034] Optionally, in this embodiment, after the parent code base project is updated, before each child code base project is automatically updated according to the updated situation of the parent code base project, the entire project is first compiled based on the latest parent code base project code to obtain the compiled file of the parent code base project.

[0035] As an optional example, obtaining the new commit identifier and the old commit identifier of each child code base project of the parent code base project includes:

[0036] Set each sub-codebase project of the parent codebase project as the current sub-codebase project, and perform the following operations on the current sub-codebase project:

[0037] Get the new commit identifier of the current child code base project from the first Git repository of the parent code base project;

[0038] Get the old commit identifier of the current sub-codebase project from the second Git repository of the current sub-codebase project.

[0039] Optionally, in this embodiment, when obtaining the new submission mark and the old submission mark of each sub-code library project of the parent code library project, taking a sub-code library project as an example, in the parent code library project, there is a main warehouse (first Git warehouse) that records the latest submission marks of all sub-code library projects, and the corresponding new submission mark is found for this sub-code library project in the first Git warehouse. Each sub-code library project has its own warehouse (second Git warehouse), which records the submission mark of the last synchronization of the project, and finds its corresponding old submission mark for this sub-code library project in its second Git warehouse. By analogy, the new submission mark and the old submission mark of each sub-code library project of the parent code library project are obtained. By obtaining the new and old submission marks of each sub-code library project, after the parent code library project is updated, the sub-code library project that needs to be updated can be accurately and efficiently determined, and a solid foundation is laid for subsequent synchronous update operations, which not only improves the efficiency of synchronization and management, but also enhances the accuracy and consistency of version control.

[0040] As an optional example, according to the new submission identifier and the old submission identifier of each sub-code base project, determining at least one project to be updated from all sub-code base projects of the parent code base project includes:

[0041] Set each sub-codebase project of the parent codebase project as the current sub-codebase project, and perform the following operations on the current sub-codebase project:

[0042] Compare the new commit identifier and the old commit identifier of the current sub-codebase project;

[0043] When the new submission identifier and the old submission identifier of the current sub-code base project are different, the current sub-code base project is determined to be a project to be updated;

[0044] When the new submission identifier and the old submission identifier of the current sub-code base project are the same, it is determined that the current sub-code base project is not a project to be updated.

[0045] Optionally, in this embodiment, when determining which sub-code library projects need to be updated based on the new submission identifier and the old submission identifier of each sub-code library project, it is necessary to process each sub-code library project one by one and compare them. Taking a sub-code library project as an example, the new submission identifier and the old submission identifier of this sub-code library project are compared. If the new submission identifier and the old submission identifier are different, it means that the sub-code library project has been updated, and a subsequent synchronization update operation is required to determine that the sub-code library project is a project to be updated. If the new submission identifier and the old submission identifier are the same, the sub-code library project has not changed, and no subsequent synchronization update operation is required, and the sub-code library project is determined to be a non-project to be updated. By analogy, each sub-code library project is compared and processed to determine all sub-code library projects that need to be updated. By comparing the new and old submission identifiers one by one, it is precisely identified which sub-code library projects need to be updated to avoid omissions or erroneous updates. Automatically compare the new and old submission identifiers, reduce the time and effort of manual inspection, and improve work efficiency. Only process the projects that need to be updated, optimize resource utilization, and avoid unnecessary repeated operations.

[0046] As an optional example, synchronizing the project to be updated based on the access status and the compiled files of the parent code base project includes:

[0047] When the access status of the project to be updated is closed source, copy the compiled file to the project to be updated.

[0048] As an optional example, synchronizing the project to be updated based on the access status and the compiled files of the parent code base project includes:

[0049] When the access status of the project to be updated is open source, the difference file of the project to be updated is determined from the compiled file according to the new submission identifier and the old submission identifier of the project to be updated;

[0050] Copy the difference file to the project to be updated.

[0051] Optionally, in this embodiment, the project to be updated should be synchronized according to the access status and the compiled files of the parent code base project. It is necessary to distinguish the access status (open source or closed source) of the project to be updated, and adopt the corresponding synchronous update method. Specifically, first determine the access status of the project to be updated, whether it is open source or closed source. The code of the closed source project is not public, only the compiled binary file, and the code of the open source project is public, and the source code can be directly accessed and modified. Since the closed source project does not disclose the source code, it can only be updated through the compiled binary file. Therefore, if the project to be updated is in a closed source state, the corresponding compiled file in the parent code base project is copied to the project to be updated, overwriting the old compiled file. If the project to be updated is in an open source state, the new submission mark and the old submission mark of the project to be updated are compared to determine the files that have changed since the last update. These difference files reflect the specific changes between the new and old versions. The difference files are extracted from the compiled files of the parent code base project, and these difference files are copied to the project to be updated, overwriting the old files, and completing the synchronous update of the project to be updated.

[0052] Optionally, in this embodiment, different automatic synchronization methods are adopted according to the access status of the project to be updated to achieve efficient and accurate project updates. For closed-source projects, the compiled files are directly copied to simplify the operation; for open-source projects, the accuracy and consistency of the versions are ensured through differential file updates, which not only improves the efficiency of synchronization and management, but also enhances the accuracy and consistency of version control.

[0053] As an optional example, synchronizing the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated includes:

[0054] Get the new commit identifier of the project to be updated from the first Git repository of the parent code base project;

[0055] The old submission identifier of the project to be updated recorded in the second Git repository of the project to be updated is modified to the new submission identifier of the project to be updated.

[0056] Optionally, in this embodiment, to synchronize the old commit identifier of the second Git repository in the project to be updated, it is necessary to obtain a new commit identifier and update the old commit identifier to the new commit identifier. Obtaining the new commit identifier and updating the old commit identifier not only maintains the version consistency of the subproject and the parent project, but also simplifies the version control process, reduces the risk of errors, improves the efficiency of development and management, and enhances the traceability and transparency of the project.

[0057] In conjunction with an example, the present application relates to a method for synchronizing a code base project, such as Figure 2 The specific implementation flow chart is shown in FIG. 1 , which includes the following steps:

[0058] 1. Compile the parent code base project to get the compiled file;

[0059] 2. Get the new commit identifier and old commit identifier of each child code base project of the parent code base project;

[0060] 3. According to the new submission identifier and old submission identifier of each sub-code base project, determine whether each sub-code base project is a project to be updated. If so, proceed to the next step. If not, no processing is required;

[0061] 4. Determine the access status of the project to be updated. If it is closed source, execute step 5; if it is open source, execute step 6;

[0062] 5. Copy the compiled file to the project to be updated, and update the old submission identifier to the new submission identifier;

[0063] 6. According to the new submission identifier and the old submission identifier of the project to be updated, determine the difference file of the project to be updated from the compiled file, copy the difference file to the project to be updated, and update the old submission identifier to the new submission identifier.

[0064] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0065] According to another aspect of the embodiment of the present application, a synchronization device for a code library project is also provided, such as Figure 3 As shown, including:

[0066] The acquisition module 302 is used to acquire the new submission identifier and the old submission identifier of each child code base project of the parent code base project after the parent code base project is updated, wherein the new submission identifier is recorded in the first Git repository of the parent code base project, and the old submission identifier is recorded in the second Git repository of each child code base project;

[0067] A determination module 304 is used to determine at least one project to be updated from all the sub-code base projects of the parent code base project according to the new submission identifier and the old submission identifier of each sub-code base project;

[0068] A first synchronization module 306 is used to determine the access status of the project to be updated, and synchronize the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status;

[0069] The second synchronization module 308 is used to synchronize the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated.

[0070] Optionally, in this embodiment, the code base project (Repo project) is a place for storing and managing code, files, and documents, which is usually managed by a version control system (such as Git). A code base project can include the source code, configuration files, documents, and historical versions of the project. Git warehouse is a place where the Git version control system is used to store and manage project code and related files. It contains all the files of the project and the historical records of each file. In Git, the relationship between the parent Repo project and the child Repo project is usually realized through submodules. Submodules allow a Git warehouse (parent Repo project) to contain other independent Git warehouses (child Repo projects), thereby embedding and managing multiple code bases in one project. The child Repo project is an independent project embedded in a larger parent Repo project. Each child Repo project is an independent Git warehouse containing its own code and historical records. The parent Repo project manages these child Repo projects through a submodule mechanism. The commit identifier, that is, Commit ID, is a hash value used to uniquely identify a commit in Git. It is usually a 40-bit SHA-1 hash string. Each time you submit code to a Git repository, Git generates a unique commit ID, which is an encrypted hash of the commit content, ensuring that each commit is unique. With the commit ID, you can accurately find any commit, including the specific content, author, time, and other detailed information of the commit. If there is a problem with the code, you can use the commit ID to roll back to a previous version or restore the specific content of a commit. Using the commit ID, you can compare two different versions of the code, view the differences, and then synchronize updates.

[0071] Optionally, in this embodiment, after the parent code base project is updated, each sub-code base project is automatically updated according to the updated situation of the parent code base project. Specifically, the new submission mark of each sub-code base project of the parent code base project is obtained from the first Git repository of the parent code base project, and the old submission mark of each sub-code base project is obtained from the second Git repository of each sub-code base project. According to the new submission mark and the old submission mark of each sub-code base project, it is determined which sub-code base projects need to be updated, that is, the new submission mark and the old submission mark are compared. If the two are different, it means that the sub-code base project has been updated and subsequent synchronization operations are required. Determine the access status of the project to be updated, that is, determine whether the project is open source or closed source. If it is open source, determine the difference file of the project from the compiled file of the parent code base project according to the new submission mark and the old submission mark of the project to be updated, and then copy the difference file to the project to be updated. If it is closed source, directly copy the compiled file of the parent code base project to the project to be updated. At the same time, obtain the new commit identifier of the project to be updated from the first Git repository of the parent code base project, and modify the old commit identifier recorded in the second Git repository of the project to be updated to the new commit identifier, so as to ensure that all sub-code base projects can be synchronized to the latest version.

[0072] Optionally, in this embodiment, by automatically obtaining and comparing new and old submission identifiers, the sub-code library project that needs to be updated is determined, and different synchronization update operations are performed according to the access status of the sub-code library project, ensuring that all sub-code library projects can be synchronized to the latest version, thereby achieving the purpose of automatically executing code synchronization operations without manual intervention, thereby improving the efficiency of synchronization work, and further solving the technical problems of low synchronization efficiency, high error rate and poor security of manually synchronizing code library projects.

[0073] As an optional example, the above device further includes:

[0074] The compiling module is used to compile the parent code base project to obtain the compiled file before obtaining the new submission mark and the old submission mark of each child code base project of the parent code base project.

[0075] Optionally, in this embodiment, after the parent code base project is updated, before each child code base project is automatically updated according to the updated situation of the parent code base project, the entire project is first compiled based on the latest parent code base project code to obtain the compiled file of the parent code base project.

[0076] As an optional example, the acquisition module includes:

[0077] The first processing unit is used to take each sub-code base project of the parent code base project as the current sub-code base project, and perform the following operations on the current sub-code base project:

[0078] Get the new commit identifier of the current child code base project from the first Git repository of the parent code base project;

[0079] Get the old commit identifier of the current sub-codebase project from the second Git repository of the current sub-codebase project.

[0080] Optionally, in this embodiment, when obtaining the new submission mark and the old submission mark of each sub-code library project of the parent code library project, taking a sub-code library project as an example, in the parent code library project, there is a main warehouse (first Git warehouse) that records the latest submission marks of all sub-code library projects, and the corresponding new submission mark is found for this sub-code library project in the first Git warehouse. Each sub-code library project has its own warehouse (second Git warehouse), which records the submission mark of the last synchronization of the project, and finds its corresponding old submission mark for this sub-code library project in its second Git warehouse. By analogy, the new submission mark and the old submission mark of each sub-code library project of the parent code library project are obtained. By obtaining the new and old submission marks of each sub-code library project, after the parent code library project is updated, the sub-code library project that needs to be updated can be accurately and efficiently determined, and a solid foundation is laid for subsequent synchronous update operations, which not only improves the efficiency of synchronization and management, but also enhances the accuracy and consistency of version control.

[0081] As an optional example, the determination module includes:

[0082] The second processing unit is used to take each sub-code base project of the parent code base project as the current sub-code base project, and perform the following operations on the current sub-code base project:

[0083] Compare the new commit identifier and the old commit identifier of the current sub-codebase project;

[0084] When the new submission identifier and the old submission identifier of the current sub-code base project are different, the current sub-code base project is determined to be a project to be updated;

[0085] When the new submission identifier and the old submission identifier of the current sub-code base project are the same, it is determined that the current sub-code base project is not a project to be updated.

[0086] Optionally, in this embodiment, when determining which sub-code library projects need to be updated based on the new submission identifier and the old submission identifier of each sub-code library project, it is necessary to process each sub-code library project one by one and compare them. Taking a sub-code library project as an example, the new submission identifier and the old submission identifier of this sub-code library project are compared. If the new submission identifier and the old submission identifier are different, it means that the sub-code library project has been updated, and a subsequent synchronization update operation is required to determine that the sub-code library project is a project to be updated. If the new submission identifier and the old submission identifier are the same, the sub-code library project has not changed, and no subsequent synchronization update operation is required, and the sub-code library project is determined to be a non-project to be updated. By analogy, each sub-code library project is compared and processed to determine all sub-code library projects that need to be updated. By comparing the new and old submission identifiers one by one, it is precisely identified which sub-code library projects need to be updated to avoid omissions or erroneous updates. Automatically compare the new and old submission identifiers, reduce the time and effort of manual inspection, and improve work efficiency. Only process the projects that need to be updated, optimize resource utilization, and avoid unnecessary repeated operations.

[0087] As an optional example, the first synchronization module includes:

[0088] The first synchronization unit is used to copy the compiled file to the project to be updated when the access status of the project to be updated is a closed source state.

[0089] As an optional example, the first synchronization module includes:

[0090] a determination unit, configured to determine a difference file of the project to be updated from the compiled file according to a new submission identifier and an old submission identifier of the project to be updated when the access status of the project to be updated is an open source status;

[0091] The first synchronization unit is used to copy the difference file to the project to be updated.

[0092] Optionally, in this embodiment, the project to be updated should be synchronized according to the access status and the compiled files of the parent code base project. It is necessary to distinguish the access status (open source or closed source) of the project to be updated, and adopt the corresponding synchronous update method. Specifically, first determine the access status of the project to be updated, whether it is open source or closed source. The code of the closed source project is not public, only the compiled binary file, and the code of the open source project is public, and the source code can be directly accessed and modified. Since the closed source project does not disclose the source code, it can only be updated through the compiled binary file. Therefore, if the project to be updated is in a closed source state, the corresponding compiled file in the parent code base project is copied to the project to be updated, overwriting the old compiled file. If the project to be updated is in an open source state, the new submission mark and the old submission mark of the project to be updated are compared to determine the files that have changed since the last update. These difference files reflect the specific changes between the new and old versions. The difference files are extracted from the compiled files of the parent code base project, and these difference files are copied to the project to be updated, overwriting the old files, and completing the synchronous update of the project to be updated.

[0093] Optionally, in this embodiment, different automatic synchronization methods are adopted according to the access status of the project to be updated to achieve efficient and accurate project updates. For closed-source projects, the compiled files are directly copied to simplify the operation; for open-source projects, the accuracy and consistency of the versions are ensured through differential file updates, which not only improves the efficiency of synchronization and management, but also enhances the accuracy and consistency of version control.

[0094] As an optional example, the second synchronization module includes:

[0095] An acquisition unit, used for acquiring a new commit identifier of the project to be updated from the first Git repository of the parent code base project;

[0096] The second synchronization unit is used to modify the old submission identifier of the project to be updated recorded in the second Git repository of the project to be updated to the new submission identifier of the project to be updated.

[0097] Optionally, in this embodiment, to synchronize the old commit identifier of the second Git repository in the project to be updated, it is necessary to obtain a new commit identifier and update the old commit identifier to the new commit identifier. Obtaining the new commit identifier and updating the old commit identifier not only maintains the version consistency of the subproject and the parent project, but also simplifies the version control process, reduces the risk of errors, improves the efficiency of development and management, and enhances the traceability and transparency of the project.

[0098] For other examples of this embodiment, please refer to the above examples and will not be repeated here.

[0099] Figure 4 is a schematic diagram of an optional electronic device according to an embodiment of the present application, such as Figure 4 As shown, it includes a processor 402, a communication interface 404, a memory 406 and a communication bus 408, wherein the processor 402, the communication interface 404 and the memory 406 communicate with each other through the communication bus 408, wherein,

[0100] Memory 406, used to store computer programs;

[0101] The processor 402 is used to implement the following steps when executing the computer program stored in the memory 406:

[0102] After the parent code base project is updated, a new commit identifier and an old commit identifier of each child code base project of the parent code base project are obtained, wherein the new commit identifier is recorded in the first Git repository of the parent code base project, and the old commit identifier is recorded in the second Git repository of each child code base project;

[0103] According to the new submission identifier and the old submission identifier of each sub-code base project, at least one project to be updated is determined from all sub-code base projects of the parent code base project;

[0104] Determine the access status of the project to be updated, and synchronize the project to be updated based on the access status and the compiled files of the parent code base project;

[0105] The old submission identifier of the project to be updated is synchronized according to the new submission identifier of the project to be updated.

[0106] Optionally, in this embodiment, the communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The communication interface is used for communication between the above electronic device and other devices.

[0107] The memory may include RAM, or may include non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0108] As an example, the memory 406 may include, but is not limited to, the acquisition module 302, the determination module 304, the first synchronization module 306, and the second synchronization module 308 in the synchronization device of the code library project. In addition, other module units in the synchronization device of the code library project may also be included but are not limited to, which will not be repeated in this example.

[0109] The above-mentioned processor can be a general-purpose processor, which can include but not be limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processing), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0110] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0111] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only. The electronic device implementing the synchronization method of the above code library project may be a module capable of realizing the communication function or a terminal device including the module, etc. The terminal device may be a mobile terminal or a smart terminal. The mobile terminal may be at least one of a mobile phone, a tablet computer, a laptop computer, etc.; the smart terminal may be a terminal including a wireless communication module such as a smart car, a smart watch, a shared bicycle, a smart cabinet, etc.; the module may be a wireless communication module, such as any one of a 2G communication module, a 3G communication module, a 4G communication module, a 5G communication module, and a NB-IOT communication module. Figure 4 The structure of the electronic device is not limited. For example, the electronic device may also include Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 4 Different configurations shown.

[0112] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0113] According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program executes the steps in the synchronization method of the above-mentioned code library project when executed by a processor.

[0114] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0115] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0116] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0117] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0118] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0119] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0120] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0121] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for synchronizing a code base project, characterized in that: include: After the parent code base project is updated, obtain a new submission identifier and an old submission identifier of each child code base project of the parent code base project, wherein the new submission identifier is recorded in the first Git repository of the parent code base project, and the old submission identifier is recorded in the second Git repository of each child code base project; Determine at least one project to be updated from all the sub-code library projects of the parent code library project according to the new submission identifier and the old submission identifier of each of the sub-code library projects; Determine the access status of the project to be updated, and synchronize the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status; According to the new submission identifier of the project to be updated, the old submission identifier of the project to be updated is synchronized.

2. The method according to claim 1, characterized in that Before obtaining the new submission identifier and the old submission identifier of each child code base project of the parent code base project, the method further includes: Compile the parent code base project to obtain the compiled file.

3. The method according to claim 1, characterized in that The obtaining of the new submission identifier and the old submission identifier of each child code base project of the parent code base project comprises: Take each sub-code base project of the parent code base project as the current sub-code base project, and perform the following operations on the current sub-code base project: Obtain a new submission identifier of the current child code base project from the first Git repository of the parent code base project; Obtain an old commit identifier of the current sub-code repository project from the second Git repository of the current sub-code repository project.

4. The method according to claim 1, characterized in that: Determining at least one to-be-updated project from all sub-code repository projects of the parent code repository project according to the new submission identifier and the old submission identifier of each sub-code repository project comprises: Take each sub-code base project of the parent code base project as the current sub-code base project, and perform the following operations on the current sub-code base project: Compare the new commit identifier and the old commit identifier of the current sub-code base project; When the new submission identifier and the old submission identifier of the current sub-code library project are different, determining that the current sub-code library project is a project to be updated; When the new submission identifier and the old submission identifier of the current sub-code library project are the same, it is determined that the current sub-code library project is a project not to be updated.

5. The method according to claim 1, characterized in that: The synchronizing the to-be-updated project according to the access status and the compiled file of the parent code base project includes: When the access status of the project to be updated is a closed source status, the compiled file is copied to the project to be updated.

6. The method according to claim 1, characterized in that The synchronizing the to-be-updated project according to the access status and the compiled file of the parent code base project includes: In a case where the access status of the project to be updated is an open source status, determining a difference file of the project to be updated from the compiled file according to a new submission identifier and an old submission identifier of the project to be updated; The difference file is copied to the project to be updated.

7. The method according to claim 1, characterized in that The synchronizing the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated includes: Obtain a new submission identifier of the project to be updated from the first Git repository of the parent code base project; The old submission identifier of the project to be updated recorded in the second Git repository of the project to be updated is modified to the new submission identifier of the project to be updated.

8. A synchronization device for a code base project, characterized in that: include: An acquisition module, configured to acquire a new submission identifier and an old submission identifier of each child code base project of the parent code base project after the parent code base project is updated, wherein the new submission identifier is recorded in a first Git repository of the parent code base project, and the old submission identifier is recorded in a second Git repository of each child code base project; A determination module, configured to determine at least one project to be updated from all the sub-code library projects of the parent code library project according to the new submission identifier and the old submission identifier of each of the sub-code library projects; A first synchronization module, used to determine the access status of the project to be updated, and synchronize the project to be updated according to the access status and the compiled file of the parent code base project, wherein the access status includes an open source status and a closed source status; The second synchronization module is used to synchronize the old submission identifier of the project to be updated according to the new submission identifier of the project to be updated.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images