Version control method, system and readable storage medium based on Git

Abstract

The embodiment of the present invention discloses a version control method, system and readable storage medium based on Git. The embodiment of the present invention receives an operation request sent by an application layer through a traffic reverse proxy, wherein the operation request has been annotated with information, and the information includes a code repository name; the traffic reverse proxy obtains the information; the traffic reverse proxy sends the information to a metadata management node; the traffic reverse proxy receives feedback information sent by the metadata management node, wherein the feedback information includes the port number of at least one Git node corresponding to the information; the traffic reverse proxy establishes a socket connection with the at least one Git node; the traffic reverse proxy sends the operation request to the at least one Git node; the traffic reverse proxy receives the processing result of the at least one Git node; the traffic reverse proxy sends the processing result to the application layer.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a version control method, system and readable storage medium based on Git. Background Art

[0002] Git is an open source distributed version control system that can manage project versions effectively and quickly. For example, the current mainstream solution for enterprise-level code hosting is to use Git for code version control. Git also has the advantages of distributed collaborative development, convenient and fast rollback of historical code, and high data security. It better meets the needs of small and medium-sized collaborative development and continuous integration / continuous delivery enterprises.

[0003] In the existing technology, Git is installed on a single machine to serve users and implement code hosting services, but the storage capacity and computing power are limited by the single machine. The large-scale collaborative development required by enterprises requires the ability to store massive amounts of code and high concurrent processing capabilities. Due to the constraints of the single machine's storage limit and computing resources, Git installed on a single machine can no longer meet the needs of enterprises.

[0004] In summary, based on Git installed on a single machine, how to achieve massive code storage and high-concurrency processing is a problem that needs to be solved at present. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a version control method, system and readable storage medium based on Git, which can realize massive code storage and high-concurrency processing.

[0006] In a first aspect, an embodiment of the present invention provides a Git-based version control system method, which is applied to a traffic reverse proxy, and the method includes: receiving an operation request sent by an application layer, wherein the operation request has been annotated with information, and the annotated information includes a code repository name; sending the information to a metadata management node; receiving feedback information sent by the metadata management node, wherein the feedback information includes a port number of at least one Git node corresponding to the information; establishing a socket connection with the at least one Git node; sending the operation request to the at least one Git node; receiving a processing result of the at least one Git node; and sending the processing result to the application layer.

[0007] Preferably, the operation request includes a code merge operation request and a code fork operation request.

[0008] In second aspect, an embodiment of the present invention provides a Git-based version control method, which is applied to the application layer, and the method includes: receiving an operation request sent by a user; annotating the operation request with information, wherein the information includes the name of the code repository; sending the operation request to a traffic reverse proxy; and receiving the processing result sent by the traffic reverse proxy.

[0009] Preferably, the method further comprises: encapsulating the operation request through GRPC.

[0010] Preferably, the information marking of the operation request specifically includes: the application layer marking the metadata of the operation request.

[0011] Preferably, the method further comprises: saving the processing result.

[0012] In the third aspect, an embodiment of the present invention provides a Git-based version control method, which is applied to a metadata management node, and the method includes: receiving information sent by a traffic reverse proxy, wherein the information includes a code repository name; determining at least one Git node corresponding to the information based on the information; generating feedback information, wherein the feedback information includes a port number of at least one Git node corresponding to the information; and sending the feedback information to the traffic reverse proxy.

[0013] Preferably, determining at least one Git node corresponding to the information according to the information specifically includes: searching topology information and lineage library according to the code repository name, and determining at least one Git node corresponding to the code repository name.

[0014] Preferably, the method further comprises: updating the kinship library.

[0015] Preferably, the method further comprises: receiving registration information sent by a newly registered Git node, wherein the registration information comprises a port number of the newly registered Git node.

[0016] Preferably, the method further comprises: determining the bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; and sending the bloodline information to the distributed system where the Git nodes are located.

[0017] In a fourth aspect, an embodiment of the present invention provides a Git-based version control method, which is applied to a Git node. The method includes: receiving an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name; processing according to the operation request; and sending the processing result to the traffic reverse proxy.

[0018] Preferably, processing according to the operation request specifically includes: creating a code repository according to the operation request; or merging a code repository according to the operation request.

[0019] Preferably, the method further comprises: migrating the code repository to other Git nodes, wherein writing to the code repository is prohibited during the migration process; and deleting the code repository in response to completion of the migration.

[0020] Preferably, the method further comprises: in response to the Git node being a newly registered Git node, sending registration information to a metadata management node.

[0021] Preferably, the method further comprises: receiving the code repository sent by the other Git node, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

[0022] In a fifth aspect, an embodiment of the present invention provides a version control system based on Git, the system comprising: an application layer, a traffic reverse proxy, a metadata management node and a distributed system comprising at least one Git node, wherein the application layer is used to receive an operation request sent by a user, send the operation request to the traffic reverse proxy and annotate information for the operation request; the traffic reverse proxy is used to receive the operation request, obtain the information, send the information to the metadata management node, establish a socket connection with at least one Git node corresponding to the feedback information according to the feedback information of the metadata management node, send the operation request to the at least one Git node, receive the processing result of the at least one Git node, and send the processing result to the application layer; the metadata management node is used to determine at least one Git node corresponding to the information according to the information, and send the feedback information to the traffic reverse proxy; the distributed system comprises at least one Git node, the Git node is used to receive the operation request, process according to the operation request, and send the processing result to the traffic reverse proxy.

[0023] Preferably, the application layer includes a traffic annotation module for annotating information on metadata in the operation request.

[0024] Preferably, the traffic reverse proxy includes a traffic calculation module and a lineage registration module, wherein the traffic calculation module is used to forward the operation request according to the frame granularity; the lineage registration module is used to record the lineage relationship of the code repository included in at least one Git node.

[0025] Preferably, the metadata management node includes a lineage library module and a service discovery module, wherein the lineage library module is used to store all lineage relationships of the code repositories included in the at least one Git node, and the service discovery module is used to record each of the Git nodes and the code repositories stored on each of the Git nodes.

[0026] Preferably, the distributed system also includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the at least one Git node, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol.

[0027] In the sixth aspect, an embodiment of the present invention provides a version control device based on Git, the device comprising: a first receiving unit, used to receive an operation request sent by an application layer, wherein the operation request has been annotated with information, and the annotated information includes a code repository name; a first sending unit, sending the information to a metadata management node; the first receiving unit is also used to receive feedback information sent by the metadata management node, wherein the feedback information includes the port number of at least one Git node corresponding to the information; a first processing unit, used to establish a socket connection with the at least one Git node; the first sending unit is also used to send the operation request to the at least one Git node; the first receiving unit is also used to receive the processing result of the at least one Git node; the first sending unit is also used to send the processing result to the application layer.

[0028] Preferably, the operation request includes a code merge operation request and a code fork operation request.

[0029] In the seventh aspect, an embodiment of the present invention provides a Git-based version control device, which includes: a second receiving unit, used to receive an operation request sent by a user; a second processing unit, used to annotate the operation request with information, wherein the information includes the name of the code repository; a second sending unit, the application layer sends the operation request to the traffic reverse proxy; the second receiving unit, used to receive the processing result sent by the traffic reverse proxy.

[0030] Preferably, the second processing unit is further used to encapsulate the operation request through GRPC.

[0031] Preferably, the second processing unit is specifically used to: perform information annotation on the metadata of the operation request.

[0032] Preferably, the device further comprises: a second saving unit, configured to save the processing result.

[0033] In the eighth aspect, an embodiment of the present invention provides a Git-based version control device, which includes: a third receiving unit, used to receive information sent by a traffic reverse proxy, wherein the information includes a code repository name; a third processing unit, used to determine at least one Git node corresponding to the information based on the information; a third generating unit, used to generate feedback information, wherein the feedback information includes the port number of at least one Git node corresponding to the information; and a third sending unit, used to send the feedback information to the traffic reverse proxy.

[0034] Preferably, the third determination unit is specifically used to: search for topology information and a lineage library according to the code repository name, and determine at least one Git node corresponding to the code repository name.

[0035] Preferably, the device further comprises: a third updating unit, used for updating the bloodline library.

[0036] Preferably, the third receiving unit is further used for: receiving registration information sent by a newly registered Git node, wherein the registration information includes a port number of the newly registered Git node.

[0037] Preferably, the third determining unit is further used to: determine the lineage information in the lineage library, wherein the lineage information includes all Git nodes with lineage relationships; and the third sending unit is further used to send the lineage information to the distributed system where the Git node is located.

[0038] In the ninth aspect, an embodiment of the present invention provides a version control device based on Git, which includes: a fourth receiving unit, used to receive an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name; a fourth processing unit, used to perform processing according to the operation request; and a fourth sending unit, used to send the processing result to the traffic reverse proxy.

[0039] Preferably, the fourth processing unit is specifically used to: create a code repository according to the operation request; or merge a code repository according to the operation request.

[0040] Preferably, the fourth processing unit is further used to: migrate the code repository to other Git nodes, wherein writing to the code repository is prohibited during the migration process; and delete the code repository in response to completion of the migration.

[0041] Preferably, the fourth sending unit is further used for: in response to the Git node being a newly registered Git node, sending registration information to the metadata management node.

[0042] Preferably, the fourth receiving unit is further used for: receiving the code repository sent by the other Git node, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

[0043] In a tenth aspect, an embodiment of the present invention provides a computer-readable storage medium having a storage medium

[0044] The computer program instructions are stored, and when the computer program instructions are executed by a processor, they implement a method as described in the first aspect, or any possible one of the first aspect, the second aspect, or any possible one of the second aspect, the third aspect, or any possible one of the third aspect, the fourth aspect, or any possible one of the fourth aspect.

[0045] In the eleventh aspect, an embodiment of the present invention provides an electronic device, comprising a memory and a processor, the memory being used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement a method as described in the first aspect, or any possible embodiment of the first aspect, the second aspect, or any possible embodiment of the second aspect, the third aspect, or any possible embodiment of the third aspect, the fourth aspect, or any possible embodiment of the fourth aspect.

[0046] The embodiment of the present invention receives an operation request sent by the application layer, wherein the operation request has been annotated with information, and the annotated information includes the name of the code repository; sends the information to the metadata management node; receives feedback information sent by the metadata management node, wherein the feedback information includes the port number of at least one Git node corresponding to the information; establishes a socket connection with the at least one Git node; sends the operation request to the at least one Git node; receives the processing result of the at least one Git node; and sends the processing result to the application layer. Through the above method, after the traffic reverse proxy receives the operation request sent by the application layer, it obtains the port number of at least one Git node through the metadata management node, and sends the operation request to the at least one Git node for processing. In a high concurrency scenario, the corresponding at least one Git node can be determined separately for concurrent processing; and multiple Git nodes can realize the storage of massive amounts of code. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The above and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0048] Figure 1 is a schematic diagram of a Git-based version control system according to a first embodiment of the present invention;

[0049] Figure 2is a flow chart of a version control method based on Git according to a second embodiment of the present invention;

[0050] Figure 3 is a flow chart of a version control method based on Git according to a third embodiment of the present invention;

[0051] Figure 4 is a flow chart of a version control method based on Git according to a third embodiment of the present invention;

[0052] Figure 5 is a flow chart of a version control method based on Git according to a third embodiment of the present invention;

[0053] Figure 6 is a flow chart of a version control method based on Git according to a fourth embodiment of the present invention;

[0054] Figure 7 is a flow chart of a version control method based on Git according to a fifth embodiment of the present invention;

[0055] Figure 8 is a flow chart of a version control method based on Git according to a sixth embodiment of the present invention;

[0056] Fig. 9 is a schematic diagram of interaction of a version control system based on Git according to a sixth embodiment of the present invention;

[0057] Fig.10 is a flow chart of a version control method based on Git according to a seventh embodiment of the present invention;

[0058] Fig.11 is a schematic diagram of a version control device based on Git according to an eighth embodiment of the present invention;

[0059] Fig.12 is a schematic diagram of a version control device based on Git according to a ninth embodiment of the present invention;

[0060] Fig.13 is a schematic diagram of a version control device based on Git according to a tenth embodiment of the present invention;

[0061] Fig.14 is a schematic diagram of a version control device based on Git according to an eleventh embodiment of the present invention;

[0062] Fig.15 is a schematic diagram of an electronic device according to a twelfth embodiment of the present invention. DETAILED DESCRIPTION

[0063] The present invention is described below based on the embodiments, but the present invention is not limited to these embodiments. In the detailed description of the present invention below, some specific details are described in detail. It is possible for a person skilled in the art to fully understand the present invention without the description of these details. In order to avoid confusing the essence of the present invention, known methods, processes, procedures, components and circuits are not described in detail.

[0064] In addition, persons of ordinary skill in the art will appreciate that the drawings provided herein are for illustration purposes and are not necessarily drawn to scale.

[0065] Unless the context clearly requires otherwise, the words "include", "comprising" and similar words throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, the meaning is "including but not limited to".

[0066] In the description of the present invention, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and cannot be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" is two or more.

[0067] Usually in the prior art, Git is installed on a single machine to serve users and implement code hosting services, but the rapidly growing code is restricted by storage capacity and cannot implement the storage of massive code; Git's concurrent processing capability is limited by computing power and cannot implement large-scale concurrent processing, while large-scale collaborative development in the enterprise's demands requires the ability to store massive code and high concurrent processing capabilities, which are restricted by the upper limit of single-machine storage and computing resources. Git installed on a single machine can no longer meet the demands of enterprises. In order to solve the problems existing in the prior art, an embodiment of the present invention proposes a version control system based on Git to achieve massive code storage and high concurrent processing.

[0068] Figure 1 Schematic diagram of a Git-based version control system according to the first embodiment of the present invention. Figure 1As shown, the Git-based version control system includes: an application layer 101, a traffic reverse proxy 102, a metadata management node 103 and a distributed system 104 including at least one Git node, wherein the application layer is used to receive an operation request sent by a user, send the operation request to the traffic reverse proxy and annotate information for the operation request; the traffic reverse proxy is used to receive the operation request, obtain the information, send the information to the metadata management node, establish a socket connection with at least one Git node corresponding to the feedback information according to the feedback information of the metadata management node, send the operation request to the at least one Git node, receive the processing result of the at least one Git node, and send the processing result to the application layer; the metadata management node is used to determine at least one Git node corresponding to the information according to the information, and send the feedback information to the traffic reverse proxy; the distributed system includes at least one Git node, and the Git node is used to receive the operation request, process according to the operation request, and send the processing result to the traffic reverse proxy.

[0069] In a possible implementation, the application layer 101 includes a traffic marking module 1011 for marking metadata in the operation request.

[0070] In one possible implementation, the traffic reverse proxy 102 includes a traffic calculation module 1021 and a lineage registration module 1022, wherein the traffic calculation module is used to forward the operation request according to the frame granularity; the lineage registration module is used to record the lineage relationship of the code repository included in at least one Git node.

[0071] In one possible implementation, the metadata management node 103 includes a lineage library module 1031 and a service discovery module 1032, wherein the lineage library module is used to store all lineage relationships of the code repositories included in the at least one Git node, and the service discovery module is used to record each of the Git nodes and the code repositories stored on each of the Git nodes.

[0072] In one possible implementation, there are multiple Git nodes, and multiple Git nodes form a distributed system. In an embodiment of the present invention, the distributed system 104 can expand the capabilities of a single Git point to multiple Git nodes. The distributed system 104 also includes a traffic processing module 1041, a service registration module 1042 and a multi-copy management module 1043, wherein the traffic processing module is used to balance the load of multiple Git nodes, the service registration module is used to register new Git nodes, and the multi-copy management module implements the management of multiple copies based on the Raft protocol, thereby systematically realizing the storage and high-concurrency processing of massive codes.

[0073] In the embodiment of the present invention, different steps are performed in different operation processes through the application layer, traffic reverse proxy, metadata management node and distributed system in the above-mentioned Git-based version control system.

[0074] In the embodiment of the present invention, Figure 2 : is a flow chart of the Git-based version control method according to the second embodiment of the present invention. Figure 2 As shown, the specific steps of traffic reverse proxy are as follows:

[0075] Step S200: The traffic reverse proxy receives an operation request sent by the application layer, wherein the operation request has been annotated with information, and the annotated information includes a code repository name.

[0076] In a possible implementation, the operation request includes a code merge operation request and a code fork operation request. Optionally, the above operation request also includes a rename operation request, a transfer operation request, etc. The present invention is an embodiment and does not limit it, and it is specifically determined according to the user's operation request.

[0077] Step S201: The traffic reverse proxy sends the information to the metadata management node.

[0078] Step S202: The traffic reverse proxy receives feedback information sent by the metadata management node, wherein the feedback information includes the port number of at least one Git node corresponding to the information.

[0079] Step S203: The traffic reverse proxy establishes a socket connection with the at least one Git node.

[0080] Step S204: The traffic reverse proxy sends the operation request to the at least one Git node.

[0081] Step S205: The traffic reverse proxy receives the processing result of the at least one Git node.

[0082] Step S206: The traffic reverse proxy sends the processing result to the application layer.

[0083] Optionally, after step S200, the method further includes: the traffic reverse proxy obtains the information.

[0084] In the embodiment of the present invention, Figure 3 : is a flow chart of a Git-based version control method according to the third embodiment of the present invention. Figure 3 As shown, the specific steps of the application layer are as follows:

[0085] Step S300: The application layer receives an operation request sent by a user.

[0086] Step S301: The application layer annotates the operation request with information, wherein the information includes a code repository name.

[0087] In a possible implementation manner, the application layer performs information annotation on the metadata of the operation request.

[0088] Step S302: The application layer sends the operation request to the traffic reverse proxy.

[0089] Step S303: The application layer receives the processing result sent by the traffic reverse proxy.

[0090] In one possible implementation, Figure 4 3 is a flow chart of a Git-based version control method according to a third embodiment of the present invention. After step S300, the method further includes:

[0091] Step S304: The application layer encapsulates the operation request through GRPC.

[0092] In a possible implementation, the GRPC is an open source remote procedure call system, and the operation request encapsulated by the GRPC can be called traffic.

[0093] In one possible implementation, Figure 5 3 is a flow chart of a version control method based on Git according to a third embodiment of the present invention. After step S303, the method further includes:

[0094] Step S305: The application layer saves the processing result.

[0095] In the embodiment of the present invention, Figure 6 4 is a flow chart of a Git-based version control method according to the fourth embodiment of the present invention. Figure 6 As shown, the specific steps of the metadata management node are as follows:

[0096] Step 600: The metadata management node receives information sent by the traffic reverse proxy, wherein the information includes the code repository name.

[0097] Step 601: The metadata management node determines at least one Git node corresponding to the information based on the information.

[0098] Step 602: The metadata management node generates feedback information, wherein the feedback information includes the port number of at least one Git node corresponding to the information.

[0099] In a possible implementation, the metadata management node searches for topology information and a lineage library according to the code repository name to determine at least one Git node corresponding to the code repository name.

[0100] Step 603: The metadata management node sends the feedback information to the traffic reverse proxy.

[0101] In a possible implementation, the method further includes: the metadata management node updating the bloodline library.

[0102] In a possible implementation, the method further includes: the metadata management node receiving registration information sent by the newly registered Git node, wherein the registration information includes the port number of the newly registered Git node.

[0103] In a possible implementation, the method further includes: the metadata management node determines the lineage information in the lineage library, wherein the lineage information includes all Git nodes with lineage relationships; and the metadata management node sends the lineage information to the distributed system where the Git node is located.

[0104] In the embodiment of the present invention, Figure 7 : is a flow chart of a version control method based on Git according to the fifth embodiment of the present invention. Figure 7 As shown, the specific steps of the Git node are as follows:

[0105] Step S700: The Git node receives an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name.

[0106] Step S701: The Git node processes according to the operation request.

[0107] In a possible implementation, the Git node creates a code repository according to the operation request; or, the Git node merges the code repository according to the operation request.

[0108] Step S702: The Git node sends the processing result to the traffic reverse proxy.

[0109] In a possible implementation, the method further includes: the Git node migrating the code repository to another Git node, wherein writing to the code repository is prohibited during the migration process; and in response to completion of the migration, the Git node deleting the code repository.

[0110] In a possible implementation, the method further includes: in response to the Git node being a newly registered Git node, the Git node sending registration information to the metadata management node.

[0111] In a possible implementation, the method further includes: the Git node receiving the code repository sent by the other Git nodes, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

[0112] In the embodiments of the present invention, the version control method based on Git is described in detail through the following three specific embodiments.

[0113] Specific embodiment 1: Figure 8 : is a flow chart of a version control method based on Git according to a sixth embodiment of the present invention, specifically, the specific steps of a version control system based on Git processing a code merge operation request issued by a user:

[0114] Step S800: The application layer receives a code merging operation request sent by a user.

[0115] Step S801: The application layer encapsulates the merge operation request through GRPC, and annotates the metadata of the merge operation request to generate GRPC traffic, wherein the information includes the code repository name.

[0116] Optionally, the information also includes parameters, branches, etc. The parameters, branches, and code repository name can trigger an asynchronous task through parsing, and the asynchronous task triggers the Git node to complete the code merge operation.

[0117] Step S802: The application layer sends the GRPC traffic to the traffic reverse proxy.

[0118] Step S803: The traffic reverse proxy receives the GRPC traffic.

[0119] Step S804: The traffic reverse proxy obtains the code repository name in the GRPC traffic.

[0120] Step S805: The traffic reverse proxy sends the code repository name to the metadata management node.

[0121] Step S806: The metadata management node receives the code repository name, searches for topology information and a lineage library according to the code repository name, and determines the port number of at least one Git node corresponding to the code repository name.

[0122] Step S807: The metadata management node sends the port number of the at least one Git node to the traffic reverse proxy.

[0123] Step S808: The traffic reverse proxy receives the port number of the at least one Git node.

[0124] Step S809: The traffic reverse proxy sends the GRPC traffic to the at least one Git node.

[0125] Step S810: The Git node performs a code merge operation according to the GRPC traffic to obtain a processing result.

[0126] Specifically, the Git node will migrate other code repositories with blood relationship obtained from the blood relationship library according to the topology information to the same Git node.

[0127] Step S811: The Git node sends the processing result to the traffic reverse proxy.

[0128] Step S812: The traffic reverse proxy receives the processing result.

[0129] Step S813: The traffic reverse proxy sends the processing result to the application layer.

[0130] Step S814: The application layer receives the processing result and saves the processing result.

[0131] Specifically, the application layer saves the merged code repository.

[0132] In the embodiment of the present invention, the above processing flow can also be Fig. 9 , the interaction diagram of each part in the Git-based version control system shows that, specifically, the application layer 101 sends business traffic to the traffic reverse proxy 101, the traffic reverse proxy 102 sends control traffic to the service discovery module 1032 in the metadata management node 103, the traffic reverse proxy 102 sends business traffic to multiple Git nodes; the Git node sends control traffic to the service discovery module 1032; wherein, the business traffic is an operation request, etc., and the control traffic is registration information, etc.

[0133] Specific embodiment 2: Fig.10 : is a flowchart of a version control method based on Git according to the seventh embodiment of the present invention, specifically, the specific steps of a version control system based on Git processing a code fork operation request issued by a user:

[0134] Step S1000: The application layer receives a code fork operation request sent by a user, where the code fork operation request is used to create a new code repository, wherein the fork operation request includes the name of the forked code repository.

[0135] Step S1001: The application layer sends the code fork operation request to the traffic reverse proxy.

[0136] Step S1002: The traffic reverse proxy receives the code fork operation request.

[0137] Step S1003: The traffic reverse proxy obtains the name of the forked code repository.

[0138] Step S1004: The traffic reverse proxy sends the forked code repository name to the metadata management node.

[0139] Step S1005: The metadata management node receives the name of the forked code repository, searches for topology information and a lineage library according to the code repository name, and determines the port number of the Git node where the forked code repository needs to be stored.

[0140] Optionally, the metadata management node updates the lineage library, and the port number of the Git node where the forked code repository needs to be stored can be the same as the Git node where the forked code repository is located.

[0141] In a possible implementation, code repositories with blood relationship are stored in the same Git node.

[0142] Step S1006: The metadata management node sends the port number of the Git node to the traffic reverse proxy.

[0143] Step S1007: The traffic reverse proxy receives the port number of the Git node.

[0144] Step S1008: The traffic reverse proxy sends the code fork operation request to the Git node.

[0145] Step S1009: The Git node creates a new code repository according to the code fork operation request.

[0146] Step S1010: The Git node sends the creation result to the traffic reverse proxy.

[0147] Step S1011: The traffic reverse proxy receives the creation result.

[0148] Step S1012: The traffic reverse proxy sends the creation result to the application layer.

[0149] Step S1013: The application layer receives the creation result and sends the creation result to the user.

[0150] In the above two specific embodiments, the Git node is transparent to the application layer, thereby achieving decoupling between the upper application layer and multiple Git nodes in the lower distributed system. Specific embodiment three:

[0152] When a Git-based version control system processes the addition of a new Git node, specific steps for traffic balancing are provided, wherein the above-mentioned traffic balancing can also be called load balancing, that is, migrating the code repository in the Git node with a larger load to the new Git node, as follows: the Git node sends registration information to the metadata management node, and at the same time, the distributed system of the Git node activates the traffic balancing service, wherein the Git node is a newly registered Git node, and the traffic balancing service automatically migrates the code repository in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration, and during the migration of the code repository, the traffic is blocked, that is, during the migration process, writing operations to the Git node are prohibited to ensure the consistency of the code data during the migration process; repeat the above-mentioned migration process, and when the traffic of the new Git node reaches 80% of the average traffic of other Git nodes, the automatic joining operation process of the new Git node is completed, that is, the migration of the code repository is completed, wherein the above-mentioned 80% is an exemplary description, and other data values ​​can also be used, which are not limited in the embodiments of the present invention.

[0153] Optionally, after completing the automatic joining process of the new Git node, lift the traffic ban, modify the calculation rules of the traffic calculation module in the traffic reverse proxy, and then take the data of the code repository in other Git nodes that have completed the migration offline, that is, delete the migrated code repository in the Git node where the migrated code repository originally existed.

[0154] In the above embodiment, during the migration period, users may obtain different access results when accessing or writing to the migrating code repository. In order to ensure the strong consistency of the code repository data, the migration window is in read-only mode, that is, it is blocked to ensure the consistency of code data during the migration process.

[0155] In one possible implementation, blood relationship refers to the association relationship between multiple code repositories. Due to the constraints of code merging operations between code repositories, code repositories with blood relationship need to be maintained in one node Git. When performing operations such as forking, renaming, and migration, blood relationship maintenance is required. Specifically, the repo information before modification is recorded in the blood relationship library as the ancestor node of the current node, wherein the repo information manages the code repositories in all Git nodes, and a blood relationship map is maintained in the blood relationship library. When migrating nodes, all code repository nodes with blood relationship are found in the blood relationship library, and the information of all blood relationship code repositories is migrated in turn to complete a migration process.

[0156] Fig.11 Schematic diagram of a Git-based version control device according to the eighth embodiment of the present invention. Fig.11 As shown, the apparatus of this embodiment includes a first receiving unit 1101 , a first sending unit 1102 and a first processing unit 1103 .

[0157] Among them, the first receiving unit 1101 is used to receive an operation request sent by the application layer, wherein the operation request has been annotated with information, and the information includes the name of the code repository; the first sending unit 1102 sends the information to the metadata management node; the first receiving unit 1101 is also used to receive feedback information sent by the metadata management node, wherein the feedback information includes the port number of at least one Git node corresponding to the information; the first processing unit 1103 is used to establish a socket connection with the at least one Git node; the first sending unit 1102 is also used to send the operation request to the at least one Git node; the first receiving unit 1101 is also used to receive the processing result of the at least one Git node; the first sending unit 1102 is also used to send the processing result to the application layer.

[0158] Furthermore, the operation request includes a code merge operation request and a code fork operation request.

[0159] Fig.12 Schematic diagram of a version control device based on Git according to the ninth embodiment of the present invention. Fig.12 As shown, the apparatus of this embodiment includes a second receiving unit 1201 , a second processing unit 1202 , and a second sending unit 1203 .

[0160] Among them, the second receiving unit 1201 is used to receive an operation request sent by a user; the second processing unit 1202 is used to annotate the operation request with information, wherein the information includes the code repository name; the second sending unit 1203, the application layer sends the operation request to the traffic reverse proxy; the second receiving unit 1201 is used to receive the processing result sent by the traffic reverse proxy.

[0161] Furthermore, the second processing unit 1202 is also used to encapsulate the operation request through GRPC.

[0162] Furthermore, the second processing unit 1202 is specifically configured to: perform information annotation on the metadata of the operation request.

[0163] Furthermore, the device also includes: a second storage unit, used to store the processing result.

[0164] Fig.13 Schematic diagram of a version control device based on Git according to the tenth embodiment of the present invention. Fig.13 As shown, the apparatus of this embodiment includes a third receiving unit 1301 , a third processing unit 1302 , a third generating unit 1303 and a third sending unit 1304 .

[0165] Among them, the third receiving unit 1301 is used to receive information sent by the traffic reverse proxy, wherein the information includes the code repository name; the third processing unit 1302 is used to determine at least one Git node corresponding to the information based on the information; the third generating unit 1303 is used to generate feedback information, wherein the feedback information includes the port number of at least one Git node corresponding to the information; the third sending unit 1304 is used to send the feedback information to the traffic reverse proxy.

[0166] Furthermore, the third determination unit is specifically used to: search for topology information and a lineage library according to the code repository name, and determine at least one Git node corresponding to the code repository name.

[0167] Furthermore, the device also includes: a third updating unit, used for updating the bloodline library.

[0168] Furthermore, the third receiving unit is further used to: receive registration information sent by a newly registered Git node, wherein the registration information includes a port number of the newly registered Git node.

[0169] Furthermore, the third determination unit is also used to: determine the lineage information in the lineage library, wherein the lineage information includes all Git nodes with lineage relationships; and the third sending unit is also used to send the lineage information to the distributed system where the Git node is located.

[0170] Fig.14 Schematic diagram of a version control device based on Git according to the eleventh embodiment of the present invention. Fig.14 As shown, the apparatus of this embodiment includes a fourth receiving unit 1401 , a fourth processing unit 1402 and a fourth sending unit 1403 .

[0171] Among them, the fourth receiving unit 1401 is used to receive an operation request, wherein the operation request has been annotated with information, and the information includes the code repository name; the fourth processing unit 1402 is used to process according to the operation request; the fourth sending unit 1403 is used to send the processing result to the traffic reverse proxy.

[0172] Further, the fourth processing unit is specifically used to: create a code repository according to the operation request; or merge a code repository according to the operation request.

[0173] Furthermore, the fourth processing unit is also used to: migrate the code repository to other Git nodes, wherein writing to the code repository is prohibited during the migration process; and delete the code repository in response to completion of the migration.

[0174] Furthermore, the fourth sending unit is further used to: in response to the Git node being a newly registered Git node, send registration information to the metadata management node.

[0175] Furthermore, the fourth receiving unit is further used to: receive the code repository sent by the other Git node, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

[0176] Fig.15 1 is a schematic diagram of an electronic device according to the twelfth embodiment of the present invention. In this embodiment, the electronic device is a server. It should be understood that it can also be other electronic devices, such as a Raspberry Pi. Fig.15As shown, the electronic device: includes at least one processor 1501; and a memory 1502 that is communicatively connected to at least one processor 1501; and a communication component 1503 that is communicatively connected to a scanning device, and the communication component 1503 receives and sends data under the control of the processor 1501; wherein the memory 1502 stores instructions that can be executed by at least one processor 1501, and the instructions are executed by at least one processor 1501 to implement: the traffic reverse proxy receives an operation request sent by an application layer, wherein the operation request has been annotated with information, and the information includes a code repository name; the traffic reverse proxy obtains the information; the traffic reverse proxy sends the information to a metadata management node; the traffic reverse proxy receives feedback information sent by the metadata management node, wherein the feedback information includes a port number of at least one Git node corresponding to the information; the traffic reverse proxy establishes a socket connection with the at least one Git node; the traffic reverse proxy sends the operation request to the at least one Git node; the traffic reverse proxy receives the processing result of the at least one Git node; the traffic reverse proxy sends the processing result to the application layer.

[0177] Furthermore, the operation request includes a code merge operation request and a code fork operation request.

[0178] Furthermore, the processor is also used to execute: the application layer receives an operation request sent by a user; the application layer annotates information on the operation request, wherein the information includes a code repository name; the application layer sends the operation request to a traffic reverse proxy; the application layer receives a processing result sent by the traffic reverse proxy.

[0179] Furthermore, the processor is also used to execute: the application layer encapsulates the operation request through GRPC.

[0180] Furthermore, the processor is specifically configured to execute: the application layer performs information annotation on metadata of the operation request.

[0181] Furthermore, the processor is further configured to execute: the application layer saves the processing result.

[0182] Furthermore, the processor is also used to execute: the metadata management node receives information sent by the traffic reverse proxy, wherein the information includes the name of the code repository; the metadata management node determines at least one Git node corresponding to the information based on the information; the metadata management node generates feedback information, wherein the feedback information includes the port number of at least one Git node corresponding to the information; the metadata management node sends the feedback information to the traffic reverse proxy.

[0183] Furthermore, the processor is specifically used to execute: the metadata management node searches for topology information and a lineage library according to the code repository name, and determines at least one Git node corresponding to the code repository name.

[0184] Furthermore, the processor is also used to execute: the metadata management node updates the bloodline library.

[0185] Furthermore, the processor is further configured to execute: the metadata management node receives registration information sent by a newly registered Git node, wherein the registration information includes a port number of the newly registered Git node.

[0186] Furthermore, the processor is also used to execute: the metadata management node determines the lineage information in the lineage library, wherein the lineage information includes all Git nodes with lineage relationships; the metadata management node sends the lineage information to the distributed system where the Git node is located.

[0187] Furthermore, the processor is also used to execute: the Git node receives an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name; the Git node processes according to the operation request; and the Git node sends the processing result to the traffic reverse proxy.

[0188] Furthermore, the processor is specifically used to execute: the Git node creates a code repository according to the operation request; or the Git node merges the code repository according to the operation request.

[0189] Furthermore, the processor is also used to execute: the Git node migrates the code repository to other Git nodes, wherein writing to the code repository is prohibited during the migration process; in response to the completion of the migration, the Git node deletes the code repository.

[0190] Furthermore, the processor is further configured to execute: in response to the Git node being a newly registered Git node, the Git node sending registration information to a metadata management node.

[0191] Furthermore, the processor is also used to execute: the Git node receives the code repository sent by the other Git nodes, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

[0192] Specifically, the electronic device includes: one or more processors 1501 and a memory 1502, Fig.15A processor 1501 is taken as an example. The processor 1501 and the memory 1502 may be connected via a bus or other means. Fig.15 In the example, the bus connection is used. The memory 1502 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The processor 1501 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions and modules stored in the memory 1502, that is, the above-mentioned Git-based version control method is implemented.

[0193] The memory 1502 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store a list of options, etc. In addition, the memory 1502 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 1502 may optionally include a memory remotely arranged relative to the processor 1501, and these remote memories may be connected to an external device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0194] One or more modules are stored in the memory 1502, and when executed by one or more processors 1501, the Git-based version control method in any of the above method embodiments is executed.

[0195] The above-mentioned product can execute the method provided in the embodiment of the present application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of the present application.

[0196] A thirteenth embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program, wherein the computer-readable program is used for a computer to execute part or all of the above method embodiments.

[0197] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0198] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present invention, and that in actual applications, various changes may be made in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A version control method based on Git, characterized in that: The method includes: Receive an operation request sent by the application layer, wherein the operation request has been annotated with information, and the annotated information includes a code repository name, and the code repository name is used to find topology information and a lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotation process specifically encapsulates the operation request through GRPC, and annotates the metadata of the operation request with information to generate GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; Sending the information to a metadata management node; Receive feedback information sent by the metadata management node, wherein the feedback information includes port numbers of multiple Git nodes corresponding to the information; Establishing a socket connection with the plurality of Git nodes; Sending the operation request to the multiple Git nodes; Receiving processing results of the multiple Git nodes; The processing result is sent to the application layer.

2. The method according to claim 1, characterized in that The operation request includes a code merge operation request and a code fork operation request.

3. A version control method based on Git, characterized in that: The method includes: Receive operation requests sent by users; The operation request is annotated with information, wherein the information includes a code repository name, the code repository name is used to find topology information and lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotation process specifically encapsulates the operation request through GRPC, annotates the metadata of the operation request with information, and generates GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; Sending the operation request to the traffic reverse proxy; Receive the processing result sent by the traffic reverse proxy.

4. The method according to claim 3, characterized in that The method further includes: The processing result is saved.

5. A version control method based on Git, characterized in that: The method includes: Receive information sent by a traffic reverse proxy, wherein the information includes a code repository name, the code repository name is used to find topology information and a lineage library, the code repository name corresponds to multiple Git nodes, wherein the lineage library is used to determine the lineage information in the lineage library, wherein the lineage information includes all Git nodes with a lineage relationship; send the lineage information to the distributed system where the Git node is located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; Determine, according to the information, a plurality of Git nodes corresponding to the information; Generate feedback information, wherein the feedback information includes port numbers of multiple Git nodes corresponding to the information; The feedback information is sent to the traffic reverse proxy.

6. The method according to claim 5, characterized in that Determining multiple Git nodes corresponding to the information according to the information specifically includes: The topology information and the lineage library are searched according to the code repository name to determine multiple Git nodes corresponding to the code repository name.

7. The method according to claim 5, characterized in that The method further includes: Update the bloodline database.

8. The method according to claim 5, characterized in that The method further includes: Receive registration information sent by a newly registered Git node, wherein the registration information includes a port number of the newly registered Git node.

9. A version control method based on Git, characterized in that: The method includes: Receive an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name, the code repository name is used to find topology information and a lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotation process specifically encapsulates the operation request through GRPC, annotates the metadata of the operation request with information, and generates GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; Processing according to the operation request; Send the processing results to the traffic reverse proxy.

10. The method according to claim 9, characterized in that Processing is performed according to the operation request, specifically including: Create a code repository according to the operation request; or, Merge the code repository according to the operation request.

11. The method according to claim 9, characterized in that The method further includes: Migrate the code repository to another Git node, wherein the code repository is prohibited from being written during the migration process; In response to the completion of the migration, the code repository is deleted.

12. The method according to claim 9, characterized in that The method further includes: In response to the Git node being a newly registered Git node, registration information is sent to the metadata management node.

13. The method according to claim 12, characterized in that The method further includes: Receive a code repository sent by another Git node, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

14. A version control system based on Git, characterized in that: The system includes: an application layer, a traffic reverse proxy, a metadata management node and a distributed system including multiple Git nodes, wherein the application layer is used to receive an operation request sent by a user, send the operation request to the traffic reverse proxy and mark the operation request with information, the marked information includes a code repository name, the code repository name is used to find topology information and a lineage library, the code repository name corresponds to multiple Git nodes, wherein the information marking process is specifically to encapsulate the operation request through GRPC, and mark the metadata of the operation request with information to generate GRPC traffic; wherein the lineage library is used to determine the lineage information in the lineage library, wherein the lineage information includes all Git nodes with lineage relationships; the lineage information is sent to the distributed system where the Git node is located; wherein the distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, and the service registration module is used to register a new Git node, The multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; the traffic reverse proxy is used to receive the operation request, obtain the information, send the information to the metadata management node, establish a socket connection with the multiple Git nodes corresponding to the feedback information according to the feedback information of the metadata management node, send the operation request to the multiple Git nodes, receive the processing results of the multiple Git nodes, and send the processing results to the application layer; the metadata management node is used to determine the multiple Git nodes corresponding to the information according to the information, and send the feedback information to the traffic reverse proxy; the distributed system includes multiple Git nodes, and the Git nodes are used to receive the operation request, process according to the operation request, and send the processing results to the traffic reverse proxy.

15. The system of claim 14, wherein: The traffic reverse proxy includes a traffic calculation module and a lineage registration module, wherein the traffic calculation module is used to forward the operation request according to the frame granularity; the lineage registration module is used to record the lineage relationship of the code repositories included in multiple Git nodes.

16. The system of claim 14, wherein: The metadata management node includes a lineage library module and a service discovery module, wherein the lineage library module is used to store all lineage relationships of the code repositories included in the multiple Git nodes, and the service discovery module is used to record each of the Git nodes and the code repositories stored on each of the Git nodes.

17. A version control device based on Git, characterized in that: The device includes: A first receiving unit is used to receive an operation request sent by an application layer, wherein the operation request has been annotated with information, and the information annotated during the information annotating includes a code repository name, and the code repository name is used to find topology information and a lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotating process specifically encapsulates the operation request through GRPC, and annotates the metadata of the operation request with information to generate GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; A first sending unit sends the information to a metadata management node; The first receiving unit is further used to receive feedback information sent by the metadata management node, wherein the feedback information includes port numbers of multiple Git nodes corresponding to the information; A first processing unit, configured to establish a socket connection with the plurality of Git nodes; The first sending unit is further used to send the operation request to the multiple Git nodes; The first receiving unit is further used to receive processing results of the multiple Git nodes; The first sending unit is further used to send the processing result to the application layer.

18. The device according to claim 17, characterized in that The operation request includes a code merge operation request and a code fork operation request.

19. A version control device based on Git, characterized in that: The device includes: A second receiving unit, used to receive an operation request sent by a user; A second processing unit is used to annotate the operation request with information, wherein the information includes a code repository name, the code repository name is used to find topology information and a lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotation process specifically encapsulates the operation request through GRPC, annotates the metadata of the operation request with information, and generates GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; A second sending unit, the application layer sends the operation request to the traffic reverse proxy; The second receiving unit is used to receive the processing result sent by the traffic reverse proxy.

20. The device according to claim 19, characterized in that The device also includes: The second storage unit is used to store the processing result.

21. A version control device based on Git, characterized in that: The device includes: A third receiving unit is used to receive information sent by the traffic reverse proxy, wherein the information includes a code repository name, the code repository name is used to find topology information and a lineage library, the code repository name corresponds to multiple Git nodes, wherein the lineage library is used to determine the lineage information in the lineage library, wherein the lineage information includes all Git nodes with a lineage relationship; the lineage information is sent to the distributed system where the Git node is located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; A third processing unit, configured to determine, according to the information, a plurality of Git nodes corresponding to the information; A third generating unit is used to generate feedback information, wherein the feedback information includes port numbers of multiple Git nodes corresponding to the information; The third sending unit is used to send the feedback information to the traffic reverse proxy.

22. The device according to claim 21, characterized in that The device also includes: The third updating unit is used to update the bloodline database.

23. The device according to claim 21, characterized in that The third receiving unit is further used for: Receive registration information sent by a newly registered Git node, wherein the registration information includes a port number of the newly registered Git node.

24. A version control device based on Git, characterized in that: The device includes: A fourth receiving unit is used to receive an operation request, wherein the operation request has been annotated with information, and the information includes a code repository name, the code repository name is used to find topology information and a lineage library, and the code repository name corresponds to multiple Git nodes, wherein the information annotation process specifically encapsulates the operation request through GRPC, and annotates the metadata of the operation request with information to generate GRPC traffic; The bloodline library is used to determine bloodline information in the bloodline library, wherein the bloodline information includes all Git nodes with bloodline relationships; the bloodline information is sent to the distributed system where the Git nodes are located; The distributed system includes a traffic processing module, a service registration module and a multi-copy management module, wherein the traffic processing module is used to balance the load of the multiple Git nodes, the service registration module is used to register a new Git node, and the multi-copy management module implements multi-copy management based on the Raft protocol, wherein the traffic balancing service of the traffic processing module is to automatically migrate the code repositories in the active nodes of other Git nodes to the new Git node in proportion; during the migration process, it is necessary to query the lineage library in the metadata node to determine the scope of migration; a fourth processing unit, configured to perform processing according to the operation request; The fourth sending unit is used to send the processing result to the traffic reverse proxy.

25. The device according to claim 24, characterized in that The fourth processing unit is specifically configured to: Create a code repository according to the operation request; or, Merge the code repository according to the operation request.

26. The device according to claim 24, characterized in that The fourth processing unit is further configured to: Migrate the code repository to another Git node, wherein the code repository is prohibited from being written during the migration process; In response to the completion of the migration, the code repository is deleted.

27. The device according to claim 24, characterized in that The fourth sending unit is further used for: In response to the Git node being a newly registered Git node, registration information is sent to the metadata management node.

28. The device according to claim 27, characterized in that The fourth receiving unit is further used for: Receive a code repository sent by another Git node, wherein the code repository is prohibited from being written during the migration process, and the code repository migrated to the Git node has a blood relationship.

29. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: The computer program instructions, when executed by a processor, implement the method according to any one of claims 1 to 13.

30. An electronic device comprising a memory and a processor, characterized in that: The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method according to any one of claims 1-13.

Images