CN114780138B

CN114780138B - Flow field simulation software code version management method and device and storage medium

Info

Publication number: CN114780138B
Application number: CN202210683562.5A
Authority: CN
Inventors: 何磊; 赵钟; 赖相成; 何先耀; 万云博; 曾志春; 武文军
Original assignee: Computational Aerodynamics Institute of China Aerodynamics Research and Development Center
Current assignee: Computational Aerodynamics Institute of China Aerodynamics Research and Development Center
Priority date: 2022-06-17
Filing date: 2022-06-17
Publication date: 2022-09-02
Anticipated expiration: 2042-06-17
Also published as: CN114780138A

Abstract

The application relates to a flow field simulation software code version management method, which comprises the following steps: acquiring code updating operation of at least one Git project in the CFD software; determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node; the code updating record comprises a developer identifier, updating time, a node identifier of a child node and a node identifier of a father node of the child node; synchronizing the code updating records to a database, initiating a detection application signal to a server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, and determining the CFD version number based on the code updating track.

Description

Flow field simulation software code version management method and device and storage medium

Technical Field

The application relates to the technical field of fluid mechanics calculation, in particular to a flow field simulation software code version management method, a flow field simulation software code version management device and a storage medium.

Background

Computational Fluid Dynamics (CFD) software is a simulation software for Computational Fluid Dynamics that enables engineers and analysts to predict the behavior of liquids and gases in an intelligent manner. With the requirements on the simulation precision and efficiency being higher and higher, the functions and the code amount of the CFD software are also larger and larger, and the iteration frequency of the software version is higher and higher, so that the expandability and the maintainability of the CFD software are realized. In order to solve the above problems, an automated testing system having functions of code version management, code audit validation, example parallel testing, and the like is usually integrated in the development process of a large CFD software project, so as to ensure the research and development efficiency and flexibility of CFD software. The software version control function can record and manage the content of the file or the file set and the change of the content along with the time, so that the problems of version synchronization and development and communication among different developers are effectively solved, and the efficiency of multi-user collaborative development is improved.

Currently, a distributed code version control system commonly used in CFD software is a Git system. The Git system stores all data contents including the whole version control library on each local computer, supports off-line work, and is widely applied to many projects. However, in the development of CFD software based on Git, each functional module is used as a Git item to perform code management, and the Git item uses a hash value as a CFD software version identifier, and since the hash value itself is a string of long and unordered numbers or characters, there are problems that it is not easy to identify and the version order cannot be determined, which is not favorable for the test and backtracking search of the version problem. This problem is even more pronounced in the case where CFD software code is managed by multiple Git projects.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a method and an apparatus for managing a version of a software code for flow field simulation, a computer device, and a storage medium.

A flow field simulation software code version management method comprises the following steps:

acquiring code updating operation of at least one Git project in the CFD software;

determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node; the code updating record comprises a developer identifier, updating time, a node identifier of a child node and a node identifier of a father node of the child node;

synchronizing the code updating records to a database, initiating a detection application signal to a server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers who update codes in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, adding each code updating record in the code updating track to a list to be numbered, and combining Git projects in the list to be numbered according to the updating time and the developer identifications to obtain the CFD version number of each combination.

In one embodiment, the method further comprises: establishing a Git project for each functional module in the CFD software; establishing a development branch of each Git project; the development branches comprise a main branch and an individual branch corresponding to each developer responsible for developing the Git project; the obtaining of the code update operation on at least one Git project in the CFD software comprises the following steps: and acquiring the code updating operation of the current personal branch on the corresponding Git item in the CFD software.

In one embodiment, the determining the modified Git item as a child node according to the code update operation and generating a code update record of the child node includes: when the code updating operation is a code submitting operation, determining the latest code submitted based on the current personal branch as a child node, and determining the code submitted last time based on the current personal branch as a parent node; when the code updating operation is a first merging operation, determining a latest code based on the current personal branch as a first father node, determining a latest code in a main branch corresponding to the current personal branch as a second father node, merging the second father node to the current personal branch, and merging the first father node and the second father node at the current personal branch to obtain a child node; when the code updating operation is a second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the main branch corresponding to the current personal branch, determining the latest code in the main branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the main branch to obtain a child node.

In one embodiment, the method further comprises: when the code updating operation is a second merging operation, detecting whether a first father node on a current personal branch pointed by the second merging operation has completed a first merging operation; if not, prompting to execute the first merging operation; and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

In one embodiment, the code update record further comprises an update log; determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node, further comprising: when the code updating operation relates to a plurality of Git projects at one time, generating a code updating record corresponding to each Git project based on the same updating log; the combining the Git items in the list to be numbered according to the updating time and the developer identification to obtain the CFD version number of each combination comprises the following steps: the server detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the list to be numbered according to the updating time; and combining the Git item related to each code updating record in the list to be numbered and other Git items of corresponding updating time according to the sequence, and sequentially determining the CFD version number of each combination.

In one embodiment, the initiating a detection application signal to the server includes: and when the developer sequentially executes the code submitting operation, the first merging operation and the second merging operation based on the modified codes in the current round, the developer initiates a detection application signal to the server.

In one embodiment, the tracing a code update trajectory of each developer in the current numbering cycle according to the node identifier includes: the server side inquires the node identification of each Git project contained in the CFD software in the last CFD version number generated in the last numbering period as a historical node identification; and tracing the father node from the inquired child node of the first code updating record in the current numbering cycle, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is the historical node identifier, and generating a code updating track of the corresponding developer based on the traced plurality of code updating records.

A flow field simulation software code version management apparatus, the apparatus comprising:

the code updating operation module is used for acquiring code updating operation on at least one Git project in the CFD software;

the code updating record module is used for determining the modified Git project as a child node according to the code updating operation and generating a code updating record of the child node; the code updating record comprises a developer identifier, updating time, a node identifier of a child node and a node identifier of a father node of the child node;

and the code version numbering module is used for synchronizing the code updating records to a database, initiating a detection application signal to a server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, adding each code updating record in the code updating track to a list to be numbered, and combining Git projects in the list to be numbered according to the updating time and the developer identifications to obtain the CFD version number of each combination.

A computer device comprising a memory storing a computer program and a processor implementing the following steps when the computer program is executed:

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:

acquiring code updating operation of at least one Git project in CFD software;

The flow field simulation software code version management method, the flow field simulation software code version management device, the flow field simulation software code version management computer equipment and the storage medium are based on the distributed version control system Git, code updating records of multiple Git projects are scanned, unnumbered code updating records are identified to enter a list to be numbered, Git project combination is carried out in the list to be numbered according to single code updating operation of a developer, and ranking is carried out according to updating time recorded in Git project combination, so that the numbering sequence of the Git projects is determined, the software versions are numbered according to the precedence sequence of the developer under the condition that the multiple Git projects are updated, and backtracking search for identifying version labels and version problems is facilitated. In addition, compared with the traditional method of synchronously numbering versions while updating codes, the method and the system have the advantages that the same developer often has the problem that the numbering sequence is disordered or updating is omitted due to inconsistent submission time of a plurality of projects or faults of the server side, the codes are numbered in an asynchronous mode, namely, the code updating records are temporarily stored in the database, only when the numbering period is reached, the server side starts scanning from the hash value of the last version number record of the Git project, all unnumbered records in the database are recorded into a list to be numbered, and screening and combination numbering are uniformly carried out, so that the numbering is fundamentally ensured not to be disordered, each updating cannot be omitted, and the fault tolerance rate of the version numbers is improved.

Drawings

FIG. 1 is a diagram of an application environment of a method for managing a software code version for flow field simulation in an embodiment.

Fig. 2 is a flowchart illustrating a method for managing a software code version of a flow field simulation in an embodiment.

FIG. 3 is a diagram that illustrates the process of developer A1 performing a code update, in one embodiment.

FIG. 4 is a diagram illustrating the process of developer A1 in one embodiment for code update tracetrace during the current numbering cycle.

Fig. 5 is a schematic diagram illustrating a process of CFD software version numbering based on a code update record in a to-be-numbered list in one embodiment.

Fig. 6 is a schematic structural diagram of a flow field simulation software code version management device in one embodiment.

FIG. 7 is a diagram illustrating an internal structure of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad application.

For the development and compilation work of the source code, a plurality of developers usually develop the source code locally respectively so as to complete the development work of the source code together by division of labor and cooperation; after the development work of the source code is completely finished, merging and compiling the source code written by a plurality of developers to determine whether the merged source code has conflict or not. The application provides a code version management method suitable for flow field simulation software code development, which can be applied to an application environment shown in fig. 1. The terminal 102 and the server 104 communicate with each other through a network. The terminal 102 may be a terminal used by each developer, and specifically may be various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers.

In an embodiment, as shown in fig. 2, a method for managing a software code version of a flow field simulation is provided, which is described by taking the method as an example applied to the terminal in fig. 1, and includes the following steps:

step 202, obtaining a code update operation for at least one Git project in the CFD software.

CFD software is developed based on Git, and unlike general projects, CFD software has a demand for modular development, and performs code management using each functional module as one Git project.

In one embodiment, before obtaining a code update operation for at least one Git project in the CFD software, the method for managing the code version of the flow field simulation software provided by the present application further includes: establishing a development branch of each Git project; the development branches include a backbone branch and a corresponding individual branch for each developer responsible for developing the Git project.

Before the CFD software development is carried out, a developer firstly carries out configuration management on a CFD software development project at a terminal. Specifically, according to the requirements of CFD software function module authority management and compiling configuration management, the terminal divides CFD software into a plurality of Git projects according to the function modules. The terminal establishes a development branch for each Git project. Development branches include two types of branches: a trunk branch and a personal branch. The individual branches correspond to each developer one by one and are used for CFD software function development. Because the CFD software developer develops CFD software with relatively stable functions and a generally long development period, the individual branches extend through the whole CFD software development period, and the trunk branch is used for integrating functional codes which have a certain degree of maturity and pass the test in the individual branches. Each developer develops on a personal branch belonging only to himself. For example, CFD software includes Git project A, Git project B and Git project C. The Git project A is responsible for three developers A1, A2 and A3, and the development branches of the Git project comprise a main branch A, an individual branch A1, an individual branch A2 and an individual branch A3.

When a plurality of developers write source codes completely and then carry out merging and compiling, the problem of source code conflict is easily caused, because the source codes are more and the problem of exposure in the later development stage is more, the development difficulty is higher; moreover, when there is a source code conflict problem, developers need to review all written source codes for modification, and then perform merging and compiling again based on the modified source codes, which causes difficulty in problem troubleshooting and a long development period. To solve the problem, a corresponding individual branch is established for each developer. After completing code updating, each developer firstly performs code updating operation based on the corresponding personal branch, and uploads the updated code to the trunk branch until no code conflict exists.

Step 204, determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node; the code update record includes a developer identification, an update time, a node identification of a child node, and a node identification of a parent node of the child node.

In one embodiment, determining the modified Git item as a child node according to the code update operation, generating a code update record for the child node, comprising: when the code updating operation is a code submitting operation, determining the latest code submitted based on the current personal branch as a child node, and determining the code submitted last time based on the current personal branch as a parent node; when the code updating operation is a first merging operation, determining a latest code based on a current personal branch as a first father node, determining a latest code in a main branch corresponding to the current personal branch as a second father node, merging the second father node into the current personal branch, and merging the first father node and the second father node in the current personal branch to obtain a child node; when the code updating operation is the second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the trunk branch corresponding to the current personal branch, determining the latest code in the trunk branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the trunk branch to obtain a child node.

In the CFD software development process, the code updating operation of a developer in the personal branch of the developer comprises three operation types: a code commit operation, a first merge operation, and a second merge operation. The code submitting operation refers to an operation of submitting the modified and updated code to a personal branch by a developer. The code submission is an important part of the daily development of CFD software, and each developer submits at least one to two times every day on the basis of completing a small functional module or a function, so that the version positioning and searching of the problem are facilitated. The first merge operation refers to merging the Git item code in the trunk branch into the personal branch. Usually, in the case of updating the trunk branch, the developer needs to perform the first merge operation as soon as possible to find out as soon as possible whether the code segment that is responsible for development conflicts with other code segments that are currently up-to-date. The second merge operation refers to merging the Git item code of the personal branch into the backbone branch. When a certain function of the personal branch reaches a certain maturity, the second merging operation can be executed after the system test is passed.

Fig. 3 shows a process diagram of code update by developer a 1. As shown in FIG. 2, when developer A1 submits the code of the updated Git project A in its personal branch (i.e., performs a code submission operation), the terminal determines the latest code h2 submitted based on the current personal branch A1 as the child node and the last code h1 submitted based on the current personal branch A1 as the parent node. When the developer a1 merges the code of the Git item a in the trunk branch a into the individual branch a1 (i.e., performs the first merge operation), the terminal determines the latest code h2 in the current individual branch a1 as the first parent node, determines the latest code h6 in the trunk branch a corresponding to the current individual branch a1 as the second parent node, merges the second parent node h6 into the current individual branch a1, and merges the first parent node h2 and the second parent node h6 at the current individual branch a1 to obtain the child node h 3. It is easy to understand that h3 is a code segment for updating h2 when there is a conflict after h2 and h6 are merged. When the developer a1 merges the latest code h3 of the current personal branch a1 to the trunk branch a (i.e., performs the second merge operation), the terminal determines the latest code h3 in the current personal branch a1 as the first parent node and determines the latest code h6 in the trunk branch a as the second parent node, and merges the first parent node h3 and the second parent node h6 at the trunk branch a to obtain the child node h 7.

In one embodiment, the trunk branches of different Git projects are only used for storing code segments corresponding to Git projects, and the first merging operation is to merge code segments on the trunk branches of all the Git projects corresponding to CFD software into one person branch. In another embodiment, the trunk branches of different Git projects are used to store all code segments of the CFD software, or each Git project shares a trunk branch, and the first merge operation is to merge the code segments on the trunk branches of the current Git project into one of the personal branches.

In a preferred embodiment, the method for managing the version of the flow field simulation software code provided by the present application further includes: when the code updating operation is a second merging operation, detecting whether a father node on a current personal branch pointed by the second merging operation has completed the first merging operation; if not, prompting to execute a first merging operation; and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

In this embodiment, the first merging operation needs to be completed first before the second merging operation is performed, that is, the merging of the trunk branch to the personal branch needs to be performed first before the merging of the personal branch to the trunk branch. In other words, completing a complete code update round requires performing the code commit operation, the first merge operation and the second merge operation for the newly updated code segments in sequence, and the second merge operation is allowed to be performed for the newly updated code segments only if there is no conflict between the code segments resulting from the first merge operation. It is easy to understand that the first merge operation and the second merge operation are both referred to as incremental merge. In the embodiment, the conflict is limited to be solved in individual branches, so that the probability of conflict after all code segments are subsequently solved is reduced, and the code defect checking is facilitated.

When the developer completes each code updating operation, the terminal generates a corresponding code updating record. The code update record includes a developer identification, a project identification, an update time, a node identification of a child node, and a node identification of a parent node of the child node. The node identifier is a unique character string capable of identifying the node, and may specifically be a hash value or the like. For example, as shown in fig. 4, when the developer a1 completes the code submission operation of the code segment h2 to the personal branch a1, the corresponding code update record 1 is generated; when the developer a1 completes the first merge operation of merging code segment h6 from trunk branch a to personal branch a1, a corresponding code update record 2 is generated; when developer a1 completes merging code segment h3 from the individual branch to backbone branch a, the corresponding code update record 3 is generated. A code updating record corresponding to the code submitting operation comprises a father node identifier; and code updating records corresponding to the first merging operation and the second merging operation respectively comprise a first father node identifier and a second father node identifier. In the embodiment, when the first merging operation is performed, the merging mode is an indirect migration mode, that is, a corresponding code update record is also produced, so that the inheritance relationships of parent and child nodes in the code update process are easier to trace, and the subsequent version management is facilitated.

In one embodiment, the code update record further comprises an update log; determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node, further comprising: when a code updating operation involves multiple Git items, code updating records corresponding to each Git item involved are generated based on the same updating log. In the embodiment, when a developer relates to a plurality of Git projects in one code updating operation, the terminal generates a code updating record corresponding to each Git project based on the same updating log, so that the same operation can be identified in the subsequent version numbering.

And step 206, synchronizing the code updating records to the database, initiating a detection application signal to the server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, adding each code updating record in the code updating track to the list to be numbered, and combining the Git items in the list to be numbered according to the updating time and the developer identifications to obtain the CFD version number of each combination.

And the terminal generates a code updating record, then synchronizes to the database in time and initiates a detection application signal to the server. And the server side inquires a code updating record of a developer who initiates a detection application signal in the current numbering cycle from the database every other numbering cycle, and further determines the version number of the CFD software according to the code updating record. The numbering cycle refers to a preset cycle of version numbering performed by the server, for example, 1 day.

In one embodiment, initiating a detection application signal to a server includes: and when the developer sequentially executes the code submitting operation, the first merging operation and the second merging operation based on the modified codes in the current round, the developer initiates a detection application signal to the server. During the numbering cycle, some developers may have performed multiple rounds of code updates, and some developers may not have performed any updates. In this embodiment, only when the developer completes one round of code update, the terminal initiates a detection application signal to the server, so as to reduce the data processing burden of the server.

In one embodiment, tracing the code update track of each developer in the current numbering cycle according to the node identification comprises: the server side inquires the node identification of each Git project contained in the CFD software in the last CFD version number generated in the last numbering period as a historical node identification; and tracing the father node from the child node of the inquired first code updating record, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is a historical node identifier, and generating a code updating track of a corresponding developer based on the traced plurality of code updating records.

The server first queries the last CFD version number generated in the last numbering cycle. Each version number of the CFD software has a corresponding version identification. The version identification may specifically be a node identification of each Git item contained in the CFD software. For example, the last CFD version of the previous numbering cycle is numbered 9413, and the corresponding version is identified as "GitA: 1340371B32acb981 fete 7f + Git B: 1f56fecedb869b2b67b1+ Git C: 7049e53d1914b2bc264 ". For convenience of description, the node identifier in the latest CFD version number determined in the last numbering cycle is referred to as a history node identifier gitpro.

Further, the server determines developer identifications of the developers who initiated the detection application signals in the current numbering period, and tracks the code updating tracks of the developers in the current numbering period. Specifically, the server side inquires developer identifications which initiate detection application signals in the current numbering period and code updating records generated in the current numbering period corresponding to the developer identifications in a database, screens the code updating records, and adds effective code updating records obtained through screening to a list to be numbered.

In one embodiment, the process of screening the code update records is a process of updating the code update track, and the specific implementation may be that the code update records are sorted based on the update time in the code update records, a parent node is traced back from a child node of a first record, the traced parent node is taken as a child node, the parent node is traced back again until the node identifier of the traced parent node is a history node identifier, and the code update track of the corresponding developer is generated based on the traced multiple code update records. For example, as shown in fig. 4, the developer a1 performs code update in the current numbering cycle, the corresponding code update record includes records 1-6, the server firstly sorts the 6 records according to the update time, based on that the parent node in the record 1 in the first order is h2, the record 2 with h2 as a child node is taken as a record in the second order, and so on, until the history node identifier 1340371b32acb981fede7f with the hash value of the first parent node of the record 6 being GitA is queried, and finally the code update track of the developer a1 in the current numbering cycle is determined as follows: record 1 → record 2 → record 3 → record 4 → record 6.

In one embodiment, combining Git items in the list to be numbered according to the update time and the developer identifier to obtain the CFD version number of each combination, includes: the server side detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the to-be-numbered list according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

After the list to be numbered is generated, the server side numbers the code updating records in the list to be numbered according to the updating time, and if a plurality of code updating records exist, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range, only one code updating record with the earliest updating time in the plurality of code updating records is reserved. As shown in FIG. 5, record B and record F only need to keep record B, and record E and record A only need to keep record E.

And traversing each code updating record in the list to be numbered by the server according to the updating time, and numbering new versions until the list to be numbered is empty. Specifically, the server combines the node identifier in each reserved code update record with the node identifiers of other Git projects at the corresponding update time to obtain the CFD software version number and version identifier corresponding to the code update record. For example, as shown in fig. 5, assuming that the update time of record B is T1, the hash values of Git items at time T1 are combined to obtain the CFD software version number and version id corresponding to record B; assuming that the update time of the record D is T3, the hash values of the Git items at the time T3 are combined to obtain the CFD software version number and version identification corresponding to the record D.

The application provides a code version management method suitable for CFD software automation test, based on distributed version control system Git, through scanning code updating records of multiple Git projects, the unnumbered code updating records are identified to enter a list to be numbered, Git project combination is carried out in the list to be numbered according to single code updating operation of a developer, and the Git project combination is sorted according to the updating time recorded in the Git project combination, so that the numbering sequence of the Git projects is determined, the software versions are numbered according to the precedence sequence of the developer under the condition that the multiple Git projects are updated, and the backtracking search of identifying version labels and version problems is facilitated. In addition, compared with the traditional method of synchronously numbering the versions while updating the codes, the method has the advantages that the same developer often has the problems of disordered numbering sequence or missing updating due to inconsistent submission time of a plurality of projects or faults of the server side, the codes are numbered in an asynchronous mode, namely, the code updating records are temporarily stored in the database, only when the numbering period is reached, the server side starts to scan the hash value of the last version numbering record of the Git project, all unnumbered records in the database are recorded into a list to be numbered, and screening and combining the numbers are uniformly carried out, so that the numbering cannot be disordered fundamentally, each updating cannot be missed, and the fault-tolerant rate of the versions is improved.

It should be understood that, although the steps in the flowchart of fig. 2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in fig. 2 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.

In one embodiment, as shown in fig. 6, there is provided a field simulation software code version management apparatus 600, including: a code update operation module 602, a code update recording module 604, and a code version numbering module 606, wherein:

a code updating operation module 602, configured to obtain a code updating operation on at least one Git project in the CFD software;

a code update recording module 604, configured to determine the modified Git project as a child node according to the code update operation, and generate a code update record of the child node; the code updating record comprises a developer identifier, updating time, a node identifier of a child node and a node identifier of a father node of the child node;

the code version numbering module 606 is configured to synchronize the code update records to the database, initiate a detection application signal to the server, enable the server to periodically query the code update records from the database according to the detection application signal, determine developer identifiers of all developers performing code update in the current numbering period, trace back a code update track of each developer in the current numbering period according to the node identifier, add each code update record in the code update track to the list to be numbered, and combine Git items in the list to be numbered according to the update time and the developer identifiers, so as to obtain a CFD version number of each combination.

In one embodiment, as shown in fig. 6, the field simulation software code version management apparatus 600 further includes a development branch establishing module 608 for establishing a Git project for each functional module in the CFD software; establishing a development branch of each Git project; the development branches comprise a main branch and an individual branch corresponding to each developer responsible for developing the Git project; acquiring a code update operation on at least one Git project in CFD software, comprising: and acquiring the code updating operation of the current personal branch on the corresponding Git item in the CFD software.

In one embodiment, the code update recording module 604 is further configured to determine, as a child node, a latest code submitted based on the current personal branch and determine, as a parent node, a code submitted last time based on the current personal branch when the code update operation is a code submission operation; when the code updating operation is a first merging operation, determining a latest code based on a current personal branch as a first father node, determining a latest code in a main branch corresponding to the current personal branch as a second father node, merging the second father node into the current personal branch, and merging the first father node and the second father node in the current personal branch to obtain a child node; when the code updating operation is the second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the trunk branch corresponding to the current personal branch, determining the latest code in the trunk branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the trunk branch to obtain a child node.

In one embodiment, as shown in fig. 6, the field simulation software code version management apparatus 600 further includes a code conflict control module 610, configured to, when the code update operation is the second merge operation, detect whether the first parent node on the current personal branch pointed to by the second merge operation has completed the first merge operation; if not, prompting to execute a first merging operation; and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

In one embodiment, the code update record further comprises an update log; the code update recording module 604 is further configured to, when a code update operation involves multiple Git projects, generate a code update record corresponding to each Git project involved based on the same update log; the code version numbering module 606 is further configured to detect, by the server, whether a plurality of code update records exist in the to-be-numbered list, where the developer identifier and the update log are the same and the difference between the update times is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the to-be-numbered list according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

In one embodiment, the code version numbering module 606 is further configured to initiate a detection application signal to the server when the developer completes the code submitting operation, the first merging operation, and the second merging operation in sequence based on the modified code of the current round.

In one embodiment, the code version numbering module 606 is further configured to query, by the server, a node identifier of each Git item included in the CFD software in a last CFD version number generated in a last numbering cycle, as a historical node identifier; and tracing the father node from the inquired child node of the first code updating record in the current numbering period, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is the historical node identifier, and generating the code updating track of the corresponding developer based on the traced code updating records.

The application provides a code version management device suitable for CFD software automation test, based on distributed version control system Git, through scanning the code update record of many Git projects, the code update record of discerning not numbering gets into the list of waiting to number, carry out Git project combination according to developer's single code update operation in the list of waiting to number, and arrange according to the renewal time of record in Git project combination, thereby confirm the numbering sequence of Git project, realized that the software version numbers according to developer's precedence order under the circumstances that a plurality of Git projects are updated, be favorable to discerning the backtracking searching of version label and version problem. In addition, compared with the traditional method of synchronously numbering versions while updating codes, the method and the system have the advantages that the same developer often has the problem that the numbering sequence is disordered or updating is omitted due to inconsistent submission time of a plurality of projects or faults of the server side, the codes are numbered in an asynchronous mode, namely, the code updating records are temporarily stored in the database, only when the numbering period is reached, the server side starts scanning from the hash value of the last version number record of the Git project, all unnumbered records in the database are recorded into a list to be numbered, and screening and combination numbering are uniformly carried out, so that the numbering is fundamentally ensured not to be disordered, each updating cannot be omitted, and the fault tolerance rate of the version numbers is improved.

For specific limitations of the flow field simulation software code version management apparatus, reference may be made to the above limitations of the flow field simulation software code version management method, which is not described herein again. The various modules in the flow field simulation software code version management device can be wholly or partially realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent of a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in fig. 7. The computer device includes a processor, a memory, a communication interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The communication interface of the computer device is used for communicating with an external terminal in a wired or wireless manner, and the wireless manner can be realized through WIFI, an operator network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a flow field simulation software code version management method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the configuration shown in fig. 7 is a block diagram of only a portion of the configuration associated with the present application, and is not intended to limit the computing device to which the present application may be applied, and that a particular computing device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having a computer program stored therein, the processor implementing the following steps when executing the computer program:

synchronizing the code updating records to a database, initiating a detection application signal to a server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, adding each code updating record in the code updating track to a list to be numbered, and combining Git items in the list to be numbered according to updating time and the developer identifications to obtain the CFD version number of each combination.

In one embodiment, the processor, when executing the computer program, further performs the steps of: establishing a Git project aiming at each functional module in the CFD software; establishing a development branch of each Git project; the development branches comprise a main branch and an individual branch corresponding to each developer responsible for developing the Git project; and acquiring the code updating operation of the current personal branch on the corresponding Git item in the CFD software.

In one embodiment, the processor, when executing the computer program, further performs the steps of: when the code updating operation is a code submitting operation, determining the latest code submitted based on the current personal branch as a child node, and determining the code submitted last time based on the current personal branch as a parent node; when the code updating operation is a first merging operation, determining a latest code in a main branch corresponding to a current personal branch as a first father node, determining a latest code in the main branch corresponding to the current personal branch as a second father node, merging the second father node into the current personal branch, and merging the first father node and the second father node in the current personal branch to obtain a child node; and when the code updating operation is a second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the main branch corresponding to the current personal branch, determining the latest code in the main branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the main branch to obtain a child node.

In one embodiment, the processor when executing the computer program further performs the steps of: when the code updating operation is a second merging operation, detecting whether a first father node on a current personal branch pointed by the second merging operation has completed a first merging operation; if not, prompting to execute a first merging operation; and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

The code update record further comprises an update log; in one embodiment, the processor, when executing the computer program, further performs the steps of: when a code updating operation relates to a plurality of Git projects, generating a code updating record corresponding to each Git project based on the same updating log; the server side detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the to-be-numbered list according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

In one embodiment, the processor, when executing the computer program, further performs the steps of: and when the developer sequentially executes the code submitting operation, the first merging operation and the second merging operation based on the modified codes in the current round, the developer initiates a detection application signal to the server.

In one embodiment, the processor, when executing the computer program, further performs the steps of: the server side inquires the node identification of each Git project contained in the CFD software in the last CFD version number generated in the last numbering period as a historical node identification; and tracing the father node from the inquired child node of the first code updating record in the current numbering period, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is the historical node identifier, and generating the code updating track of the corresponding developer based on the traced code updating records.

In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:

In one embodiment, the computer program when executed by the processor further performs the steps of: establishing a Git project aiming at each functional module in the CFD software; establishing a development branch of each Git project; the development branches comprise a main branch and an individual branch corresponding to each developer responsible for developing the Git project; and acquiring the code updating operation of the current personal branch on the corresponding Git item in the CFD software.

In one embodiment, the computer program when executed by the processor further performs the steps of: when the code updating operation is a code submitting operation, determining the latest code submitted based on the current personal branch as a child node, and determining the code submitted last time based on the current personal branch as a parent node; when the code updating operation is a first merging operation, determining a latest code based on a current personal branch as a first father node, determining a latest code in a main branch corresponding to the current personal branch as a second father node, merging the second father node into the current personal branch, and merging the first father node and the second father node in the current personal branch to obtain a child node; when the code updating operation is the second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the trunk branch corresponding to the current personal branch, determining the latest code in the trunk branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the trunk branch to obtain a child node.

In one embodiment, the computer program when executed by the processor further performs the steps of: when the code updating operation is a second merging operation, detecting whether a first father node on a current personal branch pointed by the second merging operation has completed a first merging operation; if not, prompting to execute a first merging operation; and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

The code update record further comprises an update log; in one embodiment, the computer program when executed by the processor further performs the steps of: when a code updating operation relates to a plurality of Git projects, generating a code updating record corresponding to each Git project based on the same updating log; the server side detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the to-be-numbered list according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

In one embodiment, the computer program when executed by the processor further performs the steps of: and when the developer sequentially executes the code submitting operation, the first merging operation and the second merging operation based on the modified codes in the current round, the developer initiates a detection application signal to the server.

In one embodiment, the computer program when executed by the processor further performs the steps of: the server side inquires the node identification of each Git project contained in the CFD software in the last CFD version number generated in the last numbering period as a historical node identification; and tracing the father node from the inquired child node of the first code updating record in the current numbering period, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is the historical node identifier, and generating the code updating track of the corresponding developer based on the traced code updating records.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A flow field simulation software code version management method is characterized by comprising the following steps:

acquiring code updating operation of at least one Git project in CFD software;

synchronizing the code updating records to a database, initiating a detection application signal to a server, enabling the server to periodically query the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in a current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, and adding each code updating record in the code updating track to a list to be numbered;

the server side detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the list to be numbered according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

2. The method of claim 1, further comprising:

establishing a Git project aiming at each functional module in the CFD software;

establishing a development branch of each Git project; the development branches comprise a main branch and an individual branch corresponding to each developer responsible for developing the Git project;

the acquiring of the code updating operation of at least one Git project in the CFD software comprises the following steps:

and acquiring the code updating operation of the current personal branch on the corresponding Git item in the CFD software.

3. The method according to claim 2, wherein determining the modified Git item as a child node according to the code update operation, generating a code update record for the child node comprises:

when the code updating operation is a code submitting operation, determining the latest code submitted based on the current personal branch as a child node, and determining the code submitted last time based on the current personal branch as a parent node;

when the code updating operation is a first merging operation, determining a latest code based on the current personal branch as a first father node, determining a latest code in a main branch corresponding to the current personal branch as a second father node, merging the second father node to the current personal branch, and merging the first father node and the second father node at the current personal branch to obtain a child node;

when the code updating operation is a second merging operation, determining the latest code in the current personal branch as a first father node, merging the first father node to the main branch corresponding to the current personal branch, determining the latest code in the main branch corresponding to the current personal branch as a second father node, and merging the first father node and the second father node in the main branch to obtain a child node.

4. The method of claim 3, further comprising:

when the code updating operation is a second merging operation, detecting whether a first father node on a current personal branch pointed by the second merging operation completes a first merging operation or not;

if not, prompting to execute the first merging operation;

and if yes, detecting whether conflicts exist among the Git projects obtained by executing the first merging operation, and prompting to perform conflict resolution on the current personal branch when the conflicts exist, and executing the second merging operation until the Git projects have no conflicts.

5. The method of claim 3, wherein the code update record further comprises an update log; determining the modified Git project as a child node according to the code updating operation, and generating a code updating record of the child node, further comprising:

when the code updating operation relates to a plurality of Git projects at one time, generating a code updating record corresponding to each Git project based on the same updating log;

the combining the Git items in the list to be numbered according to the updating time and the developer identification to obtain the CFD version number of each combination, comprising:

the server detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range;

if yes, only keeping one code updating record with the earliest updating time in the plurality of code updating records;

sequencing all the reserved Git items in the list to be numbered according to the updating time;

and combining the Git item related to each code updating record in the list to be numbered and other Git items of corresponding updating time according to the sequence, and sequentially determining the CFD version number of each combination.

6. The method of claim 3, wherein the initiating a detection application signal to the server comprises:

and when the developer sequentially executes the code submitting operation, the first merging operation and the second merging operation based on the modified codes in the current round, a detection application signal is sent to the server.

7. The method according to claim 3, wherein tracing back the code update trace of each developer in the current numbering cycle according to the node identification comprises:

the server side inquires the node identification of each Git project contained in the CFD software in the last CFD version number generated in the last numbering period as a historical node identification;

and tracing the father node from the inquired child node of the first code updating record in the current numbering period, taking the traced father node as the child node, tracing the father node again until the node identifier of the traced father node is the historical node identifier, and generating a code updating track of a corresponding developer based on the traced code updating records.

8. An apparatus for flow field simulation software code version management, the apparatus comprising:

a code updating record module, configured to determine the modified Git project as a child node according to the code updating operation, and generate a code updating record of the child node; the code updating record comprises a developer identifier, updating time, a node identifier of a child node and a node identifier of a father node of the child node;

the code version numbering module is used for synchronizing the code updating records to a database, sending a detection application signal to the server, enabling the server to periodically inquire the code updating records from the database according to the detection application signal, determining developer identifications of all developers performing code updating in the current numbering period, tracing a code updating track of each developer in the current numbering period according to the node identifications, and adding each code updating record in the code updating tracks to a list to be numbered; the server side detects whether a plurality of code updating records exist in the list to be numbered, wherein the developer identification and the updating log are the same, and the difference value of the updating time is within a preset range; if so, only one code updating record with the earliest updating time in the plurality of code updating records is reserved; sequencing all the reserved Git items in the list to be numbered according to the updating time; and according to the combinations of the Git item related to each code updating record in the sequencing list to be numbered and other Git items of corresponding updating time, sequentially determining the CFD version number of each combination.

9. A computer device comprising a memory and a processor, the memory storing a computer program, wherein the processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.