Data synchronization method, device and equipment for enterprise code warehouse and storage medium

Abstract

The invention discloses a data synchronization method and device for an enterprise code warehouse, equipment and a storage medium, is applied to an independently deployed intermediate server, and relates to the technical field of computers, and the method comprises the following steps: analyzing a first notification event of a first code warehouse to obtain first target data; obtaining a temporary token corresponding to the first code warehouse based on a preset authorization protocol, determining first modification content corresponding to the first notification event by using the temporary token, converting the first modification content into target content, and judging whether a second notification event corresponding to the target content exists in a second code warehouse based on the distributed lock; and if the second modification content of the second notification event exists and a conflict exists between the second modification content of the second notification event and the first modification content, processing the target position with the conflict by using a preset conflict processing strategy, and synchronizing the obtained synchronization data to a second code warehouse to complete a corresponding data synchronization operation. And the efficiency of bidirectional data synchronization from GitLab to Gitea is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for synchronizing data in an enterprise code repository. Background Technology

[0002] In software development, GitLab and Gitea, as mainstream code repository management systems, are frequently used by enterprises in various scenarios (such as main and backup repositories, cross-platform collaboration). Existing mirror synchronization methods cannot automatically resolve code conflicts when GitLab and Gitea simultaneously commit code to the same repository and development branch, requiring manual intervention. Furthermore, this method is highly prone to circular synchronization, which leads to the system continuously attempting to merge conflicts. Improper conflict resolution can generate a large number of compatible or similar merge commits, causing a surge in server load and significantly impacting data synchronization efficiency. Moreover, existing synchronization methods can only synchronize code branches / commits, failing to synchronize metadata such as issues / tickets, project personnel, and permissions.

[0003] As can be seen from the above, improving the efficiency of bidirectional data synchronization between GitLab and Gitea and preventing conflicts from causing server load are urgent problems to be solved. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a data synchronization method, apparatus, device, and storage medium for enterprise code repositories, which can improve the efficiency of bidirectional data synchronization from GitLab to Gitea and prevent conflicts from causing server load. The specific solution is as follows:

[0005] Firstly, this application provides a data synchronization method for an enterprise code repository, applied to an independently deployed intermediate server, comprising:

[0006] Obtain the first notification event of the first code repository, parse the first notification event to obtain first target data including the first commit hash, the first Git branch name and the first operation type;

[0007] A temporary token corresponding to the first code repository is obtained based on a preset authorization protocol. The temporary token is used to determine the first modified content corresponding to the first notification event. The first modified content is converted into target content using the target mapping relationship between the first code repository and the second code repository. A distributed lock is used to determine whether there is a second notification event corresponding to the target content in the second code repository.

[0008] If a second notification event exists in the second code repository that matches the first target data, and the second modification content corresponding to the second notification event conflicts with the first modification content, then a preset conflict handling strategy is used to process the conflicting target location to obtain synchronized data, and the synchronized data is synchronized to the second code repository to complete the corresponding data synchronization operation.

[0009] Optionally, before obtaining the first notification event of the first code repository, the method further includes:

[0010] Register a first network hook and a second network hook based on the first code repository and the second code repository respectively, and add the receiving notification address corresponding to the intermediate server using the first network hook and the second network hook;

[0011] Based on the first network hook and the network hook respectively sending the first test information and the second test information to the intermediate server, if the intermediate server receives the first test information and the second test information, it indicates that the first network hook and the second network hook have been successfully installed;

[0012] Configure the first application key corresponding to the first code repository and the second application key corresponding to the second code repository on the intermediate server.

[0013] Optionally, obtaining the first notification event of the first code repository and parsing the first notification event to obtain first target data including the first commit hash, the first Git branch name, and the first operation type includes:

[0014] Based on the first network hook, a first notification event of the first code repository is obtained, the notification data packet corresponding to the first notification event is determined, and the notification data packet is extracted to obtain first target data including a first commit hash, a first Git branch name, and a first operation type;

[0015] The first notification event includes code commit events, merge request events, and branch operation events.

[0016] Optionally, obtaining the temporary token corresponding to the first code repository based on a preset authorization protocol, and using the temporary token to determine the first modification content corresponding to the first notification event, includes:

[0017] The API caller of the intermediate server is used to send an authorization request, including the first application key, to the authorization server of the first code repository, so that the authorization server returns the corresponding authorization code based on the authorization request and the preset authorization protocol;

[0018] Based on the authorization code, a corresponding temporary token is determined, and the temporary token and the first code repository are used to determine the first modification content corresponding to the first notification event; the temporary token is a token with a target validity period.

[0019] Optionally, the step of converting the first modified content into target content using the target mapping relationship between the first code repository and the second code repository, and determining whether a second notification event corresponding to the target content exists in the second code repository based on a distributed lock, includes:

[0020] A first mapping relationship is constructed based on the role names of the first and second code repositories, and a second mapping relationship is constructed using the event names and branch strategies of the first and second code repositories.

[0021] A third mapping relationship is constructed based on the repository configuration parameters of the first code repository and the second code repository. The target mapping relationship between the first code repository and the second code repository is determined using the first mapping relationship, the second mapping relationship and the third mapping relationship.

[0022] Based on the target mapping relationship, the first modified content is converted into target content that can be recognized by the second code repository;

[0023] Acquire a distributed lock, and based on the distributed lock and the second network hook, obtain a second notification event for the second code repository;

[0024] The second notification event is parsed to obtain second target data including the second commit hash, the second Git branch name, and the second operation type;

[0025] Determine whether the target content matches the first target data;

[0026] If a match is found, it indicates that a second notification event corresponding to the target content exists in the second code repository.

[0027] Optionally, if a second notification event matching the first target data exists in the second code repository, and the second modification content corresponding to the second notification event conflicts with the first modification content, then a preset conflict handling strategy is used to process the conflicting target location to obtain synchronized data, including:

[0028] If a second notification event that matches the first target data exists in the second code repository, then it is determined whether the second modification content corresponding to the second notification event conflicts with the first modification content.

[0029] If the second modification content corresponding to the second notification event conflicts with the first modification content, then the target location of the conflict is determined, and it is determined whether the target location is non-overlapping code;

[0030] If the target location is a non-overlapping code, then the target location is merged based on the first modification and the second modification to obtain synchronized data;

[0031] If the target location is not non-overlapping code, then determine the first priority corresponding to the first code repository and the second priority corresponding to the second code repository;

[0032] If the first priority is higher than the second priority, the target location is overwritten based on the first modification content corresponding to the first code repository to obtain synchronized data;

[0033] If the first priority is lower than the second priority, the target location is overwritten based on the second modification content corresponding to the second code repository to obtain synchronized data.

[0034] Optionally, if the second modification content corresponding to the second notification event conflicts with the first modification content, determining the target location of the conflict includes:

[0035] Determine whether the first modified content corresponding to the second notification event and the file hash corresponding to the second modified content are consistent;

[0036] If they are inconsistent, it indicates that the second modification content conflicts with the first modification content. Then, the first modification content and the second modification content are compared, and the target location of the conflict is determined based on the comparison result.

[0037] Secondly, this application provides a data synchronization device for an enterprise code repository, applied to an independently deployed intermediate server, comprising:

[0038] The event parsing module is used to obtain the first notification event of the first code repository, parse the first notification event to obtain the first target data including the first commit hash, the first Git branch name and the first operation type;

[0039] The content conversion module is used to obtain a temporary token corresponding to the first code repository based on a preset authorization protocol, use the temporary token to determine the first modified content corresponding to the first notification event, use the target mapping relationship between the first code repository and the second code repository to convert the first modified content into target content, and use a distributed lock to determine whether there is a second notification event corresponding to the target content in the second code repository.

[0040] The data synchronization module is used to process the conflicting target location using a preset conflict handling strategy if a second notification event that matches the first target data exists in the second code repository, and the second modification content corresponding to the second notification event conflicts with the first modification content, so as to obtain synchronized data and synchronize the synchronized data to the second code repository to complete the corresponding data synchronization operation.

[0041] Thirdly, this application provides an electronic device, comprising:

[0042] Memory, used to store computer programs;

[0043] A processor is used to execute the computer program to implement the aforementioned data synchronization method for the enterprise code repository.

[0044] Fourthly, this application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned data synchronization method for an enterprise code repository.

[0045] This application obtains a first notification event from a first code repository, parses the first notification event to obtain first target data including a first commit hash, a first Git branch name, and a first operation type; obtains a temporary token corresponding to the first code repository based on a preset authorization protocol, uses the temporary token to determine the first modification content corresponding to the first notification event, and uses the target mapping relationship between the first code repository and the second code repository to convert the first modification content into target content; determines whether there is a second notification event corresponding to the target content in the second code repository based on a distributed lock; if there is a second notification event in the second code repository that matches the first target data, and the second modification content corresponding to the second notification event conflicts with the first modification content, then uses a preset conflict handling strategy to process the conflicting target locations to obtain synchronization data, and synchronizes the synchronization data to the second code repository to complete the corresponding data synchronization operation.

[0046] As can be seen from the above, this application obtains core data such as the first commit hash, Git branch name, and operation type by parsing the first notification event, which can accurately pinpoint the scope of changes in the first code repository and avoid synchronization deviations caused by missing information. It obtains temporary tokens based on a preset authorization protocol, avoiding long-term exposure of static keys and reducing the risk of key leakage. It uses target mapping relationships to transform the first modification content, adapting to both the first and second code repositories and solving cross-platform compatibility issues. By using a distributed lock to determine whether a corresponding second notification event exists in the second code repository, it prevents multiple threads from simultaneously operating on the same branch or event in the second repository, avoiding data corruption caused by concurrent writes. In this way, when synchronizing code repository data, if merge conflicts exist in the events, preset conflict handling strategies can be used to resolve the conflicts specifically. Furthermore, when synchronizing metadata such as work orders, data loss and errors are avoided, thereby improving the efficiency and security of bidirectional synchronization between the first and second code repositories. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0048] Figure 1 This application discloses a flowchart of a data synchronization method for an enterprise code repository.

[0049] Figure 2 This application provides a schematic diagram of a GitLab synchronous code commit.

[0050] Figure 3 This application provides a schematic diagram of a synchronous code commit in Gitea.

[0051] Figure 4 This application provides a schematic diagram of a GitLab synchronous issue.

[0052] Figure 5 This application provides a schematic diagram of a Gitea synchronous issue.

[0053] Figure 6 A schematic diagram of a data synchronization operation log provided in this application;

[0054] Figure 7 This application discloses a flowchart of a specific data synchronization method for an enterprise code repository;

[0055] Figure 8This is a schematic diagram of the data synchronization method for a specific enterprise code repository disclosed in this application;

[0056] Figure 9 A schematic diagram of inspection task scheduling provided in this application;

[0057] Figure 10 This is a schematic diagram of the structure of a data synchronization device for an enterprise code repository disclosed in this application;

[0058] Figure 11 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] In software development, GitLab and Gitea are mainstream code repository management systems. Currently, existing mirror synchronization methods often encounter code conflicts when both GitLab and Gitea simultaneously commit code to the same repository and development branch. These conflicts cannot be resolved automatically and require manual intervention, resulting in low efficiency. Furthermore, this method is prone to circular synchronization, causing a surge in server load and significantly impacting data synchronization efficiency. Additionally, it can only synchronize code branches / commits, not metadata such as issues / work orders, project personnel, and permissions. Therefore, this application provides a data synchronization method for enterprise code repositories. This method allows for targeted resolution of merge conflicts during code repository data synchronization using preset conflict handling strategies. It also prevents data loss and errors when synchronizing metadata such as work orders, thereby improving the efficiency and security of bidirectional synchronization between the first and second code repositories.

[0061] See Figure 1 As shown, this embodiment of the invention discloses a data synchronization method for an enterprise code repository, applied to an independently deployed intermediate server, comprising:

[0062] Step S11: Obtain the first notification event of the first code repository, parse the first notification event to obtain the first target data including the first commit hash, the first Git branch name and the first operation type.

[0063] In this embodiment, if the first code repository is GitLab and the second code repository is Gitea, firstly, webhooks are registered in GitLab and Gitea respectively to obtain the first and second webhooks. Then, the webhook receiving address corresponding to the intermediate server is entered into the URL (Uniform Resource Locator) of the Webhooks section in the Settings menu of GitLab, ensuring that the intermediate server is started and listening to the above address. Next, test information including notification events is sent to the intermediate server based on the first and second webhooks. If the intermediate server can receive the test information sent by the first and second code repositories, it indicates that the first and second webhooks are successfully installed. The notification events may include code commit events and merge request events. Then, a code repository deployment service is deployed on the intermediate server, configuring the first application key and first webhook address corresponding to the first code repository, and the second application key and second webhook address corresponding to the second code repository.

[0064] Specifically, before obtaining the first notification event of the first code repository, the method further includes: registering a first network hook and a second network hook based on the first code repository and the second code repository respectively, and adding the receiving notification address corresponding to the intermediate server using the first network hook and the second network hook; sending first test information and second test information to the intermediate server based on the first network hook and the network hook respectively, and indicating that the first network hook and the second network hook are successfully installed if the intermediate server receives the first test information and the second test information; configuring the first application key corresponding to the first code repository and the second application key corresponding to the second code repository on the intermediate server.

[0065] Understandably, after the first network hook is successfully installed, the first notification event of the first code repository is obtained based on the first network hook. The first notification event includes code commit events, merge request events, and branch operation events. Then, the notification data packet corresponding to the first notification event pushed by the first network hook is parsed to obtain the first notification event. The first notification event can be standardized, and the processed event is parsed to obtain...

[0066] The first target data includes the first commit hash, the first Git (distributed version control system) branch name, and the first operation type. It should be noted that the first target data, in addition to the first commit hash, the first Git branch name, and the first operation type, may also include metadata such as committer information and commit timestamps. Specifically, obtaining the first notification event of the first code repository and parsing the first notification event to obtain the first target data including the first commit hash, the first Git branch name, and the first operation type includes: obtaining the first notification event of the first code repository based on the first network hook, determining the notification data packet corresponding to the first notification event, and extracting the notification data packet to obtain the first target data including the first commit hash, the first Git branch name, and the first operation type; wherein, the first notification event includes code commit events, merge request events, and branch operation events.

[0067] In one specific implementation, if the first code repository is GitLab, the process of parsing the first notification event is as follows:

[0068] def _parse_gitlab(self, data: Dict) -> Tuple[str, str, str]:

[0069] if data.get("object_kind") != "push":

[0070] return None;

[0071] commit_hash = data["after"]; # Latest commit hash

[0072] branch_name = data["ref"].split(" / ")[-1]; # Branch name

[0073] return (commit_hash, branch_name, "push").

[0074] In another specific implementation, if the first code repository is Gitea, the process of parsing the first notification event is as follows:

[0075] def _parse_gitea(self, data: Dict) -> Tuple[str, str, str]:

[0076] if data.get("ref_type") != "branch" or data.get("action") != "push":

[0077] return None;

[0078] commit_hash = data["after"]; # Latest commit hash

[0079] branch_name = data["ref"].split(" / ")[-1];

[0080] return (commit_hash, branch_name, "push").

[0081] Step S12: Obtain a temporary token corresponding to the first code repository based on a preset authorization protocol, use the temporary token to determine the first modified content corresponding to the first notification event, and use the target mapping relationship between the first code repository and the second code repository to convert the first modified content into target content. Based on a distributed lock, determine whether there is a second notification event corresponding to the target content in the second code repository.

[0082] In this embodiment, after obtaining the first target data, the authorization request is sent to the authorization server of the first code repository using the API (Application Programming Interface) caller of the intermediate server. The authorization request includes the first application key, so that the authorization server returns the corresponding authorization code based on the authorization request and the OAuth2 (Open Authorization 2.0) dynamic authorization protocol. A corresponding temporary token is determined based on the authorization code. A short-term validity period can be set for the temporary token to avoid long-term exposure of sensitive information. Furthermore, a new temporary token is obtained each time the API of the first code repository is called, instead of reusing the old token. Then, the first modification content corresponding to the first notification event is determined using the temporary token and the first code repository. In one specific implementation, if the first code repository is GitLab, the source repository commit records are obtained through the GitLab API, such as GET / projects / {id} / repository / commits to obtain commit record details; if the second code repository is Gita, the target repository commit records are obtained through the Gita API, such as GET / api / v1 / repos / {owner} / {repo} / commits. Specifically, obtaining the temporary token corresponding to the first code repository based on a preset authorization protocol, and using the temporary token to determine the first modification content corresponding to the first notification event, includes: using the API caller of the intermediate server to send an authorization request including the first application key to the authorization server of the first code repository, so that the authorization server returns a corresponding authorization code based on the authorization request and the preset authorization protocol; determining the corresponding temporary token based on the authorization code; and using the temporary token and the first code repository to determine the first modification content corresponding to the first notification event; wherein the temporary token is a token with a target validity period.

[0083] Understandably, it's necessary to convert the first target data corresponding to the first code repository into a format recognizable by the second code repository. Since the syntax rules of the first and second code repositories differ—for example, the Maintainer role in GitLab corresponds to the Administrator role in Gitea—a cross-platform data mapping relationship needs to be established. First, a first mapping relationship is constructed based on the role names of the first and second code repositories, essentially a role mapping relationship. A second mapping relationship is constructed using the event names and branching policies of the first and second code repositories; for example, the Merge Request event in GitLab maps to the Pull Request event in Gitea, and the Protected Branches policy in GitLab maps to the Branch Protection Rules policy in Gitea. Then, a third mapping relationship is constructed based on the repository configuration parameters of the first and second code repositories; for example, the repository visibility (Public / Private) in GitLab maps to the repository access level in Gitea. Finally, based on the constructed first, second, and third mapping relationships, the target mapping relationship between the first and second code repositories is determined.

[0084] In one specific implementation, the code for converting the first modified content into the target content is shown below:

[0085] def transform_to_target(self, source_changes: Dict) -> Dict:

[0086] target_branch = self.branch_mapping.get(

[0087] source_changes["branch"];

[0088] source_changes["branch"]; # If there is no mapping relationship, keep the original branch name. )

[0090] return {

[0091] **source_changes;

[0092] "branch": target_branch;

[0093] "sync_tag": f"[sync from {self.source_platform}]", # Add a synchronization tag to prevent loops.

[0094] "commit_msg":f"

[0095] {source_changes['commit_msg']}\n{source_changes['sync_tag']}";

[0096] }

[0097] Furthermore, after obtaining the target mapping relationship, the first modified content is converted into target content recognizable by the second code repository based on the target mapping relationship. Then, a distributed lock is acquired for the second code repository to prevent concurrent operation conflicts and ensure that only one synchronous task is allowed to process the same repository at the same time. Then, based on the distributed lock and the second network hook, a second notification event of the second code repository is obtained. The second notification event is parsed to obtain second target data including a second commit hash, a second Git branch name, and a second operation type. Then, it is determined whether the first commit hash, the first Git branch name, and the first operation type in the target content match the second commit hash, the second Git branch name, and the second operation type in the first target data. If they match, it indicates that a second notification event corresponding to the target content exists in the second code repository.

[0098] Specifically, the step of converting the first modified content into target content using the target mapping relationship between the first and second code repositories, and determining whether a second notification event corresponding to the target content exists in the second code repository based on a distributed lock, includes: constructing a first mapping relationship based on the role names of the first and second code repositories; constructing a second mapping relationship using the event names and branch policies of the first and second code repositories; constructing a third mapping relationship based on the repository configuration parameters of the first and second code repositories; determining a target mapping relationship between the first and second code repositories using the first, second, and third mapping relationships; converting the first modified content into target content recognizable by the second code repository based on the target mapping relationship; acquiring a distributed lock; acquiring a second notification event of the second code repository based on the distributed lock and the second network hook; parsing the second notification event to obtain second target data including a second commit hash, a second Git branch name, and a second operation type; determining whether the target content matches the first target data; if they match, it indicates that a second notification event corresponding to the target content exists in the second code repository.

[0099] Step S13: If there is a second notification event in the second code repository that matches the first target data, and the second modification content corresponding to the second notification event conflicts with the first modification content, then the conflicting target location is processed using a preset conflict handling strategy to obtain synchronized data, and the synchronized data is synchronized to the second code repository to complete the corresponding data synchronization operation.

[0100] In this embodiment, if a second notification event matching the first target data exists in the second code repository, it is determined whether the second modification content corresponding to the second notification event conflicts with the first modification content. Then, a preset conflict handling strategy is used to process the conflicting target location. The logic code corresponding to the preset conflict handling strategy is as follows:

[0101] def resolve_conflicts(self):

[0102] if not self.conflict_files:

[0103] self._log("No conflicting files, no need to resolve");

[0104] return True;

[0105] self._log("Starting automatic conflict resolution...");

[0106] for file in self.conflict_files:

[0107] file_path = os.path.join(self.local_repo, file);

[0108] if not os.path.exists(file_path):

[0109] self._log(f"Conflict file {file} does not exist, skipping", "WARNING");

[0110] continue;

[0111] with open(file_path, "r", encoding="utf-8") as f:

[0112] content = f.read();

[0113] with open(file_path, "w", encoding="utf-8") as f:

[0114] f.write(resolved_content);

[0115] self._run_git_command(f"git add {file}");

[0116] commit_result = self._run_git_command(

[0117] f'git commit -m "Auto-resolve conflicts between GitLab and Gitea at {datetime.now()}" )

[0119] if commit_result["success"]:

[0120] self._log("Conflict resolution commit successful");

[0121] self.conflict_files = [];

[0122] return True;

[0123] else:

[0124] self._log(f"Conflict resolution commit failed: {commit_result['error']}", "ERROR")

[0125] return False.

[0126] Understandably, if a conflict exists, textual difference analysis is performed on the first and second modified content, and the target location of the conflict is determined based on the analysis results. The textual difference analysis methods include line-level text analysis, content analysis, and discourse analysis. If the target location is non-overlapping code, meaning the modification locations corresponding to the first and second modified content are different, Git's merge function is used to merge the code, and the target location is merged based on the first and second modified content to obtain synchronized data. If the target location is not non-overlapping code, synchronized data is determined based on the code repository priority, and the synchronized data is synchronized to the second code repository to complete the corresponding data synchronization operation. In one specific implementation, if the target location is not non-overlapping code, and the priority of the second code repository is higher than that of the first code repository, the content of the second code repository is directly retained to obtain synchronized data. The corresponding code is shown below:

[0127] resolved_changes = [

[0128] f for f in target_content["changes"];

[0129] if f["filename"] not in conflict_files; #Preserve the contents of the second code repository. ]

[0131] #Record conflicts in submission information

[0132] target_content["commit_msg"] += f"\n[Conflict resolved: skippedfiles {conflict_files}]"

[0133] return {** target_content, "changes": resolved_changes}.

[0134] Specifically, if a second notification event matching the first target data exists in the second code repository, and the second modification content corresponding to the second notification event conflicts with the first modification content, a preset conflict handling strategy is used to process the conflicting target location to obtain synchronized data. This includes: if a second notification event matching the first target data exists in the second code repository, determining whether the second modification content corresponding to the second notification event conflicts with the first modification content; if the second modification content corresponding to the second notification event conflicts with the first modification content, determining the conflicting target location and determining whether the target location is non-overlapping code; if the target location is non-overlapping code, merging the target location based on the first modification content and the second modification content to obtain synchronized data; if the target location is not non-overlapping code, determining the first priority corresponding to the first code repository and the second priority corresponding to the second code repository; if the first priority is higher than the second priority, overwriting the target location based on the first modification content corresponding to the first code repository to obtain synchronized data; if the first priority is lower than the second priority, overwriting the target location based on the second modification content corresponding to the second code repository to obtain synchronized data.

[0135] Understandably, when determining whether the second modified content corresponding to the second notification event conflicts with the first modified content, specifically, it is determined whether the first modified content corresponding to the second notification event and the file hash corresponding to the second modified content are consistent. If they are inconsistent, it indicates that the second modified content and the first modified content conflict. Then, text difference analysis is used to compare the first modified content and the second modified content, and the target location of the conflict is determined based on the comparison result. The text difference method includes text line-level analysis, content analysis, and discourse analysis. Specifically, determining the target location of the conflict if the second modified content corresponding to the second notification event conflicts with the first modified content includes: determining whether the first modified content corresponding to the second notification event and the file hash corresponding to the second modified content are consistent; if they are inconsistent, it indicates that the second modified content and the first modified content conflict. Then, the first modified content and the second modified content are compared, and the target location of the conflict is determined based on the comparison result.

[0136] In this embodiment, the status of the first code repository and the second code repository can be checked periodically, and corresponding status feedback information can be determined based on the check results to prevent data synchronization errors caused by abnormal repository status; alternatively, the difference information between the first code repository and the second code repository can be determined based on the check results, and the difference information can be used to trigger data synchronization operations, as shown in the following code:

[0137] while IFS= read -r git_project; do;

[0138] project_name=$(echo "$git_project" | awk -F' / ' '{print $NF}');

[0139] cd / git / repo;

[0140] if [[ ! -d " / git / repo / $project_name" ]]; then;

[0141] output=$(git clone --mirror http: / / root:5e3d3db5dc31******09f9fe67faf39cea7cb@10.110.40.x:8001 / $git_project 2>&1);

[0142] print_log $? "git clone $git_project error" "$output";

[0143] fi;

[0144] cd / git / repo / $project_name;

[0145] output=$(git fetch origin 2>&1);

[0146] print_log $? "git pull $group_name / $project_name error" "$output";

[0147] git remote |grep gitea;

[0148] if [ $? = 1 ]; then;

[0149] `git remote add gitea url;`

[0150] fi;

[0151] output=$(git push -f --all gitea 2>&1);

[0152] print_log $? "git push $group_name / $project_name error" "$output";

[0153] `git push -f --tag gitea;`

[0154] done < "$group_name".

[0155] Furthermore, a retry mechanism for failed pushes can be configured, such as up to three exponential backoff retries, with a 10-second interval for the first retry, 30 seconds for the second, and 60 seconds for the third, to avoid synchronization failures caused by network fluctuations. It's worth noting that the logic for synchronizing data from the first code repository to the second code repository in this solution can also be applied to the reverse synchronization from the second code repository to the first code repository. Additionally, the enterprise code repository data synchronization solution in this embodiment can be applied to enterprise IoT device development scenarios. The device firmware team, responsible for embedded code development, can use GitLab as the first code repository; the cloud platform team, responsible for data storage and analysis service development, can use Gitea as the second code repository.

[0156] It is worth mentioning that, Figure 2 This is a schematic diagram of a GitLab synchronous code commit provided in this embodiment. Figure 3 This embodiment illustrates a Gitea code commit synchronization method. The data synchronization solution for enterprise code repositories in this embodiment can synchronize not only code branches / commits, but also metadata such as issues / work orders, project personnel, and permissions. Figure 4 This is a schematic diagram of a GitLab synchronous issue provided in this embodiment. Figure 5 This is a schematic diagram of a Gitea synchronous issue provided in this embodiment. Additionally, Figure 6 This embodiment provides a schematic diagram of a data synchronization operation log. When there are differences between the first code repository and the second code repository, a preset conflict handling strategy is used to resolve the conflict in order to achieve the corresponding data synchronization operation.

[0157] As can be seen from the above, this application obtains core data such as the first commit hash, Git branch name, and operation type by parsing the first notification event, which can accurately pinpoint the scope of changes in the first code repository and avoid synchronization deviations caused by missing information. It obtains temporary tokens based on a preset authorization protocol, avoiding long-term exposure of static keys and reducing the risk of key leakage. It uses target mapping relationships to transform the first modification content, adapting to both the first and second code repositories and solving cross-platform compatibility issues. By using a distributed lock to determine whether a corresponding second notification event exists in the second code repository, it prevents multiple threads from simultaneously operating on the same branch or event in the second repository, avoiding data corruption caused by concurrent writes. In this way, when synchronizing code repository data, if merge conflicts exist in the events, preset conflict handling strategies can be used to resolve the conflicts specifically. Furthermore, when synchronizing metadata such as work orders, data loss and errors are avoided, thereby improving the efficiency and security of bidirectional synchronization between the first and second code repositories.

[0158] As can be seen from the above embodiments, this application is based on the data synchronization operation between the code repository using a preset conflict handling strategy and the difference analysis method. Therefore, the process of data synchronization operation between the code repository using the preset conflict handling strategy and the difference analysis method is described.

[0159] See Figure 7 and Figure 8 As shown, this embodiment of the invention discloses a data synchronization method for an enterprise code repository, applied to an independently deployed intermediate server, comprising:

[0160] In this embodiment, the code repository can be GitLab, Gitea, or GitHub. If the first code repository is GitLab and the second code repository is Gitea, by configuring Webhooks in the first and second code repositories, the intermediate server captures the repository's notification events in real time. First, the first notification event of the first code repository is obtained. The first notification event includes code commit events, branch change times, and merge / pull request events. If the time type corresponding to the first notification event is a code commit event, then the first target data including the first commit hash, the first Git branch name, and the first operation type is extracted. If the first notification event is a merge request event or a ticket event, then the first notification event in JSON format is parsed to obtain the first target data.

[0161] Understandably, after obtaining the first target data, a temporary token corresponding to the first code repository is obtained based on the OAuth2 dynamic authorization protocol, and the API of the first code repository is called to determine the first modified content corresponding to the first notification event. Based on the distributed lock and the first modified content, it is determined whether there is a second notification event corresponding to the target content in the second code repository. When determining whether there is a second notification event corresponding to the target content in the second code repository, it is necessary to use the mapping relationship between the first code repository and the second code repository to convert the first modified content into target content that the second code repository can recognize. The second notification event of the second code repository is parsed to obtain the second target data including the second commit hash, the second Git branch name, and the second operation type. It is determined whether the first commit hash, the first Git branch name, and the first operation type in the target content match the second commit hash, the second Git branch name, and the second operation type. If they match, it indicates that there is a second notification event corresponding to the target content in the second code repository.

[0162] Furthermore, if a second notification event matching the first target data exists in the second code repository, it is determined whether the second modification content corresponding to the second notification event conflicts with the first modification content. If a conflict exists, text difference analysis is performed on the first modification content and the second modification content, and the target location of the conflict is determined based on the analysis results. If the target location is non-overlapping code, that is, the modification locations corresponding to the first modification content and the second modification content are different, the target location is merged based on the first modification content and the second modification content to obtain synchronized data. If the target location is not non-overlapping code, synchronized data is determined based on the priority of the code repository, and the synchronized data is written into the second code repository.

[0163] Figure 9 This embodiment provides a schematic diagram of a check task scheduling. To avoid data loss due to network fluctuations, service failures, or other events, the intermediate server proactively initiates a repository status check task at a preset period using a timed scheduling tool. This task calls the APIs of the first and second code repositories to compare their statuses. For example, it compares commit hashes and commit events to see if one repository has a new commit while the other is missing one. If the comparison results indicate that the GitLab and Gitea states are inconsistent, the complete data synchronization process of this embodiment is triggered.

[0164] As can be seen from the above, this application obtains temporary tokens through a preset authorization protocol to avoid long-term exposure of static keys. Then, it uses a preset conflict handling strategy to resolve conflicts between code repositories. Through a dual mechanism of timed polling and event-driven mechanisms, it uses Webhook to achieve real-time synchronization and improve collaboration efficiency. At the same time, timed polling makes up for the lack of reliability of Webhook to ensure the consistency of GitLab and Gitea repository data. It is suitable for cross-team and cross-platform code collaboration scenarios. Moreover, when merge conflicts occur, it can also resolve conflicts in a targeted manner to improve the efficiency of bidirectional synchronization between the first and second code repositories.

[0165] Accordingly, see Figure 10 As shown, this application also provides a data synchronization device for an enterprise code repository, applied to an independently deployed intermediate server, comprising:

[0166] The event parsing module 11 is used to obtain the first notification event of the first code repository, parse the first notification event to obtain the first target data including the first commit hash, the first Git branch name and the first operation type;

[0167] The content conversion module 12 is used to obtain a temporary token corresponding to the first code repository based on a preset authorization protocol, use the temporary token to determine the first modified content corresponding to the first notification event, use the target mapping relationship between the first code repository and the second code repository to convert the first modified content into target content, and use a distributed lock to determine whether there is a second notification event corresponding to the target content in the second code repository.

[0168] The data synchronization module 13 is used to process the conflicting target location using a preset conflict handling strategy if there is a second notification event in the second code repository that matches the first target data, and the second modification content corresponding to the second notification event conflicts with the first modification content, so as to obtain synchronized data and synchronize the synchronized data to the second code repository to complete the corresponding data synchronization operation.

[0169] In some specific embodiments, the data synchronization device for the enterprise code repository may further include:

[0170] The address addition unit is used to register a first network hook and a second network hook based on a first code repository and a second code repository respectively, and to add the receiving notification address corresponding to the intermediate server using the first network hook and the second network hook;

[0171] The test information sending unit is used to send first test information and second test information to the intermediate server based on the first network hook and the network hook respectively. If the intermediate server receives the first test information and the second test information, it indicates that the first network hook and the second network hook have been successfully installed.

[0172] A key configuration unit is used to configure a first application key corresponding to the first code repository and a second application key corresponding to the second code repository on the intermediate server.

[0173] In some specific embodiments, the event parsing module 11 may specifically include:

[0174] The data packet extraction unit is used to obtain a first notification event of the first code repository based on the first network hook, determine the notification data packet corresponding to the first notification event, and extract the notification data packet to obtain first target data including a first commit hash, a first Git branch name, and a first operation type.

[0175] In some specific embodiments, the content conversion module 12 may specifically include:

[0176] The authorization code return unit is used to send an authorization request, including the first application key, to the authorization server of the first code repository using the API caller of the intermediate server, so that the authorization server returns the corresponding authorization code based on the authorization request and the preset authorization protocol;

[0177] The modification content determination unit is used to determine the corresponding temporary token based on the authorization code, and to determine the first modification content corresponding to the first notification event using the temporary token and the first code repository; the temporary token is a token with a target validity period.

[0178] In some specific embodiments, the content conversion module 12 may specifically include:

[0179] A mapping relationship construction unit is used to construct a first mapping relationship based on the role names of the first code repository and the second code repository, and to construct a second mapping relationship using the event names and branch strategies of the first code repository and the second code repository;

[0180] The target relationship construction unit is used to construct a third mapping relationship based on the repository configuration parameters of the first code repository and the second code repository, and to determine the target mapping relationship between the first code repository and the second code repository using the first mapping relationship, the second mapping relationship and the third mapping relationship;

[0181] Content conversion unit, used to convert the first modified content into target content recognizable by the second code repository based on the target mapping relationship;

[0182] An event acquisition unit is used to acquire a distributed lock and, based on the distributed lock and the second network hook, acquire a second notification event of the second code repository;

[0183] An event parsing unit is used to parse the second notification event to obtain second target data including the second commit hash, the second Git branch name, and the second operation type;

[0184] A content determination unit is used to determine whether the target content matches the first target data;

[0185] A data matching unit is used to indicate that if a match is found, a second notification event corresponding to the target content exists in the second code repository.

[0186] In some specific embodiments, the data synchronization module 13 may specifically include:

[0187] The content judgment unit is used to determine whether there is a conflict between the second modification content corresponding to the second notification event and the first modification content if there is a second notification event in the second code repository that matches the first target data;

[0188] The target location determination unit is used to determine the conflicting target location if the second modification content corresponding to the second notification event conflicts with the first modification content, and to determine whether the target location is a non-overlapping code.

[0189] A location merging unit is used to merge the target location based on the first modification content and the second modification content if the target location is a non-overlapping code, so as to obtain synchronization data;

[0190] The priority determination unit is used to determine the first priority corresponding to the first code repository and the second priority corresponding to the second code repository if the target location is not non-overlapping code;

[0191] A location overlay unit is used to overlay the target location based on the first modification content corresponding to the first code repository if the first priority is higher than the second priority, so as to obtain synchronized data;

[0192] The synchronization data determination unit is used to overwrite the target location based on the second modification content corresponding to the second code repository if the first priority is lower than the second priority, so as to obtain synchronization data.

[0193] In some specific embodiments, the data synchronization module 13 may specifically include:

[0194] The file hash determination unit is used to determine whether the first modified content corresponding to the second notification event and the file hash corresponding to the second modified content are consistent.

[0195] The content comparison unit is used to indicate that if there is a discrepancy, the second modified content and the first modified content conflict, and then compare the first modified content and the second modified content, and determine the target location of the conflict based on the comparison result.

[0196] Furthermore, embodiments of this application also disclose an electronic device, Figure 11 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the data synchronization method for the enterprise code repository disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0197] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0198] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0199] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the data synchronization method for the enterprise code repository executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0200] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned data synchronization method for an enterprise code repository. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0201] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0202] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0203] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0204] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0205] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data synchronization method for an enterprise code repository, characterized in that, Intermediate servers used in standalone deployments include: Obtain the first notification event of the first code repository, parse the first notification event to obtain first target data including the first commit hash, the first Git branch name and the first operation type; A temporary token corresponding to the first code repository is obtained based on a preset authorization protocol. The temporary token is used to determine the first modified content corresponding to the first notification event. The first modified content is converted into target content using the target mapping relationship between the first code repository and the second code repository. A distributed lock is used to determine whether there is a second notification event corresponding to the target content in the second code repository. If a second notification event exists in the second code repository that matches the first target data, and the second modification content corresponding to the second notification event conflicts with the first modification content, then a preset conflict handling strategy is used to process the conflicting target location to obtain synchronized data, and the synchronized data is synchronized to the second code repository to complete the corresponding data synchronization operation.

2. The data synchronization method for an enterprise code repository according to claim 1, characterized in that, Before obtaining the first notification event of the first code repository, the process also includes: Register a first network hook and a second network hook based on the first code repository and the second code repository respectively, and add the receiving notification address corresponding to the intermediate server using the first network hook and the second network hook; Based on the first network hook and the network hook respectively sending the first test information and the second test information to the intermediate server, if the intermediate server receives the first test information and the second test information, it indicates that the first network hook and the second network hook have been successfully installed; Configure the first application key corresponding to the first code repository and the second application key corresponding to the second code repository on the intermediate server.

3. The data synchronization method for an enterprise code repository according to claim 2, characterized in that, The step of obtaining the first notification event of the first code repository and parsing the first notification event to obtain first target data including the first commit hash, the first Git branch name, and the first operation type includes: Based on the first network hook, a first notification event of the first code repository is obtained, the notification data packet corresponding to the first notification event is determined, and the notification data packet is extracted to obtain first target data including a first commit hash, a first Git branch name, and a first operation type; The first notification event includes code commit events, merge request events, and branch operation events.

4. The data synchronization method for an enterprise code repository according to claim 2, characterized in that, The step of obtaining a temporary token corresponding to the first code repository based on a preset authorization protocol, and using the temporary token to determine the first modification content corresponding to the first notification event, includes: The API caller of the intermediate server is used to send an authorization request, including the first application key, to the authorization server of the first code repository, so that the authorization server returns the corresponding authorization code based on the authorization request and the preset authorization protocol; Based on the authorization code, a corresponding temporary token is determined, and the temporary token and the first code repository are used to determine the first modification content corresponding to the first notification event; the temporary token is a token with a target validity period.

5. The data synchronization method for an enterprise code repository according to claim 2, characterized in that, The step of converting the first modified content into target content using the target mapping relationship between the first code repository and the second code repository, and determining whether a second notification event corresponding to the target content exists in the second code repository based on a distributed lock, includes: A first mapping relationship is constructed based on the role names of the first and second code repositories, and a second mapping relationship is constructed using the event names and branch strategies of the first and second code repositories. A third mapping relationship is constructed based on the repository configuration parameters of the first code repository and the second code repository. The target mapping relationship between the first code repository and the second code repository is determined using the first mapping relationship, the second mapping relationship and the third mapping relationship. Based on the target mapping relationship, the first modified content is converted into target content that can be recognized by the second code repository; Acquire a distributed lock, and based on the distributed lock and the second network hook, obtain a second notification event for the second code repository; The second notification event is parsed to obtain second target data including the second commit hash, the second Git branch name, and the second operation type; Determine whether the target content matches the first target data; If a match is found, it indicates that a second notification event corresponding to the target content exists in the second code repository.

6. The data synchronization method for an enterprise code repository according to any one of claims 1 to 5, characterized in that, If a second notification event matching the first target data exists in the second code repository, and the second modification content corresponding to the second notification event conflicts with the first modification content, then a preset conflict handling strategy is used to process the conflicting target location to obtain synchronized data, including: If a second notification event that matches the first target data exists in the second code repository, then it is determined whether the second modification content corresponding to the second notification event conflicts with the first modification content. If the second modification content corresponding to the second notification event conflicts with the first modification content, then the target location of the conflict is determined, and it is determined whether the target location is non-overlapping code; If the target location is a non-overlapping code, then the target location is merged based on the first modification and the second modification to obtain synchronized data; If the target location is not non-overlapping code, then determine the first priority corresponding to the first code repository and the second priority corresponding to the second code repository; If the first priority is higher than the second priority, the target location is overwritten based on the first modification content corresponding to the first code repository to obtain synchronized data; If the first priority is lower than the second priority, the target location is overwritten based on the second modification content corresponding to the second code repository to obtain synchronized data.

7. The data synchronization method for an enterprise code repository according to claim 6, characterized in that, If the second modification content corresponding to the second notification event conflicts with the first modification content, then determining the target location of the conflict includes: Determine whether the first modified content corresponding to the second notification event and the file hash corresponding to the second modified content are consistent; If they are inconsistent, it indicates that the second modification content conflicts with the first modification content. Then, the first modification content and the second modification content are compared, and the target location of the conflict is determined based on the comparison result.

8. A data synchronization device for an enterprise code repository, characterized in that, Intermediate servers used in standalone deployments include: The event parsing module is used to obtain the first notification event of the first code repository, parse the first notification event to obtain the first target data including the first commit hash, the first Git branch name and the first operation type; The content conversion module is used to obtain a temporary token corresponding to the first code repository based on a preset authorization protocol, use the temporary token to determine the first modified content corresponding to the first notification event, use the target mapping relationship between the first code repository and the second code repository to convert the first modified content into target content, and use a distributed lock to determine whether there is a second notification event corresponding to the target content in the second code repository. The data synchronization module is used to process the conflicting target location using a preset conflict handling strategy if a second notification event that matches the first target data exists in the second code repository, and the second modification content corresponding to the second notification event conflicts with the first modification content, so as to obtain synchronized data and synchronize the synchronized data to the second code repository to complete the corresponding data synchronization operation.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the data synchronization method for an enterprise code repository as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, wherein the computer programs, when executed by a processor, implement the data synchronization method for an enterprise code repository as described in any one of claims 1 to 7.

Images