Code data management method and apparatus, and device and medium

Abstract

Provided are a code data management method and apparatus, and a device and a medium. The method comprises: receiving a set of merge requests, wherein the set of merge requests is used for merging first code data into second code data; in response to it being determined that the set of merge requests meets a predetermined condition, determining whether there is a previous merge task being executed, wherein the previous merge task is executed on the basis of a set of previous merge requests received prior to the set of merge requests; and in response to it being determined that there is no previous merge task being executed, executing a merge task on the basis of the set of merge requests, so as to merge the difference between the first code data and the second code data into the second code data. By using the exemplary implementations of the present disclosure, a corresponding merge condition can be designated on the basis of specific application development requirements, and when the merge condition is met, a merge task is automatically executed on the basis of a set of currently received merge requests.

Description

Methods, apparatus, devices, and media for managing code data Technical Field

[0001] Exemplary implementations of this disclosure generally relate to application development, and more particularly to methods, apparatus, devices, and computer-readable storage media for managing code data in application development. Background Technology

[0002] As applications grow in size, collaborative application development has become a primary method in software development. Currently, various application development environments are available, allowing different developers to create their respective functional modules. During development, applications go through development, testing, and release phases, resulting in multiple development branches and thus multiple versions of code for a single application. At this point, version merging is necessary, allowing for iterative development to create an application that better meets the intended functionality.

[0003] Summary of the Invention

[0004] In a first aspect of this disclosure, a method for managing code data is provided. In this method, a set of merge requests is received for merging first code data into second code data; in response to determining that the set of merge requests satisfies predetermined conditions, it is determined whether there is an ongoing previous merge task, the previous merge task being performed based on a set of previous merge requests received prior to this set of merge requests; and in response to determining that there is no ongoing previous merge task, a merge task is performed based on the set of merge requests to merge the differences between the first code data and the second code data into the second code data.

[0005] In a second aspect of this disclosure, an apparatus for managing code data is provided. The apparatus includes: a receiving module configured to receive a set of merge requests for merging first code data into second code data; a determining module configured to, in response to determining that a set of merge requests meets predetermined conditions, determine whether there is an ongoing previous merge task, the previous merge task being executed based on a set of previous merge requests received prior to the previous set of merge requests; and an execution module configured to, in response to determining that there is no ongoing previous merge task, execute a merge task based on the set of merge requests to merge the differences between the first code data and the second code data into the second code data.

[0006] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to a first aspect of this disclosure when executed by the at least one processing unit.

[0007] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method according to a first aspect of this disclosure.

[0008] In a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to a first aspect of this disclosure.

[0009] It should be understood that the content described in this content section is not intended to limit the key or essential features of the implementation of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] In the following detailed description, the above and other features, advantages, and aspects of the various implementations of this disclosure will become more apparent, taken in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 shows a block diagram of an application environment according to an exemplary implementation of the present disclosure;

[0012] Figure 2 shows a block diagram for managing code data according to some implementations of this disclosure;

[0013] Figure 3 shows a block diagram of the merging conditions according to some implementations of this disclosure;

[0014] Figure 4 shows a block diagram of a process for creating a merge task according to some implementations of this disclosure;

[0015] Figure 5 shows a block diagram illustrating the functionality of multiple modules for managing code data according to some implementations of this disclosure;

[0016] Figure 6 shows a flowchart of a method for managing code data according to some implementations of this disclosure;

[0017] Figure 7 shows a block diagram of an apparatus for managing code data according to some implementations of this disclosure; and

[0018] Figure 8 shows a block diagram of a device capable of implementing various implementations of the present disclosure. Detailed Implementation

[0019] Implementations of this disclosure will now be described in more detail with reference to the accompanying drawings. While some implementations of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the implementations set forth herein. Rather, these implementations are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and implementations of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] In the description of the implementation methods disclosed herein, the term "comprising" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one implementation" or "the implementation" should be understood as "at least one implementation". The term "some implementations" should be understood as "at least some implementations". Other explicit and implicit definitions may also be included below. As used herein, the term "model" can represent the relationships between various data. For example, the aforementioned relationships can be obtained based on various currently known and / or future-developed technical solutions.

[0021] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and user authorization should be obtained.

[0023] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0024] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, for example, via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose whether to "agree" or "disagree" to provide personal information to the electronic device.

[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0026] The term "in response to" as used herein refers to a state in which a corresponding event occurs or a condition is satisfied. It will be understood that the timing of subsequent actions performed in response to such event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be performed immediately upon the occurrence of the event or the fulfillment of the condition; while in others, they may be performed some time after the occurrence of the event or the fulfillment of the condition.

[0027] Example Environment

[0028] Currently, various application development environments are available, allowing different developers to develop their respective functional modules within these environments. During development, applications need to go through development, testing, and release phases, which leads to multiple development branches. Consequently, for a single application, there will be multiple versions of code data. See Figure 1 for an application environment illustrating some implementations of this disclosure; Figure 1 shows a block diagram 100 of an application environment according to an exemplary implementation of this disclosure.

[0029] As shown in Figure 1, for a specific application, multiple development versions can exist during the development process. For example, at time point T1, development version 110 may exist, and release version 120 can be generated based on development version 110. Release version 120 can undergo testing and become a new release version 122. As another example, as the development process continues, at time point T2, development version 112 may exist, and release version 130 can be generated based on development version 112. Release version 130 can undergo testing and become a new release version 132. At time point T3, there will be multiple versions of code data: release version 122, release version 132, and development version 114.

[0030] Releases 122 and 132 underwent their respective testing processes, eliminating potential bugs. Meanwhile, development version 114 completed its development process and added new features beyond those of releases 122 and 132. At this point, release 122 needed to be merged into release 132, and vice versa. This required performing version merges, thus iteratively developing an application that better met the intended functionality.

[0031] Although development environments supporting multi-user parallel development, testing, and release have been proposed, manual management by administrators is still required during the code data merging process. For example, the execution interval of manual merging operations is relatively long (usually once a day, or other frequencies), by which time a large number of code changes have accumulated. This makes code conflicts very likely during the merging process, and modifications on the old version take a long time to be reflected in the new version.

[0032] Furthermore, the synchronization task status between versions is unclear; when version 132 is released, it cannot be determined whether version 132 includes all updates from version 122. Meanwhile, manually resolving code conflicts is inefficient, wastes manpower, and may lead to potential risks during the code data merging process. Therefore, a more efficient and reliable method for managing code data is desired.

[0033] Overview of code data management

[0034] To at least partially address the shortcomings of the prior art, a method for managing code data is proposed according to an exemplary implementation of this disclosure. Referring to Figure 2, which describes an overview of an exemplary implementation of this disclosure, Figure 2 illustrates a block diagram 200 for managing code data according to some implementations of this disclosure.

[0035] As shown in Figure 2, first code data 210 and second code data 220 may exist. A set of merge requests 230 may be received. Here, the set of merge requests 230 is used to merge the first code data into the second code data. It may be determined that the set of merge requests meets predetermined conditions (e.g., merge condition 232). In response to determining that the set of merge requests 230 meets the predetermined conditions, it is determined whether there is an ongoing previous merge task 242. Here, the previous merge task 242 is executed based on a set of previous merge requests received before the current set of merge requests.

[0036] If the previous merge task 242 has been completed, then there is no previous merge task 242 in progress. If the previous merge task 242 has not yet been completed, then there is a previous merge task 242 in progress, and the current merge task 240 must wait for the previous merge task 242 to complete before it can be started. In response to determining that there is no previous merge task in progress, merge task 240 is executed based on a set of merge requests to merge the differences between the first code data 210 and the second code data into the second code data 220.

[0037] Using the exemplary implementation of this disclosure, corresponding merging conditions can be specified according to specific application development needs, and when the merging conditions are met, the merging task can be automatically executed based on the currently received set of merging requests. In this way, the complexity of manual operations during the development process can be greatly reduced, and the potential risks caused by human error can be mitigated, thereby improving development efficiency.

[0038] Detailed process of code data management

[0039] A summary of some implementations of this disclosure has been described with reference to Figure 2. Further information regarding code data management is described below with reference to the accompanying drawings. According to some implementations of this disclosure, the first code data and the second code data include source code associated with the application. The first code data includes either a committed version or a test version of the source code, and the second code data includes a development version of the source code. Specifically, code data in various branches of the application development phase can be processed automatically. For example, tested and / or released code data can be merged into subsequent development versions, thereby synchronizing optimized code data from test and release versions to the development version while performing development, testing, and release in parallel.

[0040] Figure 3 shows a block diagram 300 of merging conditions according to some implementations of this disclosure. As shown in Figure 3, corresponding merging conditions 232 can be specified according to specific application development requirements. These merging conditions 232 may include quantity conditions 310, time conditions 320, and conflict conditions 330.

[0041] According to some implementations of this disclosure, quantity condition 310 can specify whether the number of a set of merge requests exceeds a threshold. Generally speaking, the larger the number of merge requests, the more code is involved in the merge process, and the higher the probability of potential conflicts. In this case, an appropriate threshold number can be specified (e.g., 5 or other numbers).

[0042] The merge process is initiated when the number of received merge requests is greater than or equal to 5; otherwise, it waits for subsequent merge requests. Since the merge process incurs additional resource overhead, executing it too frequently may increase the workload of the development environment. This approach strikes a balance between resource overhead and conflict probability, thereby improving overall development efficiency. Specifically, the threshold number can be determined based on the frequency of merge request reception; the lower the frequency, the smaller the threshold number. This avoids long waits for the next merge and improves merge efficiency.

[0043] Time condition 320 can specify whether the time difference between the current time and the execution time of the previous merge task exceeds a threshold time difference. For example, it can be specified that the merge process is executed once every hour; that is, if the time difference exceeds one hour, the merge process is executed based on the currently received merge requests. It should be understood that if the frequency of receiving merge requests is low, no new merge requests may be received for a long time, which may result in the number of merge requests not meeting the quantity condition 310 for a long time, and thus not being merged. In this case, time condition 320 can increase the execution frequency of the merge process to a certain extent, thereby ensuring that modifications to code data can be synchronized to the development version in a timely manner.

[0044] Conflict condition 330 can specify whether there exists a third code data to be merged into the second code data, where there is a code conflict between the first and third code data. The merge process can be initiated if no conflict is found.

[0045] According to some implementations of this disclosure, the average number of lines of code difference determined by the merge condition 232 described above is approximately 300 lines. Compared to conventional techniques that trigger the merge process on a timed basis, the variance and average of the determined number of lines of code are better. This approach improves the stability of the merge process. Furthermore, the number of lines of code directly affects the success rate and conflict rate of the merge pipeline. This approach ensures that small-scale synchronous tasks are executed each time, and can significantly reduce the code conflict rate and execution failure rate, for example, to 5% or even lower.

[0046] According to some implementations of this disclosure, merge task 240 may include one or more merge requests. See Figure 4 for further details, which shows a block diagram 400 of a process for creating a merge task according to some implementations of this disclosure. If the merge process is initiated according to quantity condition 310, then merge task 240 may include a threshold number of merge requests, such as 410, ..., 412. As another example, if the merge process is initiated according to time condition 320, then merge task 240 may include fewer than the threshold number of merge requests, for example, only a single merge request 414.

[0047] According to some implementations of this disclosure, a synchronous pipeline can be triggered to perform a merge task. Each merge request can be processed in a similar manner, for example, for a first merge request in a set of merge requests, determining a first code portion in first code data corresponding to the first merge request, and a second code portion in second code data corresponding to the first merge request; determining a first difference between the first code portion and the second code portion; and in response to determining that the first difference passes the code inspection process, merging the first difference into the second portion of the second code data.

[0048] Specifically, differences between code data can be identified; for example, two code sections with discrepancies can be found and their differences determined. A pipeline can be initiated to perform code checks on these discrepancies to ensure that the merged code data does not produce anomalies. Using the example implementation of this disclosure, it can be ensured that all merged code data passes the code check process, thereby ensuring that the merged second code data can achieve the desired functionality.

[0049] According to some implementations of this disclosure, the code inspection process may include multiple aspects. For example, a build inspection process may be performed to determine whether the merged second code data has been successfully built. For example, temporary code data may be created to store the result of merging the first code portion into the second code portion, and a build operation may be performed on the temporary code data. If the build is successful, the build inspection process has passed; otherwise, the build inspection process has failed.

[0050] Alternatively and / or additionally, the code review process may include a stability check process to determine whether the merged second code data passes stability testing. Here, stability testing ensures that the merged code data produces stable operating results, thereby ensuring the quality of the merged code data. Furthermore, the code review process may include a security check process to determine whether the merged second code data passes security testing, thereby ensuring that the merged code data does not pose a data security risk.

[0051] According to some implementations of this disclosure, if the first difference is determined to pass the code review process, it indicates that the merge process will not pose any potential risks, and therefore the first merge request can be executed. Alternatively and / or additionally, if the first difference is determined to fail the code review process, it indicates that directly executing the merge process may pose potential risks, and therefore subsequent manual handling is required. In this case, prompts can be provided to at least one of the following: the submitter of the first merge request, and the administrator used to manage the code data merge.

[0052] Specifically, the commit history of merge requests can be queried to identify the submitter of the relevant merge request, the administrator used to oversee the merge process can be identified, and prompts can be provided to the submitter and / or administrator to inform them that the relevant code data for the merge request failed the code review process. Using the example implementation of this disclosure, relevant personnel can be promptly notified to address potential risks in the code data, thereby improving development efficiency.

[0053] According to some implementations of this disclosure, it is possible to check whether code conflicts arise between various code requests. Specifically, for a second merge request in a set of merge requests, it is determined whether a code conflict exists between a first code portion and a third code portion in the first code data corresponding to the second merge request. Further, in response to determining that a code conflict exists between the first code portion and the third code portion, a prompt message is provided to at least one of the following: the first committer of the first merge request and the second committer of the second merge request. Specifically, the commit history of each merge request can be queried to determine one or more committers of the relevant merge request, and then the prompt message is provided.

[0054] Using the example implementation of this disclosure, the prompt information may include, for example, information related to the merge request, such as the merge request identifier, commit time, the specific location of the code segment involved, and related descriptions, etc. In this way, each committer can quickly locate the code causing the conflict, thereby correcting potential errors in the code.

[0055] According to some implementations of this disclosure, the first committer and the second committer are determined based on the first commit history of the first merge request and the second commit history of the second merge request, respectively. A communication group is established based on the first and second committers, and prompt information is provided in the communication group. When code conflicts involve multiple committers, a group can be established for multiple committers, thereby supporting multiple committers to discuss issues and resolve code conflicts in the group. For example, code data can be adjusted, and the first merge request can be updated based on the adjusted code data. According to some implementations of this disclosure, in response to determining that the code conflict has been resolved, the updated first merge request is executed. At this time, code conflicts can be resolved in a timely manner, and development efficiency can be improved.

[0056] According to some implementations of this disclosure, in response to determining that there is no code conflict between the first code section and the third code section, the second merge request can be executed directly. Using the example implementations of this disclosure, it can be ensured that the second merge request will not cause code conflicts, thereby ensuring the stability of the merge process.

[0057] The steps involved in merging code data have been described above. The overall flow for merging code data is described below with reference to Figure 5. Figure 5 shows a block diagram 500 illustrating the functionality of multiple modules for managing code data according to some implementations of this disclosure. As shown in Figure 5, the process described above can be executed by invoking the triggering module 510, the checking module 520, and the exception handling module 530.

[0058] At block 512, triggering module 510 can determine whether a set of received merge requests meets predetermined merge conditions. In response to a set of merge requests meeting the merge conditions, the process can proceed to block 514 to determine if there is an ongoing previous merge task. In response to a "yes" result, the current process can be paused and the process can wait at block 516 for the previous merge task to complete. In response to a "no" result, checking module 520 can be invoked to perform further processing.

[0059] At box 522, a lightweight merge can be performed. Specifically, a corresponding merge operation can be performed based on each merge request. At box 524, if the merge is successful, log information about the successful execution can be logged at box 526. If the merge fails, the exception handling module 530 can be invoked to perform subsequent exception handling.

[0060] Specifically, in box 532, it can be determined whether a merge exception exists; in box 534, it can be determined whether a code conflict exists. In the event of an exception and / or conflict, information about the submitter of the corresponding merge request and / or the administrator of the merge system can be queried. Furthermore, in box 536, the relevant submitter and / or administrator can be notified. In this way, a communication group can be established for relevant personnel handling the exception, facilitating timely communication and troubleshooting.

[0061] Using the exemplary implementation of this disclosure, corresponding merging conditions can be specified according to specific application development needs, and when the merging conditions are met, the merging task can be automatically executed based on the currently received set of merging requests. In this way, the complexity of manual operations during the development process can be greatly reduced, and the potential risks caused by human error can be mitigated, thereby improving development efficiency.

[0062] Example process

[0063] Figure 6 illustrates a flowchart of a method 600 for managing code data according to some implementations of the present disclosure. At block 610, a set of merge requests is received for merging first code data into second code data; at block 620, in response to determining that a set of merge requests meets predetermined conditions, it is determined whether there is an ongoing previous merge task, which is performed based on a set of previous merge requests received before this set of merge requests; and at block 630, in response to determining that there is no ongoing previous merge task, a merge task is performed based on the set of merge requests to merge the differences between the first code data and the second code data into the second code data.

[0064] According to some implementations of this disclosure, the predetermined conditions include at least one of the following: whether the number of a set of merge requests exceeds a threshold number; whether the time difference between the current time and the execution time of the previous merge task exceeds a threshold time difference; and whether there is a third code data to be merged into the second code data, and whether there is a code conflict between the first code data and the third code data.

[0065] According to some implementations of this disclosure, performing a merge task includes: for a first merge request in a set of merge requests, determining a first code portion in first code data corresponding to the first merge request, and a second code portion in second code data corresponding to the first merge request; determining a first difference between the first code portion and the second code portion; and in response to determining that the first difference passes the code inspection process, merging the first difference into the second portion of the second code data.

[0066] According to some implementations of this disclosure, the code inspection process includes at least one of the following: a build inspection process to determine whether the merged second code data has been successfully built; a stability inspection process to determine whether the merged second code data has passed stability testing; and a security inspection process to determine whether the merged second code data has passed security testing.

[0067] According to some implementations of this disclosure, the method further includes at least one of the following: executing a first merge request in response to determining that a first difference has passed the code review process; and providing a prompt message to at least one of the following in response to determining that a first difference has failed the code review process: the submitter of the first merge request, and an administrator for managing code data merging.

[0068] According to some implementations of this disclosure, the method further includes: determining, for a second merge request in a set of merge requests, whether there is a code conflict between a first code portion and a third code portion in the first code data corresponding to the second merge request; and in response to determining that there is a code conflict between the first code portion and the third code portion, providing prompt information to at least one of the following: the first submitter of the first merge request and the second submitter of the second merge request.

[0069] According to some implementations of this disclosure, the method further includes: determining the first submitter and the second submitter based on the first submission history of the first merge request and the second submission history of the second merge request, respectively; establishing a communication group based on the first submitter and the second submitter; and providing prompt information in the communication group.

[0070] According to some implementations of this disclosure, the method further includes: in response to determining that the code conflict has been resolved, executing an updated first merge request.

[0071] According to some implementations of this disclosure, the method further includes: in response to determining that there is no code conflict between the first code portion and the third code portion, executing a first merge request.

[0072] According to some implementations of this disclosure, the first code data and the second code data include source code associated with the application, the first code data including either a committed version or a test version of the source code, and the second code data including a development version of the source code.

[0073] Example devices and equipment

[0074] Figure 7 shows a block diagram of an apparatus 700 for managing code data according to some implementations of the present disclosure. The apparatus includes: a receiving module 710 configured to receive a set of merge requests for merging first code data into second code data; a determining module 720 configured to, in response to determining that a set of merge requests meets predetermined conditions, determine whether there is an ongoing previous merge task, the previous merge task being performed based on a set of previous merge requests received prior to the current set of merge requests; and an execution module 730 configured to, in response to determining that there is no ongoing previous merge task, perform a merge task based on the set of merge requests to merge the differences between the first code data and the second code data into the second code data.

[0075] According to some implementations of this disclosure, the predetermined conditions include at least one of the following: whether the number of a set of merge requests exceeds a threshold number; whether the time difference between the current time and the execution time of the previous merge task exceeds a threshold time difference; and whether there is a third code data to be merged into the second code data, and whether there is a code conflict between the first code data and the third code data.

[0076] According to some implementations of this disclosure, the execution module includes: a code determination module configured to determine, for a first merge request in a set of merge requests, a first code portion in first code data corresponding to the first merge request, and a second code portion in second code data corresponding to the first merge request; a difference determination module configured to determine a first difference between the first code portion and the second code portion; and a merging module configured to merge the first difference into the second portion of the second code data in response to determining that the first difference passes the code inspection process.

[0077] According to some implementations of this disclosure, the code inspection process includes at least one of the following: a build inspection process to determine whether the merged second code data has been successfully built; a stability inspection process to determine whether the merged second code data has passed stability testing; and a security inspection process to determine whether the merged second code data has passed security testing.

[0078] According to some implementations of this disclosure, the apparatus further includes at least one of the following: a request execution module configured to execute a first merge request in response to determining that a first difference has passed the code review process; and a providing module configured to provide prompt information to at least one of the following in response to determining that a first difference has failed the code review process: the submitter of the first merge request, and an administrator for managing code data merging.

[0079] According to some implementations of this disclosure, the apparatus further includes: a conflict determination module configured to determine, for a second merge request in a set of merge requests, whether there is a code conflict between a first code portion and a third code portion in first code data corresponding to the second merge request; and a providing module configured to, in response to determining that there is a code conflict between the first code portion and the third code portion, provide prompt information to at least one of the following: the first submitter of the first merge request and the second submitter of the second merge request.

[0080] According to some implementations of this disclosure, the apparatus further includes: a submitter determination module configured to determine a first submitter and a second submitter based on a first submission history of a first merge request and a second submission history of a second merge request, respectively; an establishment module configured to establish a communication group based on the first submitter and the second submitter; and an information providing module configured to provide prompt information in the communication group.

[0081] According to some implementations of this disclosure, the apparatus further includes: a request execution module configured to execute a first merge request for updating in response to determining that a code conflict has been resolved.

[0082] According to some implementations of this disclosure, the apparatus further includes: a request execution module configured to execute a first merge request in response to determining that there is no code conflict between the first code portion and the third code portion.

[0083] According to some implementations of this disclosure, the first code data and the second code data include source code associated with the application, the first code data including either a committed version or a test version of the source code, and the second code data including a development version of the source code.

[0084] Figure 8 shows a block diagram of a device 800 capable of implementing various implementations of the present disclosure. It should be understood that the computing device 800 shown in Figure 8 is merely exemplary and should not constitute any limitation on the functionality and scope of the implementations described herein. The computing device 800 shown in Figure 8 can be used to implement the methods described above.

[0085] As shown in Figure 8, the computing device 800 is in the form of a general-purpose computing device. Components of the computing device 800 may include, but are not limited to, one or more processors or processing units 810, memory 820, storage devices 830, one or more communication units 840, one or more input devices 850, and one or more output devices 860. The processing unit 810 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 820. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of the computing device 800.

[0086] Computing device 800 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 800, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 820 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 830 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within computing device 800.

[0087] The computing device 800 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG8, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. The memory 820 may include a computer program product 825 having one or more program modules configured to perform various methods or actions of various implementations of the present disclosure.

[0088] The communication unit 840 enables communication with other computing devices via a communication medium. Additionally, the components of the computing device 800 can function as a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the computing device 800 can operate in a networked environment using logical connections to one or more other servers, networked personal computers (PCs), or another network node.

[0089] Input device 850 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 860 can be one or more output devices, such as a monitor, speaker, printer, etc. Computing device 800 can also communicate as needed with one or more external devices (not shown) via communication unit 840. These external devices, such as storage devices, display devices, etc., can communicate with one or more devices that enable user interaction with computing device 800, or with any device (e.g., network card, modem, etc.) that enables computing device 800 to communicate with one or more other computing devices. Such communication can be performed via input / output (I / O) interfaces (not shown).

[0090] According to exemplary implementations of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to exemplary implementations of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above. According to exemplary implementations of this disclosure, a computer program product is provided that stores a computer program thereon, which, when executed by a processor, implements the methods described above.

[0091] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0092] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0093] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0095] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for managing code data, comprising: Receive a set of merge requests, the set of merge requests being used to merge first code data into second code data; In response to determining that the set of merge requests meets predetermined conditions, it is determined whether there is an ongoing previous merge task, which is executed based on a set of previous merge requests received prior to the set of merge requests. as well as In response to determining that there is no previous merge task in progress, a merge task is performed based on the set of merge requests to merge the differences between the first code data and the second code data into the second code data.

2. The method according to claim 1, wherein the predetermined condition includes at least one of the following: Does the number of the set of merge requests exceed the threshold? Whether the time difference between the current time and the execution time of the previously merged task exceeds a threshold time difference; and Does a third code data exist that will be merged into the second code data, and is there a code conflict between the first code data and the third code data? 3. The method of claim 1, wherein performing the merging task comprises: For the first merge request in the set of merge requests, Identify the first code portion in the first code data corresponding to the first merge request, and the second code portion in the second code data corresponding to the first merge request; Determine the first difference between the first code portion and the second code portion; as well as In response to determining that the first difference passes the code inspection process, the first difference is merged into the second portion of the second code data.

4. The method of claim 3, wherein the code inspection process includes at least one of the following: A check process is built to determine whether the merged second code data has been successfully built; The stability check process is used to determine whether the merged second code data passes the stability test; as well as A security check process is used to determine whether the merged second code data passes security tests.

5. The method of claim 3, further comprising at least one of the following: In response to determining that the first difference passes the code inspection process, the first merge request is executed; and In response to determining that the first difference has failed the code review process, a notification is provided to at least one of the following: the submitter of the first merge request, and the administrator who manages the code data merge.

6. The method of claim 3, further comprising: For the second merge request in the set of merge requests, determine whether there is a code conflict between the first code portion and the third code portion in the first code data corresponding to the second merge request; as well as In response to determining that a code conflict exists between the first code portion and the third code portion, a prompt message is provided to at least one of the following: the first submitter of the first merge request and the second submitter of the second merge request.

7. The method of claim 6, further comprising: Based on the first commit history of the first merge request and the second commit history of the second merge request, the first submitter and the second submitter are determined respectively. A communication group is established based on the first submitter and the second submitter; as well as The notification message is provided in the communication group.

8. The method of claim 6, further comprising: In response to determining that the code conflict has been resolved, the updated first merge request is executed.

9. The method of claim 1, further comprising: In response to determining that there is no code conflict between the first code portion and the third code portion, the first merge request is executed.

10. The method of claim 1, wherein the first code data and the second code data comprise source code associated with the application, the first code data comprising either a submitted version or a test version of the source code, and the second code data comprising a development version of the source code.

11. An apparatus for managing code data, comprising: A receiving module is configured to receive a set of merge requests, the set of merge requests being used to merge first code data into second code data; A determination module is configured to, in response to determining that the set of merge requests meets predetermined conditions, determine whether there is an ongoing previous merge task, the previous merge task being executed based on a set of previous merge requests received prior to the set of merge requests; as well as An execution module is configured to perform a merge task based on the set of merge requests in response to determining that no previous merge task is in progress, so as to merge the differences between the first code data and the second code data into the second code data.

12. An electronic device, comprising: At least one processing unit; as well as At least one memory, coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 10 when executed by the at least one processing unit.

13. A computer-readable storage medium having a computer program stored thereon, the computer program causing the processor to implement the method according to any one of claims 1 to 10 when executed by a processor.

14. A computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1 to 10.

Images