Schematic diagram version management method and device, electronic equipment and storage medium

Abstract

The invention discloses a schematic diagram version management method and device, electronic equipment and a storage medium, and belongs to the technical field of schematic diagram version management. According to the technical scheme, a first project file generated based on schematic diagram design is obtained, and the first project file is compared with a pre-stored project file in a historical schematic diagram version; generating a first schematic diagram version number corresponding to the first project file under the condition of determining that content update exists between the first project file and the pre-stored project file; and updating schematic diagram version data stored in the Git warehouse through a Git command based on the first project file and the first schematic diagram version number. According to the invention, the efficiency of managing the schematic diagram version can be improved, and the problem that the schematic diagram version is easy to be disordered is avoided.

Description

Technical Field

[0001] The present application relates to the technical field of schematic version management, and in particular to a schematic version management method, device, electronic device and storage medium. Background Art

[0002] As circuit boards become more complex and the number of designs increases, the importance of schematic version management and version change records is gradually increasing. Convenient and simple version management can help hardware developers quickly find the schematic projects they have developed, quickly view the differences between versions, and perform corresponding permission control and record in project sharing.

[0003] Currently, in the schematic development process, hardware developers mainly transfer schematics by compressing the files and then copying them. Since this method does not standardize version management, there are problems such as low efficiency, easy loss of version files, and uncontrolled permissions, resulting in inefficient version management and confusion of schematic versions. Summary of the invention

[0004] The main purpose of this application is to provide a schematic version management method, device, electronic device and storage medium, aiming to solve the technical problems of inefficient management of schematic versions and easy confusion of schematic versions.

[0005] To achieve the above objectives, the present application provides a schematic version management method, comprising:

[0006] Acquire a first engineering file generated based on the schematic design, and compare the first engineering file with a pre-stored engineering file in a historical schematic version;

[0007] In the case where it is determined that there is a content update between the first engineering file and the pre-stored engineering file, generating a first schematic version number corresponding to the first engineering file;

[0008] Based on the first project file and the first schematic version number, the schematic version data stored in the Git repository is updated through a Git command.

[0009] In addition, to achieve the above purpose, the present application also provides a schematic version management device, including:

[0010] A comparison module, configured to obtain a first engineering file generated based on the schematic design, and compare the first engineering file with a pre-stored engineering file in a historical schematic version;

[0011] A generating module, configured to generate a first schematic version number corresponding to the first engineering file when it is determined that there is a content update between the first engineering file and the pre-stored engineering file;

[0012] The update module is configured to update the schematic version data stored in the Git repository through a Git command based on the first project file and the first schematic version number.

[0013] In addition, to achieve the above-mentioned purpose, the present application also provides an electronic device, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the schematic version management method as described in any of the above items is implemented.

[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a program or instruction is stored, and when the program or instruction is executed by a processor, the schematic diagram version management method as described in any of the above items is implemented.

[0015] The embodiment of the present application provides a schematic diagram version management method, device, electronic device and storage medium. The schematic diagram version management method in the embodiment of the present application is to obtain a first engineering file generated based on the schematic diagram design, compare the first engineering file with the pre-stored engineering file in the historical schematic diagram version; when it is determined that there is a content update between the first engineering file and the pre-stored engineering file, generate a first schematic diagram version number corresponding to the first engineering file; based on the first engineering file and the first schematic diagram version number, update the schematic diagram version data stored in the Git warehouse through the Git command, so that the R&D personnel upload the schematic diagram to the Git warehouse through the version management tool. Relying on the powerful storage function of Git, the embodiment of the present application uses compression and differential transmission technology to reduce the amount of data transmitted. Since Git will compress the file and only transmit the changed part of the file instead of the entire file, this can significantly reduce the amount of data transmission, increase the upload speed, and reduce the risk of information loss. The embodiment of the present application uses the advantages of Git's own storage performance to perform systematic version management on the schematic diagram engineering files designed by the R&D personnel, such as uploading, downloading, rollback and other version management operations through Git commands, which effectively avoids the problems of chaotic schematic versions, unclear version information, and inefficient transmission of R&D personnel.

[0016] The embodiment of the present application builds a Git repository for schematic projects, and refers the management and control method of schematic files to the code management process. Hardware developers can upload, download, roll back, and share based on Git commands. By uniformly managing and controlling the permissions of schematic versions, the problems of schematic version confusion and inefficient transmission are avoided, thereby effectively solving the technical problems of inefficient management of schematic versions and easy confusion of schematic versions. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] 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, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying any creative work.

[0018] Figure 1 A flowchart of a first embodiment of a method for managing schematic diagram versions of this application;

[0019] Figure 2 This is a hardware framework diagram of an integrated platform for schematic version management based on Git in an embodiment of the present application;

[0020] Figure 3 It is a functional module diagram of a schematic version management tool based on Git in one embodiment;

[0021] Figure 4 A flowchart of a schematic diagram upload scenario based on Git in one embodiment;

[0022] Figure 5 A flowchart of a downloading scenario of a schematic diagram version based on Git in one embodiment;

[0023] Figure 6 A flowchart of a standard model project approval scenario based on a Git-based schematic version in one embodiment;

[0024] Figure 7 Adding a scenario flow chart to a standard model of a schematic version based on Git in one embodiment;

[0025] Figure 8 This is a schematic diagram of the functional modules of the management device of the schematic diagram version of the embodiment of the present application;

[0026] Fig. 9 This is a schematic diagram of the hardware structure of the electronic device involved in the embodiment of the present application.

[0027] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0028] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0029] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only 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 creative work are within the scope of protection of this application.

[0030] It should be noted that all directional indications in the embodiments of the present application (such as up, down, left, right, front, back, etc.) are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0031] In this application, unless otherwise clearly specified and limited, the terms "connection", "fixation", etc. should be understood in a broad sense. For example, "fixation" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, it can be the internal connection of two elements or the interaction relationship between two elements, unless otherwise clearly defined. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0032] In addition, in this application, descriptions such as "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in this field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0033] As circuit boards become more complex and the number of designs increases, the importance of schematic version management and version change records is gradually increasing. Convenient and simple version management can help hardware developers quickly find the schematic projects they have developed, quickly view the differences between versions, and perform corresponding permission control and record in project sharing.

[0034] Currently, in the schematic development process, hardware developers mainly transfer schematics by compressing the files and then copying them. Since this method does not standardize version management, there are problems such as low efficiency, easy loss of version files, and uncontrolled permissions, resulting in inefficient version management and confusion of schematic versions.

[0035] Based on this, the present application embodiment provides a schematic diagram version management method, referring to Figure 1 , Figure 1 This is a flow chart of an embodiment of a schematic diagram version management method of the present application. In this embodiment, the schematic diagram version management method includes:

[0036] Step S100, obtaining a first engineering file generated based on the schematic design, and comparing the first engineering file with a pre-stored engineering file in a historical schematic version;

[0037] Exemplarily, the step of obtaining a first engineering file generated based on the schematic design includes:

[0038] Step A10, obtaining a first engineering file generated by performing schematic design based on computer-aided electronic design (ECAD) software.

[0039] In this embodiment, it is known to those skilled in the art that ECAD (Electronic Computer Aided Design) software is a CAD software for power engineering design that can draw schematic diagrams. The software can conveniently draw, calculate and generate primary and secondary drawings of power engineering. Using the software for engineering design can improve the design quality and shorten the design cycle. The software can also optimize the layout of power engineering, thereby providing a basis for scheme optimization.

[0040] The first engineering file may refer to an engineering file obtained by a technician by drawing a schematic diagram based on ECAD software.

[0041] It should be noted that the Git repository may store engineering files corresponding to historical schematic versions previously drawn by historical personnel. The pre-stored engineering files refer to engineering files corresponding to historical schematic versions stored in the Git repository.

[0042] After step S100, step S200 is executed to generate a first schematic version number corresponding to the first engineering file when it is determined that there is a content update between the first engineering file and the pre-stored engineering file;

[0043] In this embodiment, it is understandable that a schematic version number is often associated with a schematic engineering file, and each different schematic version number in the Git repository often corresponds to a different engineering file. That is, each engineering file in the Git repository often has a corresponding schematic version number.

[0044] After step S200, step S300 is executed to update the schematic version data stored in the Git repository through the Git command based on the first project file and the first schematic version number.

[0045] It is known to those skilled in the art that a Git repository can also be called a Git version repository. Git repositories can be divided into local repositories and remote repositories. Local repositories are stored on the machine where the operator is located, and remote repositories are generally stored on servers. Remote repositories can be used to achieve file data sharing, operation control, and tracking between users. Therefore, the version management of schematic engineering files drawn by R&D personnel can be combined with Git to achieve the management and traceability of schematic versions, and to maximize the control of the security, integrity, and consistency of standard model files.

[0046] Exemplarily, the step S300, based on the first project file and the first schematic version number, updating the schematic version data stored in the Git repository through the Git command includes:

[0047] Step B10: generating a first branch storage node corresponding to the first schematic version number in the Git repository based on the first project file;

[0048] Step B20: Store the first project file in the first branch storage node through the Git command to update the schematic version data stored in the Git repository.

[0049] In this embodiment, when the R&D personnel are drawing the schematic diagram, if they need to add a standard template file, they mostly use a manual copy method, which is prone to abnormalities in the added standard template or problems of arbitrary tampering. Based on this pain point, the embodiment of the present application proposes a solution for schematic version management based on Git. Since Git is a distributed version control system, it means that each developer has a complete copy of the code repository, not just a connection to the central server, which allows developers to work offline and also provides better flexibility and security. Git also provides the concept of branches, allowing developers to create independent development lines (branches) and develop without affecting the main line (main branch). Developers can create new branches, switch branches, merge branches, and other operations to carry out parallel development on different tasks and features. Git uses code repositories to store the source code and history of a project. Developers can also create a new code repository locally (local repository) or clone a remote code repository (remote repository). Developers can save changes to the code by committing them, along with detailed descriptions of the changes. This enables unified control of standard model files based on Git, ensures that all hardware R&D personnel use the same source for standard models, and ensures the correctness of adding standard models.

[0050] The embodiment of the present application is based on the first project file, generates a first branch storage node corresponding to the first schematic version number in the Git repository, and stores the first project file to the first branch storage node through the Git command, thereby completing the update of the schematic version data stored in the Git repository, making it easy to implement version management operations such as uploading, downloading, and rolling back the schematic project files drawn by R&D personnel through Git commands.

[0051] The embodiment of the present application provides a schematic diagram version management method, device, electronic device and storage medium. The schematic diagram version management method in the embodiment of the present application is to obtain a first engineering file generated based on the schematic diagram design, compare the first engineering file with the pre-stored engineering file in the historical schematic diagram version; when it is determined that there is a content update between the first engineering file and the pre-stored engineering file, generate a first schematic diagram version number corresponding to the first engineering file; based on the first engineering file and the first schematic diagram version number, update the schematic diagram version data stored in the Git warehouse through the Git command, so that the R&D personnel upload the schematic diagram to the Git warehouse through the version management tool. Relying on the powerful storage function of Git, the embodiment of the present application uses compression and differential transmission technology to reduce the amount of data transmitted. Since Git will compress the file and only transmit the changed part of the file instead of the entire file, this can significantly reduce the amount of data transmission, increase the upload speed, and reduce the risk of information loss. The embodiment of the present application uses the advantages of Git's own storage performance to perform systematic version management on the schematic diagram engineering files designed by the R&D personnel, such as uploading, downloading, rollback and other version management operations through Git commands, which effectively avoids the problems of chaotic schematic versions, unclear version information, and inefficient transmission of R&D personnel.

[0052] The embodiment of the present application builds a Git repository for schematic projects, and refers the management and control method of schematic files to the code management process. Hardware developers can upload, download, roll back, and share based on Git commands. By uniformly managing and controlling the permissions of schematic versions, the problems of schematic version confusion and inefficient transmission are avoided, thereby effectively solving the technical problems of inefficient management of schematic versions and easy confusion of schematic versions.

[0053] It is worth mentioning that the embodiment of the present application also combines Git and ECAD software, utilizes the advantages of Git's own storage performance, and systematically manages the ECAD files of R&D personnel, standardizes the archiving and use process of standard models, and improves the difficulties in finding standard models, inconsistent standard model files, and other problems, thereby improving the accuracy of schematic drawing and R&D efficiency, thereby effectively solving the problems of chaotic schematic versions, unclear version information, inefficient transmission, and uncontrollable permissions of R&D personnel.

[0054] In order to help understand the technical principles or technical concepts of the embodiments of the present application, the schematic version management method of the specific embodiment 1 is listed, and reference is made to Figure 2 , Figure 2 This is a hardware framework diagram of an integrated platform for schematic version management based on Git in an embodiment of the present application.

[0055] Among them, the Git server is deployed in the server cluster, and the version management tool is deployed on the host of the hardware developer, which can be further integrated into the ECAD software. Figure 4 , Figure 4 The following is a flowchart of a schematic diagram version upload scenario based on Git in one embodiment. The specific operation process of the schematic diagram version management method is as follows:

[0056] Step 1: The R&D personnel draw the schematic on the ECAD software and open the version management tool to upload the schematic. The version management tool will determine whether the engineering file of the schematic is uploaded for the first time based on the existing upload records. If it is uploaded for the first time, a four-level warehouse will be established on the Git warehouse according to the corresponding name and the product to which it belongs. The four-level warehouse is named after the schematic number;

[0057] Step 2: The version management tool uploads the schematic to the Git repository through the Git command. The git command will return the corresponding submission record, and will also assign a version number to the current project, associate the version number with the submission record, and store the version information for later query and display;

[0058] Step 3: The R&D personnel continue to develop the schematic diagram and then upload it again through the version management tool;

[0059] Step 4: The version management tool executes the Git command once, and can rely on the version comparison function of git itself to determine whether there are new changes. At the same time, the version management tool will perform a logical comparison of the schematics and engineering design files. When there are new changes, it allows the upload of a new version. This step uses Git's own incremental index and efficient data storage mechanism to store only the changed parts of the file instead of a copy of the entire file, which can reduce storage and transmission costs.

[0060] In this embodiment, the R&D personnel upload the schematic diagram to the Git repository through the version management tool. This process relies on Git's powerful storage function and uses compression and differential transmission technology to reduce the amount of data transmitted. Git will compress the file and only transmit the changed part of the file instead of the entire file, which can significantly reduce the amount of data transmission and increase the upload speed. This process solves the difficulties of R&D personnel having multiple local project versions, confusing versions, and occupying computer memory space.

[0061] It should be noted that although the above-mentioned specific embodiment 1 shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of the present application, and does not constitute a limitation of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0062] In a possible implementation, the step of generating a first branch storage node corresponding to the first schematic version number in a Git repository based on the first project file includes:

[0063] Step C10, compressing the file part with updated content between the first project file and the pre-stored project file and the first schematic version number and uploading them to the target server to trigger the target server to restore the first project file based on the file part and the pre-stored project file, and based on the first project file, generating a first branch storage node corresponding to the first schematic version number in the Git repository on the target server.

[0064] In this embodiment, the target server may be a Gerrit storage server, that is, the Git repository is a remote repository.

[0065] This embodiment compresses the file portion with updated content between the first project file and the pre-stored project file and the first schematic version number and uploads them to the target server to trigger the target server to restore the first project file based on the file portion and the pre-stored project file, and generates a first branch storage node corresponding to the first schematic version number in the Git repository on the target server based on the first project file, so as to facilitate the subsequent storage of the first project file in the first branch storage node through Git commands, and complete the update of the schematic version data stored in the Git repository, so that hardware developers can upload, download, roll back and share based on Git commands, so as to facilitate unified management and authority control of schematic versions and avoid confusion and inefficient transmission of schematic versions.

[0066] In addition, it is worth mentioning that since there is no need for manual configuration in the deployment process, the updated code files or configuration files in the schematic version files can be automatically updated, which greatly reduces manual operations, improves the efficiency of project version release, and reduces operating costs.

[0067] In one practicable manner, the method further comprises:

[0068] Step D10, obtaining viewing information for viewing the schematic diagram version, wherein the viewing information includes the version number of the second schematic diagram required to be viewed;

[0069] Step D20, using a Git command, retrieve the second engineering file corresponding to the second schematic version number from the historical schematic version in the Git repository;

[0070] Step D30: output the second project file to a designated directory of the current user account for display.

[0071] This embodiment obtains viewing information for viewing the schematic version, wherein the viewing information includes the second schematic version number that needs to be viewed, and then uses the Git command to retrieve the second project file corresponding to the second schematic version number from the historical schematic version of the Git repository, and outputs the second project file to the specified directory of the current user account for display, thereby facilitating hardware developers to view previous historical schematic versions based on Git commands and other operations, thereby facilitating unified schematic version management of schematic versions, realizing management and traceability of schematic versions, and maximizing the control of the security, integrity and consistency of standard model files.

[0072] To help understand this embodiment, an exemplary schematic download scenario is listed, referring to Figure 5 , Figure 5 The following is a flowchart of a download scenario of a schematic diagram version based on Git in one embodiment, and the specific process includes:

[0073] Step 1: The developer uses the version management tool to view the previously uploaded historical versions and selects a version to download;

[0074] Step 2: The version management tool obtains the commit record of the specified version, that is, commitid, and then executes the gitclone command to pull the corresponding version file to the specified directory.

[0075] In this embodiment, the developer downloads the specified version through the version management tool. This process helps the developer to view any historical version, so that the developer can see the development process and the corresponding functions of the corresponding version.

[0076] It should be noted that although the schematic diagram download scenario of this embodiment shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of this application, and does not constitute a limitation on this application. More simple transformations based on the technical concept should all be within the scope of protection of this application.

[0077] In a possible implementation, the method further includes:

[0078] Step E10, obtaining loading information for loading the schematic diagram version, wherein the loading information includes the version number of the third schematic diagram required to be loaded;

[0079] Step E20, using a Git command, retrieve the third engineering file corresponding to the third schematic version number from the historical schematic version in the Git repository;

[0080] Step E30, outputting the third project file to the working directory of the current user account for loading and use.

[0081] This embodiment obtains loading information for loading and using the schematic version, wherein the loading information includes the third schematic version number required to be loaded and used, and then uses the Git command to retrieve the third project file corresponding to the third schematic version number from the historical schematic version in the Git repository, and then outputs the third project file to the working directory of the current user account for loading and use, thereby facilitating hardware developers to load and use previous historical schematic versions based on Git commands, thereby ensuring unified schematic version management of schematic versions, realizing the management and traceability of schematic versions, and maximizing the control of the security, integrity and consistency of standard model files.

[0082] To help understand this embodiment, an exemplary standard model adding scenario is listed, referring to Figure 7 , Figure 7 A scenario flow chart is added to a standard model of a schematic version based on Git in an embodiment, and the specific process includes:

[0083] Step 1: The R&D personnel open the version management tool in the ECAD software and use the query function to query all available standard molds in the standard mold library;

[0084] Step 2: The R&D personnel selects the standard model to be used and clicks Add;

[0085] Step 3: The version management tool will pull the specified standard template file from the Git repository to the worklib directory of the local schematic project;

[0086] Step 4: The version management tool issues commands to interact with the ECAD software and displays the standard model graphically on the ECAD software.

[0087] Through the above process, this embodiment effectively controls the problems of confusion of standard model file versions, inconsistency of actual content of the same version, file tampering, etc., and ensures that the standard models used by R&D personnel are generated and added through standardized processes. This standardizes the operation of using standard models and improves the efficiency of schematic drawing.

[0088] When drawing schematic diagrams, R&D personnel can use the standard model files in the standard model library through version management tools. They can directly query, add, and replace archived standard models through the tools, thereby effectively standardizing the use process of the standard model library and standard models, and then relying on Git commands to uniformly manage and operate schematic diagrams and their derivative files, helping hardware R&D personnel solve difficulties such as version confusion, difficulty in finding, and out-of-control permissions.

[0089] It should be noted that although the standard model adding scenario of this embodiment shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of this application, and does not constitute a limitation on this application. More simple transformations based on this technical concept should all be within the scope of protection of this application.

[0090] In a possible implementation, the method further includes:

[0091] Step F10, obtaining authorization information for authorizing the schematic diagram version, the authorization information including the version number of the fourth schematic diagram requiring authorization to view, the authorization item, and the authorized first user account, wherein the authorization item is at least one of authorization to view, authorization to download, authorization to edit, and authorization to load and use;

[0092] Step F20, using the Git command, retrieve the fourth engineering file corresponding to the fourth schematic version number from the historical schematic version of the Git repository, and output the fourth engineering file to the target directory of the first user account for authorization processing.

[0093] This embodiment obtains authorization information for authorizing the schematic version, and the authorization information includes a fourth schematic version number that requires authorization to view, authorization matters, and an authorized first user account, wherein the authorization matter is at least one of authorized viewing, authorized downloading, authorized editing, and authorized loading and use. Then, through the Git command, the fourth project file corresponding to the fourth schematic version number is retrieved from the historical schematic version of the Git repository, and the fourth project file is output to the target directory of the first user account to process the authorization matter, wherein the first user account is different from the current user account, so that permission management can be performed on the schematic project, and permissions such as viewing, downloading, and editing can be granted to others, thereby realizing schematic sharing among team members, thereby ensuring unified management and permission control of schematic versions, realizing management and traceability of schematic versions, and maximizing the control of the security, integrity, and consistency of standard model files.

[0094] To help understand this embodiment, an exemplary schematic version authorization scenario of Git-based schematic version management is listed, and the specific process includes:

[0095] Step 1: The R&D personnel selects a project on the version management tool and grants colleague A the permission to view and download the project;

[0096] Step 2: Colleague A opens the version management tool and can view the authorized schematics in the tool;

[0097] Step 3: Colleague A clicks download;

[0098] Step 4: The version management tool executes the git clone command to download the schematic to the specified directory;

[0099] The above steps can be used to subdivide the permission control of schematic projects to a certain version, that is, to grant permissions to one, several or all versions of the schematic.

[0100] In this embodiment, R&D personnel share the project with others, who can then directly download and view it through version management tools. This process helps hardware R&D personnel solve difficulties such as difficulty in transferring schematics (especially very large files), abnormal loss of transferred files, and loss of control over transferred permissions.

[0101] This embodiment verifies the designer's identity information and operating permissions, thereby ensuring that only specific personnel can modify the schematic file. During the entire creation process of the schematic file, the schematic file information is encrypted and stored, and version information is added. This solves the problems of version confusion, difficulty in tracing, and potential data security risks of the schematic file, and achieves improved accuracy of schematic version management and improved data security while meeting the requirements of collaborative creation by multiple people.

[0102] It should be noted that although the schematic version authorization scenario of this embodiment shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of this application, and does not constitute a limitation on this application. More simple transformations based on the technical concept should all be within the scope of protection of this application.

[0103] In one practicable manner, the method further comprises:

[0104] Step G10, obtaining the pending approval information for reviewing and archiving the schematic diagram version, wherein the pending approval information includes the version number of the fifth schematic diagram to be reviewed and archived;

[0105] Step G20, based on the pending approval information, starting an approval process for the fifth engineering file corresponding to the fifth schematic version number, wherein the node of the approval process includes sending the fifth engineering file to a second user account with approval authority for approval;

[0106] Step G30, after receiving the approval instruction of the fifth engineering file from the second user account with approval authority, the fifth engineering file is packaged to obtain a standard model engineering file;

[0107] Step G40: Generate a second branch storage node corresponding to the fifth schematic version number in the Git repository based on the standard model engineering file.

[0108] Step G50: Store the standard model project file to the second branch storage node through the Git command.

[0109] This embodiment obtains the pending approval information for review and archiving of the schematic diagram version, wherein the pending approval information includes the fifth schematic diagram version number to be reviewed and archived, and then starts the approval process for the fifth engineering file corresponding to the fifth schematic diagram version number based on the pending approval information, wherein the node of the approval process includes sending the fifth engineering file to a second user account with approval authority for approval, and after receiving the approval instruction of the fifth engineering file from the second user account with approval authority, the fifth engineering file is packaged to obtain a standard model engineering file, and then based on the standard model engineering file, a second branch storage node corresponding to the fifth schematic diagram version number is generated in the Git repository, and the standard model engineering file is saved in the Git repository through the Git command. The standard model project files are stored in the second branch storage node, thereby standardizing the archiving and use process of standard models. By submitting the standard model project files for approval, after the approval process, the Jenkins pipeline is executed to package and archive the project, and the final generated standard model files are stored in the branch of the corresponding Git repository, and a corresponding relationship between the project version and the corresponding standard model file version is established, thereby realizing the function of unified management of schematic projects and corresponding derivative files, maximizing the control of the security, integrity and consistency of standard model files, improving the accuracy of schematic drawing and R&D efficiency, and effectively solving the problems of chaotic schematic versions, unclear version information, inefficient transmission and uncontrollable permissions of R&D personnel.

[0110] To help understand this embodiment, an exemplary standard model project approval scenario flow chart is listed, referring to Figure 6 , Figure 6 The following is a flowchart of a standard model project approval scenario based on a schematic version of Git in one embodiment. The specific process includes:

[0111] Step 1: In the version management tool, the developer selects a version that has been uploaded and initiates the approval process for it;

[0112] Step 2: After the approval process is initiated and approved by the first and second approvers, the archive pipeline will be automatically triggered;

[0113] Step 3: The pipeline will obtain the Git storage path of the standard model, pull the standard model project according to the commitid corresponding to the version, and then perform the packaging operation, create a new branch with the standard model version as the branch name, and upload the ECAD standard model file generated after packaging to the corresponding branch. The standard model file is included in the standard model library and can be queried and added by other R&D personnel;

[0114] In this embodiment, the R&D personnel can review and archive the uploaded standard model project in combination with the Jenkins pipeline. This embodiment uses the Git branch management function to allow multiple branches to be developed simultaneously in the same code repository. This allows the engineering files and derivative files of the same schematic to be in the same repository for unified management.

[0115] This embodiment submits the standard model project for approval. After the approval process, the Jenkins pipeline is executed to package and archive the project, and the finally generated standard model file is stored in the branch of the corresponding Git repository, and a corresponding relationship between the project version and the corresponding standard model file version is established, thereby realizing the function of unified management of schematic projects and corresponding derivative files.

[0116] It should be noted that although the standard model engineering approval scenario of this embodiment shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of this application, and does not constitute a limitation on this application. More simple transformations based on this technical concept should all be within the scope of protection of this application.

[0117] In a possible implementation, the method further includes:

[0118] Step H10, obtaining rollback information for rolling back the schematic diagram version, wherein the rollback information includes the sixth schematic diagram version number after the rollback;

[0119] Step H20, using a Git command, retrieve the sixth engineering file corresponding to the sixth schematic version number from the historical schematic version in the Git repository;

[0120] Step H30, based on the sixth project file, roll back the current schematic version loaded by the current user account to the sixth schematic version number.

[0121] This embodiment obtains rollback information for rolling back the schematic version, wherein the rollback information includes the sixth schematic version number after the rollback, and then uses the Git command to retrieve the sixth project file corresponding to the sixth schematic version number from the historical schematic version of the Git repository, and then based on the sixth project file, rolls back the current schematic version loaded by the current user account to the sixth schematic version number, thereby facilitating hardware developers to perform version rollback and other operations on previous historical schematic versions based on the Git command, and then perform unified schematic version management on the schematic versions, thereby realizing the management and traceability of the schematic versions, and maximizing the control of the security, integrity and consistency of the standard model files.

[0122] To help understand this embodiment, an exemplary version rollback scenario is listed, and the specific process includes:

[0123] Step 1: The developer uses the version management tool to view the historical versions uploaded previously and selects a version to roll back;

[0124] In the above steps, the version project information, project measurement information and Git storage information will be stored during uploading, and the version information and other valid information will be associated.

[0125] Step 2: The version management tool obtains the commit record of the specified version, that is, commitid, and then executes the command gitreset--hard+commitid;

[0126] R&D personnel can roll back the version to the specified version through the version management tool. This process helps R&D personnel to roll back the historical version at will, making the R&D process more flexible and allowing them to continue to develop new versions based on any version.

[0127] It should be noted that although the version rollback scenario of this embodiment shows many details, it is only used to help understand the technical concept or technical principle of the embodiment of this application, and does not constitute a limitation on this application. More simple transformations based on this technical concept should all be within the scope of protection of this application.

[0128] In order to further help understand the technical concept or technical principle of the embodiments of the present application, a specific embodiment 2 is listed:

[0129] In this embodiment, by combining Git and ECAD software, referring to the application scenarios of Git in code management, and taking advantage of Git's own storage performance, the ECAD files of R&D personnel are systematically managed.

[0130] Scenario 1:

[0131] Take the example of the first submission record by a developer for a schematic project named module1 after editing it in the ECAD software.

[0132] Step 1a: The R&D personnel submit the schematic diagram of module1 in the version management tool and edit the engineering information corresponding to the version, such as the product, board manager, department, etc. The version management tool generates a submission version number A.1.1 for this submission based on the submission record;

[0133] Step 1b: Use the version management tool to create a repository in the Git repository, name the product as the third-level library, name the schematic as the fourth-level library, create a new library zte_schematic / wireline / CPE / module1, and create a master branch;

[0134] Step 1c: The version management tool pushes the schematic project to the remote Git repository through the git command. And stores the returned commit id: 22047df95bfe657165ea4eeca907ba51f94e1491.

[0135] The above completes the submission task of the first version.

[0136] Scenario 2:

[0137] For example, a developer submits a change to a schematic project named module1 after re-editing it in Cadence software.

[0138] Step 2a: The R&D personnel submit the schematic diagram of module 1 in the version management tool and edit the project information corresponding to the version; the version management tool generates the submitted version number according to the existing submission records and version number generation rules, such as A.1.2;

[0139] Step 2b: The version management tool executes the git command again to submit the new schematic to the master branch of the Git repository. The command also returns the commit id:

[0140] 969ac7496eff9c8ccccd47c08fe340e5341fb300.

[0141] In this embodiment, this step relies on the .git file already in the project directory. The project directory is managed by Git and can be operated directly with Git commands. Git's own storage management only submits file change records instead of submitting the entire disk each time, so the efficiency is very high for non-first submissions;

[0142] Scenario 3:

[0143] Take the example of R&D personnel sharing their own schematic engineering drawings with others.

[0144] Step 3a: R&D staff A selects his own project in the version management tool and grants colleague B the permission to view and download all versions of the project;

[0145] Step 3b: Colleague B can see the schematic diagram shared by A on the version management tool, and can view the basic information of the project and all historical versions;

[0146] Step 3c: Colleague B downloads a version of the schematic;

[0147] Step 3d: The version management tool executes the git clone command to download the schematic to the specified directory.

[0148] Scenario 4:

[0149] For example, R&D personnel approve and archive version A.1.1 of the standard model project.

[0150] Step 4a: R&D personnel submit the standard model project to the corresponding Git repository zte_schematic / wireline / CPE / module1 through the version management tool;

[0151] Step 4b: The R&D personnel trigger the packaging pipeline, which pulls the schematic project from the corresponding Git repository to the server and packages it according to the preset schematic packaging parameters. After the schematic project is packaged, a new version A.1.1p is generated, and the pipeline pushes version A.1.1p to the master branch of the Git repository zte_schematic / wireline / CPE / module1. This step relies on the feature of Git itself that supports multi-person collaborative development;

[0152] Step 4c: The R&D personnel edit the review information of A.1.1p in the version management tool, such as the research institute to which the standard model belongs, the technical field, the main code, etc., and click OK to trigger the review process;

[0153] Step 4d: The review process will be approved by the first and second approvers. Once approved, the archiving pipeline will be automatically triggered. The archiving pipeline pulls the A.1.1p project from the zte_schematic / wireline / CPE / module1 in the Git repository, and then performs the archive operation, which will generate the corresponding derivative standard model file. The version management tool records the version as A.1 according to the version rules. The archiving pipeline creates a new branch named A.1 in the Git repository zte_schematic / wireline / CPE / module1 and pushes the standard model derivative file A.1 to the A.1 branch.

[0154] This step effectively utilizes the branch management feature of Git, allowing multiple people to collaborate on the development and design of the same project, and to establish branches for management.

[0155] Scene 5:

[0156] Take the standard model generated in Example 4 used by R&D personnel as an example.

[0157] Step 5a: When drawing the schematic diagram yuanlitu2, the R&D personnel need to add a standard module named module1;

[0158] Step 5b: The R&D personnel use the version management tool to search for available standard models based on the name module1. The search results show that the current standard model of module1 has three versions: A.1, A.2, and A.3.

[0159] Step 5c: The developer reviews the information of each version and decides to add version A.3.

[0160] Step 5d: The version management tool pulls the content in branch A.3 of the zte_schematic / wireline / CPE / module1 repository to the worklib of the local project yuanlitu2, and issues ECAD interaction commands;

[0161] Step 5e: A.3 of standard module1 is successfully added to schematic yuanlitu2.

[0162] This embodiment uses a self-developed version management tool software to integrate the tool with ECAD software (Electronic Computer Aided Design). Figure 3 , Figure 3 The figure is a functional module diagram of a schematic version management tool based on Git in one embodiment. The tool has the following four functional modules:

[0163] 1. The engineering files generated by ECAD software can be uploaded, downloaded, rolled back and other version management operations through Git commands;

[0164] Second, you can manage the permissions of schematic projects and grant others permissions such as viewing, downloading, and editing, so that schematics can be shared among team members;

[0165] 3. For standard model projects, the standard model projects can be submitted for approval. After the approval process, the Jenkins pipeline is executed to package and archive the project, and the final generated standard model file is stored in the branch of the corresponding Git repository, and a corresponding relationship between the project version and the corresponding standard model file version is established, thereby realizing the unified management of schematic projects and corresponding derivative files.

[0166] Fourth, in the schematic drawing, the archived standard models can be directly queried, added, and replaced through the tool, thus effectively standardizing the standard model library and the use process of standard models. The above four parts rely on Git commands to uniformly manage and operate schematics and their derivative files, helping hardware R&D personnel solve difficulties such as version confusion, difficulty in finding, and loss of authority control.

[0167] This embodiment combines Git and ECAD software and utilizes the storage performance advantages of Git itself to systematically manage the ECAD files of R&D personnel, effectively solving the problems of chaotic schematic versions, unclear version information, inefficient transmission, and uncontrollable permissions of R&D personnel, and standardizing the archiving and use process of standard models, improving the difficulty in finding standard models, inconsistent standard model files, and other problems, thereby improving the accuracy of schematic drawing and R&D efficiency.

[0168] It should be noted that what is disclosed above are only several specific implementation scenarios applied in the embodiments of the present application. Of course, this cannot be used to limit the protection scope of the present application. Ordinary technicians in this field can understand that all or part of the processes of implementing the above embodiments and the equivalent changes made in accordance with the claims of the present invention are still within the scope covered by the present application.

[0169] That is to say, the above-mentioned specific embodiment 2 is only used to help understand the technical concept or technical principle of the embodiment of the present application, and does not constitute a limitation of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0170] In addition, the present application embodiment also proposes a schematic diagram version management device, referring to Figure 8 , Figure 8 This is a schematic diagram of the functional modules of the management device of the schematic diagram version of an embodiment of the present application.

[0171] In this embodiment, the schematic diagram version management device includes:

[0172] A comparison module 10 is configured to obtain a first engineering file generated based on the schematic design, and compare the first engineering file with a pre-stored engineering file in a historical schematic version;

[0173] A generating module 20, configured to generate a first schematic version number corresponding to the first engineering file when it is determined that there is a content update between the first engineering file and the pre-stored engineering file;

[0174] The updating module 30 is configured to update the schematic version data stored in the Git repository through a Git command based on the first project file and the first schematic version number.

[0175] In some embodiments, the update module 30 is further configured to:

[0176] Based on the first project file, generate a first branch storage node corresponding to the first schematic version number in the Git repository;

[0177] The first project file is stored in the first branch storage node through the Git command to update the schematic version data stored in the Git repository.

[0178] In some embodiments, the update module 30 is further configured to:

[0179] The file portion with updated content between the first project file and the pre-stored project file and the first schematic diagram version number are compressed and uploaded to the target server to trigger the target server to restore the first project file based on the file portion and the pre-stored project file, and based on the first project file, generate a first branch storage node corresponding to the first schematic diagram version number in the Git repository on the target server.

[0180] In some embodiments, the schematic version management device further includes a viewing module (not shown), and the viewing module is configured to:

[0181] Obtaining viewing information for viewing a schematic diagram version, wherein the viewing information includes a version number of a second schematic diagram required to be viewed;

[0182] Retrieving the second engineering file corresponding to the second schematic version number from the historical schematic version in the Git repository through a Git command;

[0183] The second project file is output to a designated directory of the current user account for display.

[0184] In some embodiments, the schematic version management device further includes a loading module (not shown), and the loading module is configured to:

[0185] Obtaining loading information for loading the schematic diagram version, wherein the loading information includes a third schematic diagram version number required to be loaded;

[0186] Retrieving the third engineering file corresponding to the third schematic version number from the historical schematic version in the Git repository through a Git command;

[0187] The third project file is exported to the working directory of the current user account for loading and use.

[0188] In some embodiments, the schematic version management device further includes an authorization module (not shown), and the authorization module is further configured to:

[0189] Obtaining authorization information for authorizing the schematic version, the authorization information including a fourth schematic version number for which authorization to view is required, an authorization item, and an authorized first user account, wherein the authorization item is at least one of authorization to view, authorization to download, authorization to edit, and authorization to load and use;

[0190] Through the Git command, the fourth project file corresponding to the fourth schematic version number is retrieved from the historical schematic version of the Git repository, and the fourth project file is output to the target directory of the first user account for processing authorization matters, wherein the first user account is different from the current user account.

[0191] In some embodiments, the schematic diagram version management device further includes an audit and filing module (not shown), and the audit and filing module is configured to:

[0192] Acquire the pending approval information for reviewing and archiving the schematic diagram version, wherein the pending approval information includes the version number of the fifth schematic diagram to be reviewed and archived;

[0193] Based on the pending approval information, starting an approval process for a fifth engineering file corresponding to the fifth schematic version number, wherein a node of the approval process includes sending the fifth engineering file to a second user account with approval authority for approval;

[0194] After receiving an approval instruction of the fifth engineering file from the second user account with approval authority, the fifth engineering file is packaged to obtain a standard model engineering file;

[0195] Based on the standard model engineering file, generate a second branch storage node corresponding to the fifth schematic version number in the Git repository

[0196] The standard model project file is stored in the second branch storage node through the Git command.

[0197] In some embodiments, the schematic version management device further includes a rollback module (not shown), and the rollback module is configured to:

[0198] Obtain rollback information for rolling back the schematic diagram version, wherein the rollback information includes a sixth schematic diagram version number after the rollback;

[0199] Retrieving the sixth engineering file corresponding to the sixth schematic version number from the historical schematic version in the Git repository through the Git command;

[0200] Based on the sixth project file, the current schematic version loaded by the current user account is rolled back to the sixth schematic version number.

[0201] In some embodiments, the comparison module 10 is further configured to:

[0202] A first engineering file generated by performing schematic design based on computer-aided electronic design (ECAD) software is obtained.

[0203] The schematic version management device provided in this embodiment and the schematic version management method provided in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be found in the embodiment of the schematic version management method above. This embodiment has the same beneficial effects as the embodiments of the schematic version management method, which will not be repeated here.

[0204] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0205] In addition, the present application also provides an electronic device, referring to Fig. 9 , Fig. 9 The hardware structure diagram of an electronic device provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the electronic device may include: a processor 1001, a communication bus 1002, a user interface 1003, a network interface 1004 and a memory 1005. Among them, the processor 1001 may be a central processing unit (CPU). The communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a wireless fidelity (WIreless-FIdelity, WI-FI) interface). The memory 1005 may be a high-speed random access memory (Random Access Memory, RAM), or a stable non-volatile memory (Non-Volatile Memory, NVM), such as a disk storage. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0206] Those skilled in the art will understand that Fig. 9 The structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. Fig. 9 As shown, the memory 1005 as a storage medium may include an operating system, a data storage module, a network communication module, a user interface module, and a schematic version management program.

[0207] exist Fig. 9In the electronic device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in this embodiment can be set in the electronic device, and the electronic device calls the schematic version management program stored in the memory 1005 through the processor 1001, and executes the management method applied to the schematic version provided in any of the above embodiments.

[0208] The device proposed in this embodiment and the management method applied to schematic diagram versions proposed in the above embodiment belong to the same inventive concept. The technical details not fully described in this embodiment can be referred to any of the above embodiments, and this embodiment has the same beneficial effects as the management method for executing schematic diagram versions.

[0209] In addition, an embodiment of the present application also proposes a computer-readable storage medium, which may be a non-volatile computer-readable storage medium, on which a schematic version management program is stored, and when the schematic version management program is executed by a processor, the schematic version management method of the present application as described above is implemented.

[0210] The various embodiments of the electronic device and computer-readable storage medium of the present application may refer to the various embodiments of the management method of the schematic diagram version of the present application, which will not be repeated here.

[0211] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

[0212] 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.

[0213] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for an electronic device to execute the methods described in each embodiment of the present application.

[0214] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A schematic diagram version management method, characterized in that: include: Acquire a first engineering file generated based on the schematic design, and compare the first engineering file with a pre-stored engineering file in a historical schematic version; In the case where it is determined that there is a content update between the first engineering file and the pre-stored engineering file, generating a first schematic version number corresponding to the first engineering file; Based on the first project file and the first schematic version number, the schematic version data stored in the Git repository is updated through a Git command.

2. The schematic diagram version management method according to claim 1, characterized in that: The step of updating the schematic version data stored in the Git repository through the Git command based on the first project file and the first schematic version number includes: Based on the first project file, generate a first branch storage node corresponding to the first schematic version number in the Git repository; The first project file is stored in the first branch storage node through the Git command to update the schematic version data stored in the Git repository.

3. The schematic diagram version management method according to claim 2, characterized in that: The step of generating a first branch storage node corresponding to the first schematic version number in the Git repository based on the first project file includes: The file portion with updated content between the first project file and the pre-stored project file and the first schematic diagram version number are compressed and uploaded to the target server to trigger the target server to restore the first project file based on the file portion and the pre-stored project file, and based on the first project file, generate a first branch storage node corresponding to the first schematic diagram version number in the Git repository on the target server.

4. The schematic diagram version management method according to claim 1, characterized in that: The method further comprises: Obtaining viewing information for viewing a schematic diagram version, wherein the viewing information includes a version number of a second schematic diagram required to be viewed; Retrieving the second engineering file corresponding to the second schematic version number from the historical schematic version in the Git repository through a Git command; The second project file is output to a designated directory of the current user account for display.

5. The schematic diagram version management method according to claim 1, characterized in that: The method further comprises: Obtaining loading information for loading the schematic diagram version, wherein the loading information includes a third schematic diagram version number required to be loaded; Retrieving the third engineering file corresponding to the third schematic version number from the historical schematic version in the Git repository through a Git command; The third project file is exported to the working directory of the current user account for loading and use.

6. The schematic diagram version management method according to claim 1, characterized in that: The method further comprises: Obtaining authorization information for authorizing the schematic version, the authorization information including a fourth schematic version number for which authorization to view is required, an authorization item, and an authorized first user account, wherein the authorization item is at least one of authorization to view, authorization to download, authorization to edit, and authorization to load and use; Through the Git command, the fourth engineering file corresponding to the fourth schematic version number is retrieved from the historical schematic version of the Git repository, and the fourth engineering file is output to the target directory of the first user account for processing authorization matters.

7. The schematic diagram version management method according to claim 1, characterized in that: The method further comprises: Acquire the pending approval information for reviewing and archiving the schematic diagram version, wherein the pending approval information includes the version number of the fifth schematic diagram to be reviewed and archived; Based on the pending approval information, starting an approval process for a fifth engineering file corresponding to the fifth schematic version number, wherein a node of the approval process includes sending the fifth engineering file to a second user account with approval authority for approval; After receiving an approval instruction of the fifth engineering file from the second user account with approval authority, the fifth engineering file is packaged to obtain a standard model engineering file; Based on the standard model engineering file, generate a second branch storage node corresponding to the fifth schematic version number in the Git repository The standard model project file is stored in the second branch storage node through the Git command.

8. The schematic diagram version management method according to claim 1, characterized in that: The method further comprises: Obtain rollback information for rolling back the schematic diagram version, wherein the rollback information includes a sixth schematic diagram version number after the rollback; Retrieving the sixth engineering file corresponding to the sixth schematic version number from the historical schematic version in the Git repository through the Git command; Based on the sixth project file, the current schematic version loaded by the current user account is rolled back to the sixth schematic version number.

9. The schematic diagram version management method according to any one of claims 1 to 8, characterized in that: The step of obtaining a first engineering file generated based on the schematic design includes: A first engineering file generated by performing schematic design based on computer-aided electronic design (ECAD) software is obtained.

10. A schematic diagram version management device, characterized in that: include: A comparison module, configured to obtain a first engineering file generated based on the schematic design, and compare the first engineering file with a pre-stored engineering file in a historical schematic version; A generating module, configured to generate a first schematic version number corresponding to the first engineering file when it is determined that there is a content update between the first engineering file and the pre-stored engineering file; The update module is configured to update the schematic version data stored in the Git repository through a Git command based on the first project file and the first schematic version number.

11. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores a program or instruction that can be run on the processor, and when the program or instruction is executed by the processor, the schematic diagram version management method according to any one of claims 1 to 9 is implemented.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the schematic diagram version management method according to any one of claims 1 to 9 is implemented.

Images