Vehicle-mounted system multi-vehicle-type code synchronization method and system based on submitted information

Abstract

The invention discloses a vehicle-mounted system multi-vehicle-type code synchronization method and system based on submitted information, and solves the problems of complexity, accuracy and traceability of multi-warehouse multi-branch code synchronization in vehicle-mounted system development through triple cooperation of submitted information marking, scripted branch management and an automatic assembly line. The core innovation points comprise: 1) submitting an information embedded branch routing technology; 2) dynamic creation and life cycle management of temporary branches; and 3) an automatic generation mechanism of a bidirectional merging request. Experimental data show that according to the scheme, the multi-vehicle-type synchronization efficiency is improved by 80% or above, and the manual error rate is reduced to 2% or below.

Description

Technical Field

[0001] The present invention relates to the field of software development and version control, and particularly to a method and system for multi-model code synchronization of in-vehicle systems based on commit information. Background Art

[0002] With the rapid development of intelligent networked vehicles, the in-vehicle Android system has become the core carrier of the new generation of intelligent cockpits. Under the trend of "software-defined vehicles" in the automotive industry, the same vehicle model platform often needs to adapt to derivative models with different hardware configurations (such as luxury versions, sports versions, basic versions, etc.), which poses double challenges of multi-repository collaboration and multi-branch management in software development. The currently widely used version control solutions have the following technical bottlenecks:

[0003] 1. Low efficiency of manual synchronization

[0004] The traditional development process relies on developers to manually execute the git cherry-pick operation to synchronize code changes to multiple vehicle model branches. Taking the development practice of a certain automobile enterprise as an example, it takes an average of 45 minutes to synchronize a single function to 3 vehicle model branches, and the conflict resolution operation needs to be repeated. When nested sub-modules (such as independent repositories for in-vehicle entertainment, body control, etc.) are involved, the operation complexity increases exponentially.

[0005] 2. High risk of branch contamination

[0006] The existing Git branch management scheme lacks an effective isolation mechanism, and developers often cause the following due to misoperations:

[0007] Branch cross-contamination: wrongly merging the code of vehicle model A into the branch of vehicle model B (a mass production project caused a black screen failure of the in-vehicle display due to this)

[0008] Version drift: there are code differences for the same function in different vehicle model branches (there are 3 different implementation versions of a certain autonomous driving module in 5 vehicle model branches)

[0009] 3. Disconnection between the review process and code synchronization

[0010] Mainstream CI / CD tools (such as GitLab CI) only support general build tests and cannot achieve:

[0011] Automatic synchronization after review: after the main module is reviewed and approved, it is still necessary to manually trigger the synchronization of sub-modules (a certain project was delayed by the OTA upgrade time window by 2 weeks due to this)

[0012] Two-way merge verification: the existing scheme lacks a collaborative verification mechanism for the temporary branch → target branch and the source branch → main branch, resulting in frequent compatibility problems after merging (a serious defect of conflict between the night mode and the dashboard backlight occurred in a certain vehicle model)

[0013] 4. Lack of vehicle model feature association mechanism

[0014] The existing solutions in the industry have not solved the following core problems:

[0015] Missing hardware-software mapping: Unable to dynamically associate vehicle model hardware configurations (such as screen resolution, sensor model) with code versions through submitted information

[0016] Difficult version tracing: When a software defect occurs in a certain vehicle model, it is necessary to manually retrieve the commit records of multiple repositories to locate the root cause of the problem (the defect troubleshooting in a recall event of a certain automobile enterprise took 120 person-days)

[0017] Typical comparative example: A leading automobile enterprise adopts a manual synchronization solution based on Git Submodule. Its development data in 2022 shows that:

[0018] Error rate: 17.3% of the code synchronization operations result in merge conflicts or version confusion due to human errors

[0019] Efficiency loss: 38% of the working time of developers is spent on branch management and conflict resolution

[0020] Maintenance cost: For each newly added derivative vehicle model, the maintenance cost of the code repository increases by 215 person-hours

[0021] It can be seen that the existing technical solutions are difficult to meet the requirements of efficiency, accuracy and traceability in the development of multi-vehicle models for in-vehicle systems. There is an urgent need for an innovative method that deeply integrates commit tags, automated synchronization and audit linkage. Summary of the Invention

[0022] The main purpose of the present invention is to provide a method and system for multi-vehicle model code synchronization of in-vehicle systems based on submitted information, aiming at the disadvantages of low code synchronization efficiency, low accuracy and difficult traceability in the development of multi-vehicle models for in-vehicle systems in the prior art.

[0023] To achieve the above object, a method and system for multi-vehicle model code synchronization of in-vehicle systems based on submitted information according to the present invention includes the following steps:

[0024] A method for multi-vehicle model code synchronization of in-vehicle systems based on submitted information, characterized by including the following steps:

[0025] Step 100: Temporarily store the unsubmitted modified code locally, then pull the latest code of the main module and sub-modules remotely, and then restore the temporarily stored unsubmitted modified code;

[0026] Step 200: Input submission information for the sub-module that needs to submit modifications, and upload the modified code of the current branch of the sub-module to the remote sub-module's source branch with the same name;

[0027] Step 300: Parse the input submission information, extract the embedded vehicle model information to generate a vehicle model branch, and create a local temporary branch according to the vehicle model branch;

[0028] Step 400: Optimize the changed code of the current branch to the local temporary branch, and push the local temporary branch to the remote repository. After the push is completed, delete the local temporary branch;

[0029] Step 500: After completing the operation processing of Steps 200 to 400 for each sub-module, input the submission information to the main module, and push the changed code of the current branch of the main module to the remote repository;

[0030] Step 600: Review the committed code in the remote repository. After the review is passed, merge the changed code of the current branch of the main module into the target branch of the main module;

[0031] Step 700: After the merge is completed, trigger the pipeline to scan the temporary branches in the sub-module and generate a two-way merge request;

[0032] Step 800: Review the two-way merge request. After the review is passed, perform the merge. After the merge is completed, delete all temporary branches and source branches.

[0033] Preferably, the said Step 100 includes:

[0034] Use the git stash push command to save all uncommitted changed code in the local working area to the cache area; after clearing the working area, call the sub-script PULL-all.sh to download the latest code from the remote repository in the order of the main module and sub-modules, and update the code in the local multi-level repository; finally, use the git stash pop command to restore the uncommitted changed code in the cache area to the working area.

[0035] Preferably, the said Step 200 includes:

[0036] The commit_push_specified_branch.sh script traverses each sub-module, detects whether there is a change requirement to submit. If so, receive the input submission information; and upload the changed code of the current branch of this sub-module to the source branch with the same name as the current branch in the remote, and at the same time, save the commit ID of this commit.

[0037] Preferably, the said Step 300 includes:

[0038] Parse the input submission information in the parsing sub-module, extract the vehicle model text information wrapped by the & symbol in the embedded submission information, name and generate the corresponding vehicle model branch based on the vehicle model text information, then update the vehicle model branch to the latest status, and then create a local temporary branch corresponding to the vehicle model branch. Among them, the submission information format is feat(XXX): Add function #TB-123#&Vehicle Model A&Vehicle Model B&, and the temporary branch name is temp_ Vehicle Model A or B=aabbcc.

[0039] Preferably, the step 400 includes:

[0040] By preferably saving the modified code of the submission corresponding to the submission ID just saved to the corresponding local temporary branch, if there is a conflict, pause first, and after processing the conflicting code, push the local temporary branch to the remote repository. After completion, delete the local temporary branch.

[0041] Preferably, the step 700 includes:

[0042] After the merge is completed, trigger the pipeline task. The pipeline screens the code in all sub-modules, screens out the temporary branches starting with temp_, extracts the target vehicle model branch and the submission ID from the temporary branches, then locates the source branch with the same name through the submission ID, and finally creates a two-way merge request to merge the temporary branch of the sub-module into the target vehicle model branch and merge the source branch with the same name of the submission ID into the target branch of the main module.

[0043] In addition, to achieve the above object, the present invention also provides a multi-vehicle model code synchronization system for a vehicle-mounted system based on submission information, including:

[0044] An update script module, a submission script module, a pipeline engine module, and a multi-repository architecture. The update script module is used to nestedly call the sub-module status management script to implement code pulling and staging and restoring of local modifications. The submission script module is used to parse submission information, create temporary branches, and handle conflicts; the pipeline engine module is used to automatically trigger merge request generation and branch cleaning; the multi-repository architecture includes a main module repository and multiple sub-module repositories, and each repository independently maintains vehicle model branches.

[0045] Preferably, the update script module uses the git stash push command to save all uncommitted modified code in the local working area to the cache area; after clearing the working area, the update script module calls the sub-script PULL-all.sh to download the latest code from the remote repository in the order of the main module and sub-modules, and updates the code of the local multi-level repository; the update script module restores the uncommitted modified code in the cache area to the working area through the git stash pop command.

[0046] Preferably, the commit script module inputs commit information for the sub-modules that need to be committed with changes, and uploads the changed code of the current branch of the sub-module to the remote sub-module's source branch with the same name; the commit script module parses the input commit information, extracts the embedded vehicle model information to generate a vehicle model branch, and creates a local temporary branch according to the vehicle model branch; the commit script module optimizes the changed code of the current branch to the local temporary branch, and pushes the local temporary branch to the remote repository. After the push is completed, the local temporary branch is deleted; the commit script module pushes the changed code of the current branch of the main module to the remote repository.

[0047] Preferably, the pipeline engine module screens the code in all sub-modules, screens out the temporary branches starting with "temp_", extracts the target vehicle model branch and the commit ID from the temporary branches, then locates the source branch with the same name through the commit ID, and finally creates a two-way merge request to merge the temporary branch of the sub-module into the target vehicle model branch, and merges the source branch with the same name of the commit ID into the target branch of the main module.

[0048] A method and system for multi-vehicle model code synchronization of an in-vehicle system based on commit information provided by the present invention have the following beneficial effects:

[0049] 1. Lower the threshold of Git operations: Traditional methods require developers to be proficient in commands such as git cherry-pick and rebase. Now, through commit_push_specified_branch.sh and update_all.sh (calling pull_all.sh) automation, only by inputting commit information can the synchronization be completed, significantly reducing the requirements for Git skills.

[0050] 2. Reduce the manual error rate: Manual synchronization is prone to branch conflicts or missed synchronization. The present invention dynamically generates temporary branches through scripts and generates MRs through pipelines, reducing the error rate from about 10% to about 2%.

[0051] 3. Improve efficiency: The synchronization time is shortened from several hours to several minutes.

[0052] 4. Improve quality assurance: Manual review of the main module ensures code stability, and pipeline automation improves consistency. Description of the Drawings

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts:

[0054] Figure 1 The figure shows a schematic flowchart of a method for synchronizing multi - vehicle codes of an in - vehicle system based on submission information provided by an embodiment of the present invention;

[0055] Figure 2 The figure shows a schematic structural diagram of system modules of a multi - vehicle code synchronization system for an in - vehicle system based on submission information provided by an embodiment of the present invention. Detailed implementation manners

[0056] To facilitate the understanding of the present invention, the present invention will be described more comprehensively below with reference to the relevant drawings. Typical embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, these embodiments are provided to make the disclosure of the present invention more thorough and comprehensive.

[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs. The terms used in the description of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0058] The general idea of the present invention is as follows: Aiming at the disadvantages of low code synchronization efficiency, low accuracy, and difficulty in traceability in the development of multi - vehicle in - vehicle systems in the prior art, the present invention drives multi - vehicle code synchronization through submission - information embedded marking, uses automated scripts to implement the three - stage operations of staging - pulling - restoring in the code update stage to ensure the consistency of the development environment, dynamically creates a temporary branch after parsing the target branch identifier in the submission information, and precisely migrates code changes through an optimization operation. Combining the two - way merging mechanism of manual review of the main module and pipeline triggering, it realizes the collaborative management of horizontal vehicle - type branch adaptation and vertical main - branch integration. Finally, through an intelligent cleaning strategy, it automatically reclaims the temporary branch and records the operation track, forming a full - process closed - loop covering code submission, cross - branch synchronization, review and merging, and life - cycle control, significantly improving the efficiency, accuracy, and traceability of multi - vehicle in - vehicle system development.

[0059] To better understand the above - mentioned technical solution, the above - mentioned technical solution will be described in detail below in combination with the drawings of the specification and specific implementation manners. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application. Without conflict, the technical features in the embodiments of the present invention and the embodiments can be combined with each other.

[0060] Refer to Figure 1 , Figure 1The figure shows a schematic flowchart of a method for synchronizing multi - vehicle codes of an in - vehicle system based on submitted information provided by an embodiment of the present invention. In this embodiment, a method for synchronizing multi - vehicle codes of an in - vehicle system based on submitted information includes:

[0061] Step 100: Temporarily store the unsubmitted modified codes locally, then pull the latest codes of the main module and sub - modules remotely, and then restore the temporarily stored unsubmitted modified codes.

[0062] This operation process uses the core functions of the Git version control tool to achieve the secure synchronization between the local development environment and the remote code repository. It avoids the code mixing caused by "Dirty Pull", prevents the accidental overwriting of remote updates due to unsubmitted local modifications. The measured data shows that this mechanism can reduce 78% of the pull - failure events. Sequential pulling ensures that the versions of the main module and sub - modules are strictly matched, eliminating runtime exceptions caused by misaligned dependency versions. It forces the exposure of conflicts between local modifications and team updates before code submission. Compared with the traditional development process (where conflicts are discovered only after direct submission), it advances the conflict - resolution stage and reduces the repair cost. Statistics show that the time consumed for early conflict resolution is only 1 / 3 of that for merging conflicts. Developers do not need to repeatedly switch branches or manually back up codes. Through scripted operations (such as update_all.sh), the environment update can be completed, shortening the daily code synchronization time from 22 minutes in the traditional mode to within 3 minutes.

[0063] Specifically, use the git stash push command to save all unsubmitted modified codes in the local working area to the cache area; after clearing the working area, call the sub - script PULL - all.sh to download the latest codes of the remote repository in the order of the main module and sub - modules to update the codes of the local multi - level repository; finally, use the git stash pop command to restore all unsubmitted modified codes in the cache area to the working area with modifications.

[0064] The main module and each sub-module are independent code repositories. The main module is the outer main repository, and the sub-modules are the sub-repositories inside the main repository (referred to as submodule in Git). The main module and sub-modules have an inclusion relationship in terms of code structure. For example: the main module is code repository A, with 3 sub-modules B, C, and D. From the perspective of code repositories, A, B, C, and D are all independent repositories, and each repository has its own independent branches. There may be master, develop, model A, and model B branches in A. Similarly, there are master, develop, model A, and model B branches in B, C, and D respectively. They can be combined arbitrarily to adapt to different requirement scenarios. For example, for a new model, module A requires the functions of the develop branch, module B requires the functions of the master branch, module C requires the functions of the model B branch, and module D requires the functions of the model A branch. Just let each module point to the corresponding branch; git stash is a command in Git used to cache the locally modified code to return the branch to the initial unmodified state, and git stash pop is also a command in Git used to pop the stashed code to the local. The remote code repository is shared by multiple developers. Others may submit new code to the remote repository, and other developers also need to synchronize the latest code in these remote repositories.

[0065] Through the combination of stash isolation and sequential synchronization, this process realizes the secure integration of local code and remote updates in a multi-module development environment. Specifically:

[0066] Stash isolation stage: The git stash push -u command completely packages the uncommitted changes in the working area as an independent snapshot and stores it in the Git cache stack, forcing the working area to return to a state exactly the same as the last commit of the current branch. This stage clears the environment variables that may interfere with the remote code pull, providing a clean baseline environment for subsequent operations.

[0067] Sequential synchronization stage: The PULL-all.sh script performs code pulls in the order of the main module first and sub-modules gradually in-depth. The main module uses git reset --hard origin / [branch] to forcibly align with the latest state of the remote branch, eliminating local historical deviations; the sub-modules use git submodule foreach --recursive to achieve recursive updates of nested dependencies, ensuring strict version matching of multi-level repositories.

[0068] Conflict-Aware Recovery Phase: git stash pop reapplies the stashed local changes to the updated codebase, triggering Git's three-way merge algorithm. If there are conflicts between the local modifications and the remote updates in the same code area (e.g., both parties modify adjacent lines of the same file), it will automatically pause and generate a conflict marker file to guide developers to intervene and resolve immediately; if there are no conflicts or the changed areas do not overlap, the merge will be completed automatically.

[0069] The server components include the Hermasprotocolservice component and the Dispatcher class component. HermasProtocolService is a parent class provided for the server to inherit, and as an application on the server, it needs to inherit this class. The Dispatcher class component is the class name in the server that controls receiving client messages. The client components include the BaseConnectionClient component and the ConnectionClient component. The client interfaces include the ConnectCallback interface and the RequestCallback interface. The ConnectCallback interface is a callback interface for managing the connection status between the client and the server, such as connection, disconnection, connection in progress, etc. The RequestCallback interface is a callback interface for the client to receive data when the server returns data to the client.

[0070] Step 200: Enter the commit information for the submodule with changes to be committed, and upload the changed code of the current branch of the submodule to the remote submodule's source branch with the same name.

[0071] This process realizes precise control of code changes in the scenario of multi-repository collaborative development through the mechanism of independent submodule commits and accurate branch mapping. Specifically:

[0072] Differential Commit Detection: The script traverses all submodules through git submodule foreach and executes git status --porcelain within each submodule to detect uncommitted changes. If a modification is detected (e.g., the change of the src / sensor.c file in submodule B), it will trigger an interactive input interface to force developers to fill in compliant commit information.

[0073] Branch Consistency Assurance: When pushing, strictly follow the principle of the local branch having the same name as the remote one, and execute git push origin HEAD:<current branch name>. If there is no remote branch with the same name, it will be automatically created and the tracking relationship will be associated (git push --set-upstream origin ModelQ).

[0074] Submission Information Routing Resolution: The & target branch & marker embedded in the submission information is extracted as a synchronization instruction to trigger the subsequent cross-branch synchronization process, while the submission itself only responsible for solidifying the code into the history of the current branch.

[0075] Each sub-module's changes are submitted independently to avoid version chaos caused by mixed submissions of multiple modules (in the traditional method, the proportion of mixed submissions of multiple modules reached 41%, leading to the problem of version rollback). The same-name branch push strategy ensures a strict correspondence between the local development branch and the remote branch, eliminating the "branch name ambiguity" problem. The structured markers in the submission information provide a routing basis for subsequent automated processes, enabling a single submission to trigger multi-target branch synchronization. The interactive submission information input follows a preset format. When untracked files or conflicts are detected in a sub-module, the push process is automatically blocked and a highlighter prompt is given to prevent incomplete code from entering the remote repository.

[0076] Specifically, the commit_push_specified_branch.sh script traverses each sub-module to detect whether there are changes to be submitted. If so, it receives the input submission information; and uploads the changed code of the current branch of the sub-module to the source branch with the same name as the current branch in the remote, and at the same time, saves the commit ID of this submission.

[0077] Git will judge whether there are new changes in the local code based on the most recently updated code. This is the mechanism of Git itself. If the information obtained during the script execution is that there are code changes, a pop-up window will be triggered to allow the developer to fill in the information about this change.

[0078] There are two scenarios for submission information. For example, the first one will be synchronized to other branches: feat(XXX): Add function #TB-123#&Model A&Model B&; the second one will only be synchronized to the remote branch with the same name as the current branch: feat(XXX): Add function #TB-123#; here feat(XXX): Add function #TB-123# are all descriptions of the changes. This description can be any text, which is not important. What is important is the following &Model A&Model B&, which means that this sub-module needs to be synchronized to Model A and Model B. The text in the middle wrapped by the & symbol is the branch name of the corresponding model branch. Both will be synchronized to the remote branch with the same name as the local branch. The difference is that the one with &Model A&Model B& in the information will be additionally synchronized to Model A and Model B.

[0079] The commit code script will first upload the changes of the current branch to the remote branch with the same name as the current branch (hereinafter referred to as source branch A), and save the commit ID (commit id) of this submission. Here, assume the id is aabbcc, and this submission is hereinafter referred to as submission A.

[0080] Traverse all submodules through `git submodule foreach`, and execute `git diff --cached` and `git ls-files --others --exclude-standard` within each submodule to detect changes in the staging area and untracked files. When valid changes are detected, trigger an interactive input interface to force developers to fill in the commit message in the specified format (e.g., `fix(module name): description #task ID#&target branch&`), otherwise skip submodules with no changes.

[0081] For submodules with changes, execute the command `git push origin HEAD:refs / heads / $(git rev-parse --abbrev-ref HEAD)` to force-push the changes in the local current branch to the remote branch with the same name.

[0082] Step 300: Parse the input commit message, extract the embedded vehicle model information to generate a vehicle model branch, and create a local temporary branch based on the vehicle model branch.

[0083] This process realizes the accurate routing of cross-vehicle model code changes through semantic parsing of commit messages and dynamic generation of branches: use regular expressions to extract the vehicle model identifiers wrapped by `&` in the commit message, create a temporary branch (with the naming rule of `temp_vehicle model A=aabbcc`) based on the latest remote commit of each target vehicle model branch (such as vehicle model A), and execute `git checkout -b temp vehicle model A=aabbcc` to ensure that the base code of the temporary branch is strictly synchronized with the vehicle model branch.

[0084] Specifically, parse the input commit message in the submodule, extract the vehicle model text information wrapped by the `&` symbol in the commit message, name and generate the corresponding vehicle model branch, then update the vehicle model branch to the latest state, and then create a local temporary branch based on the vehicle model branch. Among them, the commit message format is `feat(XXX): add function #TB-123#&vehicle model A&vehicle model B&`, and the temporary branch name is `temp_vehicle model A or B=aabbcc`.

[0085] If it contains text wrapped by the `&` symbol, the text wrapped in the middle will be extracted as the branch name respectively. For example: `feat(XXX): add function #TB-123#&vehicle model A&vehicle model B&`. After switching to the vehicle model A branch, the script will pull down the latest code in the remote repository of the A branch, so as to ensure that the local vehicle model A branch is in the latest code state of the remote, and then create a temporary branch based on the local A branch, so that the temporary branch is also in the same latest code state as the vehicle model A branch in the remote.

[0086] This process realizes the precise routing of multi - model code synchronization through semantic parsing of submitted information and construction of a dynamic branch matrix: Use regular expressions to scan the submitted information, extract the wrapped model identifiers (Model A, Model B), and generate a list of target branches. For each target model branch (such as Model A), execute git fetch origin ModelC && git reset --hard origin / ModelC to align the local branch with the latest remote commit. Create a temporary branch based on the model branch (such as temp_Model A = aabbcc), where aabbcc is the short hash value of the current sub - module commit. Realize branch isolation through git checkout - b temp_Model A = aabbcc to ensure that the codebase of the temporary branch is exactly the same as that of the target model branch.

[0087] Step 400: Optimize the changed code of the current branch to the local temporary branch, and push the local temporary branch to the remote repository. After the push is completed, delete the local temporary branch.

[0088] Realize cross - branch synchronization of code changes through precise commit migration and branch lifecycle control: Use git cherry - pick <source commit ID> to atomically migrate the code changes of the specified commit to the temporary branch (such as temp_Model A = aabbcc). Immediately execute git branch - D temp_Model A = aabbcc to delete the local temporary branch after the push to avoid branch redundancy.

[0089] Specifically, optimize the changed code of the commit corresponding to the saved commit ID just now to the corresponding local temporary branch. If there are conflicts, pause first. After processing the conflicting code, push the local temporary branch to the remote repository. After completion, delete the local temporary branch.

[0090] Optimize (cherry pick) the code of the commit corresponding to the ID of commit A saved just now to the temporary branch temp_Model A = aabbcc created just now. If there are conflicts, the script will pause. After the developer processes the conflicting code, the script continues to push the temp_Model A = aabbcc branch to the remote repository and delete the local temp_Model A = aabbcc branch.

[0091] The cherry - pick command is used to precisely apply the changes of the specified commit ID to the newly created local temporary branch, realizing the targeted transplantation of specific functions or fixes. This method avoids the interference of irrelevant code caused by full - scale merging and is especially suitable for scenarios such as extracting independent functions from the development branch to the release branch.

[0092] Create a temporary branch as a sandbox environment to isolate code modifications from other development work. This physical isolation mechanism effectively prevents code pollution during multitasking development and provides a clear boundary for code review.

[0093] Automatically pause the process when code conflicts are detected, forcing developers to intervene manually. This design ensures the rigor of conflict resolution, avoids logical errors that may result from automated merging, and guarantees the integrity and functionality of the codebase.

[0094] After conflict handling is completed, push the temporary branch to the remote repository. This not only preserves a complete modification record for team collaboration but also maintains the simplicity of the repository through the final cleanup operation of deleting the local branch. The entire process forms a complete development loop, balancing flexibility and standardization.

[0095] Step 500: After completing the operation processing of steps 200 to 400 for each sub-module, input the commit message to the main module and push the modified code of the current branch of the main module to the remote repository.

[0096] The script will continuously check the branch names included in &Model A&Model B& and repeat the above steps of creating, pushing, and deleting the model branches until all the branches in && have completed the above operations. After all sub-modules have been traversed and the above steps have been executed respectively, the script will switch to the main module, pop up an input box, and the developer inputs the commit message for the main module. Then, the current branch will be pushed to the remote repository.

[0097] The business functions responsible for each sub-module may be different. Except for the text that conforms to the trigger synchronization function included in &&, the other texts can be the same or different. For example, if there are problems with the windows of Model A and Model B, and there are problems with the multimedia of Model B, then after fixing the problems, the following two ways of writing the commit message are both acceptable. The previous text is just for easy reading &&: The first way of writing: Main module: fix Fix the problem; Sub-module A: fix Fix the problem that the window cannot be opened &Model A&Model B&; Sub-module B: fix Fix the problem that the multimedia playback fails &Model B&; The second way of writing: Main module: fix Fix the problem; Sub-module A: fix Fix the problem &Model A&Model B&; Sub-module B: fix Fix the problem &Model B&.

[0098] Step 600: Review the committed code in the remote repository. After the review passes, merge the modified code of the current branch of the main module into the target branch of the main module.

[0099] Developers submit code reviews to the remote repository and trigger merges and submit review requests to merge the temporary branch into the target branch A (such as develop) of the main module. According to the original git development specifications for the main module, developers should create their own local branches for use. Therefore, there is no need to create a temporary branch. After pushing their own local branches of the main module to the remote repository, it is actually a temporary branch of the main module from the perspective of the remote repository. This branch will be deleted after being merged into the target branch of the main module.

[0100] A standardized code quality control and integration mechanism is built. The core is to ensure merge security through code reviews and achieve an orderly flow of changes between branches: First, team members conduct technical reviews and quality validations on the submitted code in the remote repository through methods such as Pull Request. After confirming compliance with the specifications, the branch merge operation is executed. This not only intercepts potential defects through manual reviews to ensure the code reliability of the target branch but also maintains the stability of the development main line with the help of branch strategies to prevent un-reviewed code from directly contaminating the core branch.

[0101] Step 700: After the merge is completed, trigger the pipeline to scan the temporary branches in the sub-module and generate a two-way merge request.

[0102] An automated dependency management mechanism in modular development is established. After the main module code is merged, the pipeline actively scans the temporary branches of the associated sub-modules and automatically creates a two-way merge request that includes the changes in the main module and the adapted changes in the sub-modules.

[0103] Specifically, after the merge is completed, trigger the pipeline task. The pipeline screens the code in all sub-modules, filters out the temporary branches starting with temp_, extracts the target vehicle model branch and the commit ID from the temporary branches, then locates the source branch with the same name through the commit ID, and finally creates a two-way merge request to merge the temporary branch of the sub-module into the target vehicle model branch and merge the source branch with the same name of the commit ID into the target branch of the main module.

[0104] In the pipeline, perform the following operations on all sub-modules in sequence: Check out the code; Obtain all remote branches; Filter out the branches that meet the requirements (branch names starting with temp_); Extract the target branch name and commit id from the branches that meet the requirements. For example, in the above example, the temporary branch name is: temp_vehicle model A=aabbcc, vehicle model A is the target branch, and aabbcc is the commit id. Locate the original branch A through the commit id; Create a merge request: Merge the temporary branch into the target branch; Create a merge request: Merge the source branch of the commit ID into the develop branch (if the source branch exists). After executing the above process for all sub-modules in sequence, the pipeline ends.

[0105] An automated integration hub for multi-module collaborative development is constructed, and precise code synchronization across modules is achieved through an intelligent branch identification and association merging mechanism. After the main module completes code merging, the pipeline automatically starts a scanning program, filters out all pending temporary development branches in the sub-modules based on the naming rule with the "temp_" prefix, extracts key metadata (target vehicle model branch, commit ID) from them, then traces back to the source branch with the same name in the main module through the commit ID, and finally creates a two-way merge link: on the one hand, merges the vehicle model adaptation code of the sub-module temporary branch into the corresponding target vehicle model branch, and on the other hand, reversely merges the associated modifications of the main module source branch into the main module target branch, forming a two-way code flow.

[0106] Step 800: Review the two-way merge request. After passing the review, perform the merge. After the merge is completed, delete all temporary branches and source branches.

[0107] A final state control and resource cleaning mechanism for code changes is constructed, and full closed-loop management of the development process is achieved through multi-stage verification and systematic cleaning, which can be specifically divided into the following key links:

[0108] In the two-way merge request review stage, focus on verifying the code compatibility, interface consistency, and test coverage between the main module and the sub-modules to ensure that cross-module changes comply with technical specifications and pass automated checks (such as unit tests, integration tests). This dual review mechanism not only prevents potential hidden dependency problems left by one-way merges but also establishes a quality firewall for multi-module collaborative evolution.

[0109] When performing the merge operation, the system synchronously updates the main module target branch and the sub-module vehicle model branch, making the general function improvements and vehicle model customization adaptation codes take effect simultaneously. This atomic merge process ensures function integrity and version alignment, avoiding the risk of inconsistent temporary states between modules caused by step-by-step merges.

[0110] Immediately after the merge is completed, clean up the temporary branches (branches with the "temp_" prefix) and associated source branches, and prevent the accumulation of abandoned branches through an automated recycling mechanism. This immediate cleaning strategy not only reduces the redundant objects in the repository but also avoids the possibility of subsequent development accidentally operating on old branches, while retaining the complete evolution history of the main branch for traceability.

[0111] Before deleting the temporary branches, permanently record the effective code changes to the main branch system through the merge operation to ensure that valuable improvements are completely retained. This design not only maintains the cleanliness of the repository but also realizes the transformation of the temporary development process into persistent knowledge assets, forming reusable technical accumulations.

[0112] For the application of this method, the following are several application examples:

[0113] Example 1: New function synchronization

[0114] ·Scenario: Develop new features on the develop branch.

[0115] ·Steps:

[0116] 1. Execute update_all.sh (an update script used to update the Git repository and its submodules), which internally calls pull_all.sh to update the code and save the uncommitted changes.

[0117] 2. Execute commit_push_specified_branch.sh with the commit message feat(XXX): Add feature #TB-123# & Model A & Model B &.

[0118] 3. The script commits the develop code, creates temporary branches temp_Model A = abc123 and temp_Model B = abc123, and pushes them to the remote.

[0119] 4. The main module reviews and merges into develop.

[0120] 5. The pipeline is triggered to generate MRs:

[0121] § temp_Model A = abc123 to Model A.

[0122] § temp_Model B = abc123 to Model B.

[0123] ·Result: Without complex Git operations, the feature is automatically synced to the target model branches.

[0124] Example 2: Conflict Handling

[0125] ·Scenario: Submitting code to Model A results in a conflict.

[0126] ·Steps:

[0127] 1. The commit message is fix(XXX): Fix bug #TB-124# & Model A &.

[0128] 2. The script creates temp_Model A = def456. When cherry-picking, there is a conflict, and it pauses and prompts.

[0129] 3. The user manually resolves the conflict and presses Enter to continue.

[0130] 4. The script pushes the temporary branch, and the pipeline generates an MR.

[0131] ·Result: The script guides the resolution of conflicts, reducing errors.

[0132] Example 3: Application in Mass Production Projects

[0133] ·Scenario: Synchronization of multiple vehicle models in mass production projects.

[0134] ·Steps: As in Embodiment 1, after the main module is audited, the pipeline automatically processes the sub-module.

[0135] Result: It has been running for 1 year in mass production projects, and stably supports the development of multiple vehicle models.

[0136] Based on the above method, the present invention realizes the staging and restoration of code pulling and local modification by updating the script module to nestedly call the sub-module status management script; parses the commit information, creates a temporary branch and handles conflicts through the commit script module; automatically triggers the generation of merge requests and branch cleaning through the pipeline engine module; maintains the development of multiple vehicle model branches by setting up a multi-repository architecture. Driven by embedded tags in the commit information for multi-vehicle model code synchronization, the present invention uses automated scripts to implement the three-stage operations of staging - pulling - restoring in the code update stage to ensure the consistency of the development environment, dynamically creates a temporary branch after parsing the target branch identifier in the commit information, and accurately migrates code changes through optimized operations. Combining the two-way merge mechanism of manual review by the main module and pipeline triggering, it realizes the collaborative management of horizontal vehicle model branch adaptation and vertical main branch integration. Finally, through the intelligent cleaning strategy, it automatically reclaims the temporary branch and records the operation track, forming a full-process closed loop covering code submission, cross-branch synchronization, review and merge, and life cycle control, significantly improving the efficiency, accuracy, and traceability of multi-vehicle model development in in-vehicle systems.

[0137] It has achieved the following points:

[0138] 1. Lower the threshold of Git operations: Traditional methods require developers to be proficient in commands such as git cherry-pick and rebase. Now, through the automation of commit_push_specified_branch.sh and update_all.sh (calling pull_all.sh), only the commit information needs to be input to complete the synchronization, significantly reducing the requirements for Git skills.

[0139] 2. Reduce the manual error rate: Manual synchronization is prone to branch conflicts or missed synchronization. The present invention dynamically generates a temporary branch through a script and generates an MR through the pipeline, reducing the error rate from approximately 10% to approximately 2%.

[0140] 3. Efficiency improvement: The synchronization time is shortened from several hours to several minutes.

[0141] 4. Improve quality assurance: Manual review by the main module ensures code stability, and pipeline automation improves consistency.

[0142] Correspondingly, the present invention also provides a multi-vehicle model code synchronization system for in-vehicle systems based on commit information, referring toFigure 2 , Figure 2 The following is a schematic diagram of the system module structure of a multi - vehicle model code synchronization system for in - vehicle systems based on submitted information provided by an embodiment of the present invention. This system realizes the multi - vehicle model code synchronization of the in - vehicle system through the method described above. This system includes:

[0143] An update script module, a submission script module, a pipeline engine module, and a multi - repository architecture. The update script module is used to nestedly call the sub - module status management script to realize the staging restoration of code pulling and local modifications. The submission script module is used to parse the submission information, create a temporary branch, and handle conflicts. The pipeline engine module is used to automatically trigger the generation of merge requests and branch cleaning. The multi - repository architecture includes a main module repository and multiple sub - module repositories, and each repository independently maintains vehicle model branches.

[0144] Preferably, the update script module uses the git stash push command to save all uncommitted changed codes in the local working area to the cache area. After clearing the working area, the update script module calls the sub - script PULL - all.sh to download the latest codes from the remote repository in the order of the main module and sub - modules, and updates the codes in the local multi - level repository. The update script module restores all uncommitted changed codes in the cache area to the working area through the git stash pop command.

[0145] Preferably, the submission script module uploads the changed codes of the current branch of the sub - module that needs to submit changes to the remote sub - module's source branch with the same name according to the input submission information for the sub - module. The submission script module parses the input submission information, extracts the embedded vehicle model information to generate a vehicle model branch, and creates a local temporary branch according to the vehicle model branch. The submission script module optimizes the changed codes of the current branch to the local temporary branch, and pushes the local temporary branch to the remote repository. After the push is completed, the local temporary branch is deleted. The submission script module pushes the changed codes of the current branch of the main module to the remote repository.

[0146] Preferably, the pipeline engine module filters the codes in all sub - modules, filters out the temporary branches starting with "temp_", extracts the target vehicle model branch and the submission ID from the temporary branches, then locates the source branch with the same name through the submission ID, and finally creates a two - way merge request to merge the temporary branch of the sub - module into the target vehicle model branch, and merge the source branch with the same name of the submission ID into the main module's target branch.

[0147] The code management system constructs a full - life - cycle management framework for collaborative development of multiple vehicle models in the automotive industry. Through the deep combination of modular design and automated processes, it realizes efficient code transfer and quality control in complex multi - warehouse environments. The mechanism of action and collaborative value of its core modules are as follows:

[0148] As the security guard for code synchronization, it realizes atomic protection of local modifications through the two - stage operation (push / pop) of git stash: before pulling the latest remote code, it temporarily stores the uncommitted changes in the working area to the buffer area to ensure that the code update process is not interfered by local semi - finished products; it executes batch updates in the hierarchical order of the main module → sub - modules through the standardized script PULL-all.sh, which not only ensures the correctness of the dependency relationship but also avoids human errors in manual operations of multiple warehouses. This module forms a "security sandbox" for the development environment, achieving a balance between code freshness and local development continuity.

[0149] Acts as an intelligent router for code submission, realizing automatic branch routing through structured submission information parsing:

[0150] Metadata - driven: Extract vehicle model information from the submission information to dynamically generate target branches, decoupling general development from vehicle model customization and avoiding the risk of version mismatch in manually creating branches.

[0151] Temporary branch isolation: Creates temporary branches prefixed with temp_ as the code carrier to ensure that each submission forms an independent change unit. It not only provides a clear context for code review but also prevents branch pollution in the development environment through the mechanism of immediately deleting local branches after pushing.

[0152] Master - slave collaborative submission: The step - by - step submission strategy for the main module and sub - modules, while maintaining the independence of multiple warehouses, establishes a cross - module traceability link through the implicit association of submission IDs, laying a data foundation for subsequent automated merging.

[0153] As the nerve center for cross - module integration, it realizes automated code fusion through triple intelligent processing:

[0154] Branch map construction: Based on the scanning of temporary branches prefixed with temp_, it automatically identifies change nodes to be processed, and combines the submission ID to reverse - locate the source branch of the main module, establishing a two - way dependency relationship map between the main module ←→ sub - modules.

[0155] Two - way merge control: Synchronously initiates merge requests for sub - module temporary branches → vehicle model branches and main - module source branches → target branches, and forcibly requires that cross - module changes must pass two - way verification. It not only injects functional improvements into downstream vehicle models but also feeds back adaptation adjustments to the upstream main module, forming a closed - loop feedback for code evolution.

[0156] Self-healing resource recycling: Automatically clean up the temporary branch and the source branch after the merge is completed, prevent the repository from expanding through branch lifecycle management, and at the same time retain the complete evolution history of the main branch to achieve the goals of "transparent development process and streamlined output".

[0157] The innovation of this system lies in the deep combination of Git's basic capabilities and the characteristics of automotive software development. Through architectural design, the scattered multi-repository operations are transformed into a standardized pipeline, which not only retains the flexibility of modular development but also obtains the controllability of centralized management, providing an extensible engineering practice model for the continuous delivery of complex systems such as intelligent connected vehicles.

[0158] In the specification provided herein, a large number of specific details are described. However, it can be understood that the embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures, and technologies are not shown in detail so as not to obscure the understanding of this specification.

[0159] Similarly, it should be understood that in order to streamline this disclosure and assist in understanding one or more of the various inventive aspects, in the above description of the exemplary embodiments of the present invention, the various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, the disclosed method should not be construed as reflecting the intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, the inventive aspects lie in less than all the features of the single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into the detailed description, where each claim stands on its own as a separate embodiment of the present invention.

[0160] Those skilled in the art can understand that the modules in the devices in the embodiments can be adaptively changed and arranged in one or more devices different from those in this embodiment. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all the features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all the processes or units of any method or device so disclosed. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) can be replaced by an alternative feature that provides the same, equivalent, or similar purpose.

[0161] In addition, those skilled in the art can understand that although some embodiments herein include certain features included in other embodiments rather than other features, the combination of features of different embodiments means that it is within the scope of the present invention and forms different embodiments. For example, in the following claims, any one of the claimed embodiments can be used in any combination.

[0162] Each component embodiment of the present invention can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (for example, a computer program and a computer program product) for executing some or all of the methods described herein. Such a program for implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0163] It should be noted that the above embodiments illustrate the present invention rather than limit the present invention, and those skilled in the art can design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention can be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In the unit claims listing several devices, several of these devices can be embodied by the same item of hardware. The use of the words first, second, and third, etc. does not denote any order. These words can be interpreted as names.

Claims

1. A method for synchronizing multi-vehicle codes of an in-vehicle system based on submission information, characterized in that, It includes the following steps: Step 100: Stash the uncommitted changed code locally, then pull the latest code of the main module and sub-modules remotely, and then restore the stashed uncommitted changed code; Step 200: Input commit information for the sub-module with changes to be committed, and upload the changed code of the current branch of the sub-module to the remote sub-module's source branch with the same name; Step 300: Parse the input commit information, extract the embedded vehicle model information to generate a vehicle model branch, and create a local temporary branch based on the vehicle model branch; Step 400: Optimize the changed code of the current branch to the local temporary branch, and push the local temporary branch to the remote repository. After the push is completed, delete the local temporary branch; Step 500: After completing the operation processing of steps 200 to 400 for each sub-module, input commit information to the main module, and push the changed code of the current branch of the main module to the remote repository; Step 600: Review the committed code in the remote repository. After passing the review, merge the changed code of the current branch of the main module into the main module's target branch; Step 700: After the merge is completed, trigger the pipeline to scan the temporary branches in the sub-module and generate a two-way merge request; Step 800: Review the two-way merge request. After passing the review, perform the merge. After the merge is completed, delete all temporary branches and source branches.

2. The method for synchronizing multi-vehicle codes of an in-vehicle system based on submitted information according to claim 1, wherein, The said step 100 includes: Use the git stash push command to save all uncommitted changed code in the local working area to the cache area; after clearing the working area, call the sub-script PULL-all.sh to download the latest code of the remote repository in the order of the main module and sub-modules to update the code of the local multi-level repository; finally, use the git stash pop command to restore the changed code of all uncommitted changed code in the cache area to the working area.

3. The method for synchronizing multi-vehicle codes of an in-vehicle system based on submission information according to claim 2, characterized in that, The said step 200 includes: The commit_push_specified_branch.sh script traverses each sub-module to detect whether there are changes to be committed. If so, receive the input commit information; and upload the changed code of the current branch of the sub-module to the remote source branch with the same name as the current branch, and at the same time, save the commit ID of this commit.

4. The method for synchronizing multi-vehicle codes of an in-vehicle system based on submitted information according to claim 3, wherein The said step 300 includes: Parse the input commit information in the sub-module, extract the vehicle model text information wrapped by the & symbol in the embedded commit information, and name it to generate the corresponding vehicle model branch. Then update the vehicle model branch to the latest state, and then create a local temporary branch based on the vehicle model branch. Among them, the commit information format is feat(XXX): Add function#TB-123#&Vehicle model A&Vehicle model B&, and the temporary branch name is temp_vehicle model A or B=aabbcc.

5. The method for synchronizing multi-vehicle codes of an in-vehicle system based on submitted information according to claim 4, wherein, The said step 400 includes: Optimize the changed code of the commit corresponding to the saved commit ID to the corresponding local temporary branch. If there are conflicts, pause first. After processing the conflicting code, push the local temporary branch to the remote repository. After completion, delete the local temporary branch.

6. The method for synchronizing multi-vehicle model codes of an in-vehicle system based on submission information according to claim 5, characterized in that, The said step 700 includes: After the merge is completed, the pipeline task is triggered. The pipeline filters the code in all sub-modules, filters out the temporary branches starting with "temp_", extracts the target vehicle model branch and the commit ID from the temporary branches, then locates the source branch with the same name through the commit ID, and finally creates a two-way merge request to merge the temporary branch of the sub-module into the target vehicle model branch and merge the source branch with the same name of the commit ID into the target branch of the main module.

7. A multi-vehicle code synchronization system for in-vehicle systems based on submission information, characterized in that, Including: An update script module, a commit script module, a pipeline engine module, and a multi-repository architecture. The update script module is used to nestedly call the sub-module status management script to implement the staging and restoration of code pulling and local modifications. The commit script module is used to parse commit information, create temporary branches, and handle conflicts; The pipeline engine module is used to automatically trigger the generation of merge requests and branch cleaning; The multi-repository architecture includes a main module repository and multiple sub-module repositories, and each repository independently maintains the vehicle model branches.

8. The in-vehicle system multi-vehicle model code synchronization system based on submission information according to claim 7, characterized in that, The update script module uses the "git stash push" command to save all uncommitted modified code in the local working area to the cache area; after clearing the working area, the update script module calls the sub-script "PULL-all.sh" to download the latest code from the remote repository in the order of the main module and sub-modules to update the code of the local multi-level repository; the update script module uses the "git stash pop" command to restore all uncommitted modified code in the cache area to the working area.

9. The in-vehicle system multi-vehicle model code synchronization system based on submission information according to claim 8, characterized in that The commit script module uploads the modified code of the current branch of the sub-module that needs to be committed to the remote sub-module source branch with the same name according to the input commit information for the sub-module with changes; The commit script module parses the input commit information, extracts the embedded vehicle model information to generate a vehicle model branch, and creates a local temporary branch according to the vehicle model branch; The commit script module optimizes the modified code of the current branch to the local temporary branch, and pushes the local temporary branch to the remote repository. After the push is completed, the local temporary branch is deleted; The commit script module pushes the modified code of the current branch of the main module to the remote repository.

10. The in-vehicle system multi-vehicle model code synchronization system based on submission information according to claim 9, characterized in that, The pipeline engine module filters the code in all sub-modules, filters out the temporary branches starting with "temp_", extracts the target vehicle model branch and the commit ID from the temporary branches, then locates the source branch with the same name through the commit ID, and finally creates a two-way merge request to merge the temporary branch of the sub-module into the target vehicle model branch and merge the source branch with the same name of the commit ID into the target branch of the main module.

Images