Branch synchronization method, system and device for low-code development platform and readable storage medium

Abstract

The embodiment of the invention relates to the technical field of computers, and provides a branch synchronization method, system and device for a low-code development platform and a readable storage medium, and the method comprises the steps: newly storing branch name fields for all data in a database to associate corresponding git branches; when a git branch is newly built on the platform, if the database has no branch data, synchronizing a corresponding branch code of the database; if the branch data exists in the database, developing based on the database; synchronizing the data of the git branch and the corresponding branch of the database so as to realize the addition and deletion of the operation branch of the client and the synchronous addition and removal of the data of the database; the same set of database table structure design is adopted according to different environments, and the data quantity is determined according to a user branch strategy. According to the embodiment of the invention, the characteristics of git can be fully utilized, code version management is carried out on low codes like high codes, a DevOps research and development process is better adapted, and a foundation is laid for continuous delivery of low code applications.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a branch synchronization method, system, device and readable storage medium for a low-code development platform. Background Art

[0002] Low-code is an application development method. Compared with traditional application development, the program code of low-code is actually a piece of data in the database. However, since it is program development, it faces the need for multi-branch parallel development, as well as historical archiving of branch codes, branch management, code review, synchronous merging and other version management issues.

[0003] At present, the low-code platforms in the industry usually only support single-branch development iterations. Version management archives the metadata of the final product or final state, and cannot achieve the flexible iteration and change management of high-code development. The existing CN114661337A patent technology uses JGit to perform version maintenance on the metadata of the business subsystem, which is mainly used for the middle-office system to obtain different versions of data. The applicable scenarios are limited and the code version management is not performed for each state in the low-code development process; the existing CN118642751A patent technology focuses on the management of low-code application version products after the application development is completed. It cannot perform code management, baseline management, historical tracing, etc. for each development state of the low-code during the development process, and cannot effectively avoid conflicts in multi-person collaborative development.

[0004] Therefore, it is a technical problem that technical personnel in this field urgently need to solve to propose a technical solution that can confirm the development baseline based on version management records before developing low-code applications, ensure changes or iterations of new requirements, and perform iterative development based on the corresponding correct production running version. During the development process, according to the project characteristics and the development progress and habits of the developers, different branch strategies can be selected to collaborate with each developer for parallel development. After the development is completed, the code of each branch can be merged, the handover of the test version can be controlled, a single product can be ensured, and baseline tracking and tag management of the online version can be performed. Summary of the invention

[0005] In order to solve the above problems, the technical solutions adopted in this application are as follows:

[0006] In a first aspect, an embodiment of the present application provides a branch synchronization method for a low-code development platform, the method comprising the following steps:

[0007] Step S1: Add a branch name field to all data in the database to associate with the corresponding git branch;

[0008] Step S2: when a new git branch is created on the platform, if the database does not have the branch data, synchronize the database with the corresponding branch code; if the database has the branch data, develop based on the database;

[0009] Step S3: Synchronize the data of the git branch and the corresponding branch of the database to realize the addition and deletion of the client operation branch and the synchronization of the addition and deletion of the database data;

[0010] Step S4: Use the same database table structure design according to different environments, and determine the amount of data based on the user branching strategy.

[0011] Optionally, the method further comprises:

[0012] Step S201: After logging in, configure the git tool chain information and configure the associated git repository;

[0013] Step S202: The local warehouse is on the background server. The standard warehouse directory is used for development and synchronization, and the temp directory is used for merging and displaying historical versions.

[0014] Optionally, the method further comprises:

[0015] Step S301: Based on the development of the database, the changed content after modification and saving is directly in the database;

[0016] Step S302: When selecting branch development, first synchronize the database branch with the remote branch. If the database does not have the branch data, pull the corresponding branch data from the gitlab remote and write it into the library before developing. If the database has the branch data, based on the database development, the database record changes need to synchronize the git low-code data records, and modify the corresponding resource version management status to pending submission by modifying the resource snapshot table.

[0017] Optionally, the method further comprises:

[0018] Step S401: Check out the original branch and the target branch to the server local warehouse temporary storage area through JGit;

[0019] Step S402: Implement Git diff-merge-base-name-status according to JGit to obtain a file set of branch merge resource changes;

[0020] Step S403: Provide the user with a list of resources for handling merge conflicts, and perform visual display based on the current status of each branch data in redis;

[0021] Step S404: Write the local temporary storage area file overwrite according to the resource object overwrite after the conflict is resolved, then mark the file to resolve the conflict, and use JGit to perform Git commit & push operations after the conflict is completely resolved.

[0022] Optionally, the method further comprises:

[0023] Step S501: Synchronize the data of the selected branch database with the git remote repository;

[0024] Step S502: The local warehouse used synchronously is the same warehouse for development;

[0025] Step S503: The conflicting resources to be synchronized are obtained by comparing the resource list set after parsing the file set changed between the last commitID of the branch in the database and the commitID of the corresponding remote branch with the resource set marked as modified to be submitted in the database as the conflicting resource list;

[0026] Step S504: For resources that need to resolve conflicts, when the remote branch data status is selected to be stored in the database, the database corresponding resource status is marked as submitted. When the database is used or edited and developed to resolve the conflict, the database corresponding resource status is marked as pending submission.

[0027] Step S505: After the resource conflict is resolved and stored in the database, a list of resources to be submitted is provided for the user to select and process according to the database resource status;

[0028] Step S506: The resources to be synchronized are identified according to the database resource status.

[0029] Optionally, the method further comprises:

[0030] Step S601: Obtain the branch history commit record through JGit, and obtain the specific commitID, obtain the file change set of the current commit change according to the commitID, and parse it into a low-code metadata object through unified rules;

[0031] Based on the user's selection of the corresponding metadata object or the commitID, resources are compared with the current data object. A visual low-code configuration page is provided for users to analyze the change differences. Users can also choose to use the historical version or re-edit it and write it to the database.

[0032] Optionally, the method further comprises:

[0033] Step S701: Delete the local branch, and use JGit to perform a branch delete operation on the temporary storage area corresponding to the application branch under the server user name;

[0034] Step S702: Complete the remote deletion of the git branch, and use JGit to delete the remote branch;

[0035] Step S703: The remote branch is deleted successfully, and the corresponding branch data in the database is deleted at the same time.

[0036] In a second aspect, the present invention provides a branch synchronization system for a low-code development platform, the system comprising: an association module, a creation module, a synchronization module, and an audit module, wherein:

[0037] Association module: used to add a branch name field to all data in the database to associate with the corresponding git branch;

[0038] Creation module: when creating a new git branch on the platform, if the database does not have the branch data, synchronize the database corresponding branch code; if the database has the branch data, develop based on the database;

[0039] Synchronization module: used to synchronize the data of git branches and corresponding branches in the database, so as to realize the addition and deletion of branches operated by the client and the synchronization of addition and deletion of database data;

[0040] Audit module: used to adopt the same database table structure design according to different environments and determine the amount of data based on the user's branching strategy.

[0041] In a third aspect, the present invention provides an electronic device, including a processor and a memory;

[0042] The memory is used to store operation instructions;

[0043] The processor is used to execute the branch synchronization method of the above-mentioned low-code development platform by calling the operation instruction.

[0044] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and the computer program, when executed by a processor, implements a method for branch synchronization of the above-mentioned low-code development platform.

[0045] The branch synchronization solution of the low-code development platform disclosed in this specification adds a branch name field to all data in the database to associate the corresponding git branch; when a new git branch is created on the platform, if the database does not have the branch data, the corresponding branch code of the database is synchronized; if the database has the branch data, development is based on the database; synchronize the git branch and the corresponding branch data of the database to realize the addition and deletion of client operation branches and the synchronization of database data addition and removal; use the same set of database table structure design according to different environments, and determine the amount of data according to the user's branch strategy. The beneficial effects brought are:

[0046] 1. After the low-code platform integrates gitlab, it can make full use of the characteristics of git to manage the code version of low-code like high-code, such as branch merging, viewing and rolling back branch history submission records, viewing and comparing resource history submission records, etc., and supports users to independently choose branch strategies.

[0047] 2. Unlike high-code, low-code resource comparison has a visual data page instead of a simple file content comparison, and provides a visual and configurable conflict resolution page.

[0048] 3. After the low-code platform is integrated with Gitlab, the metadata code is managed by git, which can better adapt to the DevOps R&D process and lay the foundation for the continuous delivery of low-code applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in describing the embodiments of the present application.

[0050] Figure 1 A flowchart of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0051] Figure 2 A branch strategy diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0052] Figure 3 An example diagram of a database design for a branch synchronization method of a low-code development platform provided in an embodiment of the present application;

[0053] Figure 4 A development flow chart of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0054] Figure 5 A branch list management diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0055] Figure 6 A code synchronization (commit, rollback) diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0056] Figure 7a A branch merging diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0057] Figure 7b A branch merging diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0058] Figure 8A merge (synchronization) conflict resolution diagram for a branch synchronization method of a low-code development platform provided in an embodiment of the present application;

[0059] Fig. 9 An application of a branch synchronization method for a low-code development platform provided in an embodiment of the present application, and a branch development diagram;

[0060] Fig.10 A branch merging diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0061] Fig.11 A branch synchronization diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0062] Fig.12 A development merge synchronization diagram of a branch synchronization method for a low-code development platform provided in an embodiment of the present application;

[0063] Fig.13 A schematic diagram of the structure of a branch synchronization system of a low-code development platform provided in an embodiment of the present application;

[0064] Fig.14 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application.

[0066] It will be understood by those skilled in the art that, unless otherwise stated, the singular forms "a", "an" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0067] The present invention application targets the characteristics of the low-code development platform to support various branch strategies, integrate and flexibly use various processes in the high-code R&D process, break the gap between high and low code, retain the advantages of low-code development while being fully compatible with the various advantages of high-code development.

[0068] In order to make the objectives, technical solutions and advantages of the present application more clear, the specific implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0069] The core of the present invention is to provide a branch synchronization method for a low-code development platform. Figure 1 The figure is a flow chart of the branch synchronization method of the low-code development platform provided in this embodiment. In order to better understand the method, Figure 1 The technical solution of this embodiment is described in detail:

[0070] Step S1: Add a branch name field to all data in the database to associate with the corresponding git branch;

[0071] Step S2: when a new git branch is created on the platform, if the database does not have the branch data, synchronize the database with the corresponding branch code; if the database has the branch data, develop based on the database;

[0072] Step S3: Synchronize the data of the git branch and the corresponding branch of the database to realize the addition and deletion of the client operation branch and the synchronization of the addition and deletion of the database data;

[0073] Step S4: Use the same database table structure design according to different environments, and determine the amount of data based on the user branching strategy.

[0074] For example, if the production environment maintains a single branch data iterative release, the branch fields can be controlled to be consistent; if the business test environment adopts the strategy of releasing one branch, the branch fields are also controlled to be consistent; if the development environment supports multi-branch parallel development, different branch data will exist in the database.

[0075] In this embodiment, the database stores data by branch, which can meet the needs of using different git branch strategies. The data in the database has a branch mark field, and the data in the git library does not have a branch mark field (the branch name itself is the mark, and even if the branch field exists in the file data, it needs to be ignored in some comparison or storage operations, and the actual branch name is used as the basis). When branches are merged, they are still judged as the same resource based on the files with the same resource number. Different branch resources are newly assigned different resource numbers (it is impossible to create the same resource).

[0076] The preferred embodiment of this invention further comprises:

[0077] Step S201: After logging in, configure the git tool chain information and configure the associated git repository;

[0078] Step S202: The local warehouse is on the background server. The standard warehouse directory is used for development and synchronization, and the temp directory is used for merging and displaying historical versions.

[0079] The preferred embodiment of this invention further comprises:

[0080] Step S301: Based on the development of the database, the changed content after modification and saving is directly in the database;

[0081] Step S302: When selecting branch development, first synchronize the database branch with the remote branch. If the database does not have the branch data, pull the corresponding branch data from the gitlab remote and write it into the library before developing. If the database has the branch data, based on the database development, the database record changes need to synchronize the git low-code data records, and modify the corresponding resource version management status to pending submission by modifying the resource snapshot table.

[0082] The preferred embodiment of this invention further comprises:

[0083] Step S401: Check out the original branch and the target branch to the server local warehouse temporary storage area through JGit;

[0084] Step S402: Implement Git diff-merge-base-name-status according to JGit to obtain a file set of branch merge resource changes;

[0085] Step S403: Provide the user with a list of resources for handling merge conflicts, and perform visual display based on the current status of each branch data in redis;

[0086] Step S404: Write the local temporary storage area file overwrite according to the resource object overwrite after the conflict is resolved, then mark the file to resolve the conflict, and use JGit to perform Git commit & push operations after the conflict is completely resolved.

[0087] The merge is for the remote git branch, and the operation does not affect the database data;

[0088] The merge uses a temporary local repository, which does not affect development synchronization;

[0089] After the merge is completed, the temporary warehouse will be cleared. When synchronizing branches, the difference in file changes between the last commitId of the current branch in the database and the last commitId of the corresponding remote branch will be analyzed to find out the list of resources that need to be pulled into the warehouse before the branch is submitted. At the same time, the version management status of the corresponding resources in the database will be used to determine whether there is a conflict. If there is no conflict, it will be forced into the warehouse. If there is a conflict, it will be forced into the warehouse after the conflict is resolved.

[0090] When merging, you can view the comparison of resources between the two branches. By comparing resource objects, you can identify the differences in specific fields and visualize them on the page.

[0091] The conflict resolution function includes comparison and editing capabilities, and supports unilateral selection and saving after re-editing.

[0092] The preferred embodiment of this invention further comprises:

[0093] Step S501: Synchronize the data of the selected branch database with the git remote repository;

[0094] Step S502: The local warehouse used synchronously is the same warehouse for development;

[0095] Step S503: The conflicting resources to be synchronized are obtained by comparing the resource list set after parsing the file set changed between the last commitID of the branch in the database and the commitID of the corresponding remote branch with the resource set marked as modified to be submitted in the database as the conflicting resource list;

[0096] Step S504: For resources that need to resolve conflicts, when the remote branch data status is selected to be stored in the database, the database corresponding resource status is marked as submitted. When the database is used or edited and developed to resolve the conflict, the database corresponding resource status is marked as pending submission.

[0097] Step S505: After the resource conflict is resolved and stored in the database, a list of resources to be submitted is provided for the user to select and process according to the database resource status;

[0098] Step S506: The resources to be synchronized are identified according to the database resource status.

[0099] The preferred embodiment of this invention further comprises:

[0100] Step S601: Obtain the branch history commit record through JGit, and obtain the specific commitID, obtain the file change set of the current commit change according to the commitID, and parse it into a low-code metadata object through unified rules;

[0101] Based on the user's selection of the corresponding metadata object or the commitID, resources are compared with the current data object. A visual low-code configuration page is provided for users to analyze the change differences. Users can also choose to use the historical version or re-edit it and write it to the database.

[0102] The preferred embodiment of this invention further comprises:

[0103] Step S701: Delete the local branch, and use JGit to perform a branch delete operation on the temporary storage area corresponding to the application branch under the server user name;

[0104] Step S702: Complete the remote deletion of the git branch, and use JGit to delete the remote branch;

[0105] Step S703: The remote branch is deleted successfully, and the corresponding branch data in the database is deleted at the same time.

[0106] The preferred embodiment of this invention further comprises:

[0107] Clear local warehouse: Delete the local warehouse to facilitate reinitialization of local warehouse data.

[0108] Clear the database: Delete the database, and develop again by re-importing the database based on the updated data in the local warehouse and developing again.

[0109] Clear the local repository and database: This is a combination of the first two clears. The difference from branch deletion is that the remote branch is not deleted.

[0110] In an embodiment of the present application, a branch name field is added to all data in the database to associate with the corresponding git branch; when a new git branch is created on the platform, if the database does not have the branch data, the corresponding branch code of the database is synchronized; if the database has the branch data, development is based on the database; the git branch and the data of the corresponding branch of the database are synchronized to realize the addition and deletion of client operation branches and the synchronous addition and removal of database data; the same set of database table structure design is adopted according to different environments, and the amount of data is determined according to the user's branch strategy.

[0111] Compared with the CN114661337A patent technology, this technology uses various low-code development business scenarios, supports various branch strategy models, and can achieve code version management for the entire life cycle of low-code development;

[0112] Compared with the patented technology of CN118642751A, this technology realizes the version management of each product through the baseline of git code, which is not limited to the final product, but the final code state. At the same time, it supports the detection of each final state code for hot repair development or branch demand development.

[0113] The beneficial effects of this embodiment are:

[0114] 1. After the low-code platform integrates gitlab, it can make full use of the characteristics of git to manage the code version of low-code like high-code, such as branch merging, viewing and rolling back branch history submission records, viewing and comparing resource history submission records, etc. It also supports users to choose branch strategies independently.

[0115] 2. Unlike high-code, low-code resource comparison has a visual data page, rather than a simple file content comparison. It also provides a visual, configurable conflict resolution page.

[0116] 3. After the low-code platform is integrated with Gitlab, the metadata code is managed by git, which can better adapt to the DevOps R&D process and lay the foundation for the continuous delivery of low-code applications.

[0117] based on Figure 1 The embodiment shown provides a branch synchronization method for a low-code development platform. Fig.13 A branch synchronization system of a low-code development platform provided in an embodiment of the present application is shown, such as Fig.13 As shown, the system can mainly include: 201 association module, 202 creation module, 203 synchronization module, 204 review module, wherein:

[0118] 201 Association module: used to add a branch name field to all data in the database to associate with the corresponding git branch;

[0119] 202 creation module: used for creating a new git branch on the platform. If the database does not have the branch data, the corresponding branch code of the database is synchronized; if the database has the branch data, the development is based on the database;

[0120] 203 Synchronization module: used to synchronize the data of git branches and corresponding branches in the database, so as to realize the addition and deletion of branches operated by the client and the synchronization of addition and deletion of database data;

[0121] 204 Audit Module: It is used to adopt the same database table structure design according to different environments and determine the amount of data according to the user branching strategy.

[0122] In an embodiment of the present application, a branch name field is added to all data in the database to associate with the corresponding git branch; when a new git branch is created on the platform, if the database does not have the branch data, the corresponding branch code of the database is synchronized; if the database has the branch data, development is based on the database; the git branch and the data of the corresponding branch of the database are synchronized to realize the addition and deletion of client operation branches and the synchronous addition and removal of database data; the same set of database table structure design is adopted according to different environments, and the amount of data is determined according to the user's branch strategy.

[0123] The beneficial effects of the embodiments of the present application are:

[0124] 1. After the low-code platform integrates gitlab, it can make full use of the characteristics of git to manage the code version of low-code like high-code, such as branch merging, viewing and rolling back branch history submission records, viewing and comparing resource history submission records, etc. It also supports users to choose branch strategies independently.

[0125] 2. Unlike high-code, low-code resource comparison has a visual data page, rather than a simple file content comparison. It also provides a visual, configurable conflict resolution page.

[0126] 3. After the low-code platform is integrated with Gitlab, the metadata code is managed by git, which can better adapt to the DevOps R&D process and lay the foundation for the continuous delivery of low-code applications.

[0127] It can be understood that the above modules of the branch synchronization system of the low-code development platform in this embodiment have the function of implementing Figure 1 The functions of the corresponding steps of the method in the embodiment shown in . The function can be implemented by hardware, or by hardware executing the corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The above modules can be software and / or hardware, and the above modules can be implemented separately or integrated with multiple modules. For the functional description of the above modules, please refer to Figure 1 The corresponding description of the method in the embodiment shown in will not be repeated here.

[0128] An embodiment of the present application provides an electronic device, including a processor and a memory;

[0129] A memory, used for storing operation instructions;

[0130] A processor is used to execute the branch synchronization method of the low-code development platform provided in any embodiment of the present application by calling an operation instruction.

[0131] As an example, Fig.14 A schematic diagram of the structure of an electronic device applicable to the embodiment of the present application is shown. Fig.14 As shown, the electronic device 2000 includes: a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, such as through a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that in actual applications, the transceiver 2004 is not limited to one, and the structure of the electronic device 2000 does not constitute a limitation on the embodiments of the present application.

[0132] The processor 2001 is applied in the embodiment of the present application to implement the method shown in the above method embodiment. The transceiver 2004 may include a receiver and a transmitter. The transceiver 2004 is applied in the embodiment of the present application to implement the function of the electronic device of the embodiment of the present application communicating with other devices when executed.

[0133] Processor 2001 may be a CPU (Central Processing Unit), a general purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0134] The bus 2002 may include a path to transmit information between the above components. The bus 2002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 2002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.14 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0135] The memory 2003 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0136] Optionally, the memory 2003 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 2001. The processor 2001 is used to execute the application code stored in the memory 2003 to implement the branch synchronization method of the low-code development platform provided in any embodiment of the present application.

[0137] The electronic device provided in the embodiment of the present application is applicable to any embodiment of the above method and will not be described in detail here.

[0138] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the branch synchronization method of the low-code development platform shown in the above method embodiment is implemented.

[0139] The computer-readable storage medium provided in the embodiments of the present application is applicable to any embodiment of the above method and will not be described in detail here.

[0140] The branch synchronization solution of the low-code development platform provided in the embodiment of the present application is to add a branch name field to all data in the database to associate the corresponding git branch; when a new git branch is created on the platform, if the database does not have the branch data, the corresponding branch code of the database is synchronized; if the database has the branch data, development is based on the database; synchronize the git branch and the data of the corresponding branch of the database to realize the addition and deletion of branches operated by the client and the synchronous addition and removal of database data; adopt the same set of database table structure design according to different environments, and determine the amount of data according to the user's branch strategy.

[0141] The beneficial effects are:

[0142] 1. After the low-code platform integrates gitlab, it can make full use of the characteristics of git to manage the code version of low-code like high-code, such as branch merging, viewing and rolling back branch history submission records, viewing and comparing resource history submission records, etc. It also supports users to choose branch strategies independently.

[0143] 2. Unlike high-code, low-code resource comparison has a visual data page, rather than a simple file content comparison. It also provides a visual, configurable conflict resolution page.

[0144] 3. After the low-code platform is integrated with Gitlab, the metadata code is managed by git, which can better adapt to the DevOps R&D process and lay the foundation for the continuous delivery of low-code applications.

[0145] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the specific system can be divided into different functional modules to complete all or part of the functions described above.

[0146] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0147] In several embodiments covered by the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, or it can be an electrical, mechanical or other form of connection.

[0148] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0149] In addition, each functional module in each embodiment of the present application can be implemented in the form of hardware or in the form of software functional modules. If these functional modules are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application is essentially or part of the prior art that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a computer program product, which includes one or more computer instructions. When loading and executing computer program instructions on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer program product is stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, a computer instruction can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0150] The above contents are merely examples and explanations of the structure of the present invention. The technicians in this technical field may make various modifications or additions to the specific embodiments described or replace them in a similar manner. As long as they do not deviate from the structure of the invention or exceed the scope defined by the claims, they should all fall within the protection scope of the present invention.

Claims

1. A branch synchronization method for a low-code development platform, characterized in that: The following steps are involved: Step S1: Add a branch name field to all data in the database to associate with the corresponding git branch; Step S2: when a new git branch is created on the platform, if the database does not have the branch data, synchronize the database with the corresponding branch code; if the database has the branch data, develop based on the database; Step S3: Synchronize the data of the git branch and the corresponding branch of the database to realize the addition and deletion of the client operation branch and the synchronization of the addition and deletion of the database data; Step S4: Use the same database table structure design according to different environments, and determine the amount of data based on the user branching strategy.

2. The branch synchronization method of the low-code development platform according to claim 1, characterized in that: The method further comprises: Step S201: After logging in, configure the git tool chain information and configure the associated git repository; Step S202: The local warehouse is on the background server. The standard warehouse directory is used for development and synchronization, and the temp directory is used for merging and displaying historical versions.

3. The branch synchronization method of the low-code development platform according to claim 1 is characterized in that: The method further comprises: Step S301: Based on the development of the database, the changed content after modification and saving is directly in the database; Step S302: When selecting branch development, first synchronize the database branch with the remote branch. If the database does not have the branch data, pull the corresponding branch data from the gitlab remote and write it into the library before developing. If the database has the branch data, based on the database development, the database record changes need to synchronize the git low-code data records, and modify the corresponding resource version management status to pending submission by modifying the resource snapshot table.

4. The branch synchronization method of the low-code development platform according to claim 1, characterized in that: The method further comprises: Step S401: Check out the original branch and the target branch to the server local warehouse temporary storage area through JGit; Step S402: Implement Git diff-merge-base-name-status according to JGit to obtain a file set of branch merge resource changes; Step S403: Provide the user with a list of resources for handling merge conflicts, and perform visual display based on the current status of each branch data in redis; Step S404: Write the local temporary storage area file overwrite according to the resource object overwrite after the conflict is resolved, then mark the file to resolve the conflict, and use JGit to perform Git commit & push operations after the conflict is completely resolved.

5. The branch synchronization method of the low-code development platform according to claim 1, characterized in that: The method further comprises: Step S501: Synchronize the data of the selected branch database with the git remote repository; Step S502: The local warehouse used synchronously is the same warehouse for development; Step S503: The conflicting resources to be synchronized are obtained by comparing the resource list set after parsing the file set changed between the last commitID of the branch in the database and the commitID of the corresponding remote branch with the resource set marked as modified to be submitted in the database as the conflicting resource list; Step S504: For resources that need to resolve conflicts, when the remote branch data status is selected to be stored in the database, the database corresponding resource status is marked as submitted. When the database is used or edited and developed to resolve the conflict, the database corresponding resource status is marked as pending submission. Step S505: After the resource conflict is resolved and stored in the database, a list of resources to be submitted is provided for the user to select and process according to the database resource status; Step S506: The resources to be synchronized are identified according to the database resource status.

6. The branch synchronization method of the low-code development platform according to claim 1, characterized in that: The method further comprises: Step S601: Obtain the branch history commit record through JGit, and obtain the specific commitID, obtain the file change set of the current commit change according to the commitID, and parse it into a low-code metadata object through unified rules; Based on the user's selection of the corresponding metadata object or the commitID, resources are compared with the current data object. A visual low-code configuration page is provided for users to analyze the change differences. Users can also choose to use the historical version or re-edit it and write it to the database.

7. The branch synchronization method of the low-code development platform according to claim 1, characterized in that: The method further comprises: Step S701: Delete the local branch, and use JGit to perform a branch delete operation on the temporary storage area corresponding to the application branch under the server user name; Step S702: Complete the remote deletion of the git branch, and use JGit to delete the remote branch; Step S703: The remote branch is deleted successfully, and the corresponding branch data in the database is deleted at the same time.

8. A branch synchronization system for a low-code development platform, characterized in that: The system includes: an association module, a creation module, a synchronization module, and an audit module, wherein: Association module: used to add a branch name field to all data in the database to associate with the corresponding git branch; Creation module: when creating a new git branch on the platform, if the database does not have the branch data, synchronize the database corresponding branch code; if the database has the branch data, develop based on the database; Synchronization module: used to synchronize the data of git branches and corresponding branches in the database, so as to realize the addition and deletion of branches operated by the client and the synchronization of addition and deletion of database data; Audit module: used to adopt the same database table structure design according to different environments and determine the amount of data based on the user's branching strategy.

9. An electronic device, characterized in that: including a processor and a memory; The memory is used to store operation instructions; The processor is used to execute the method according to any one of claims 1 to 7 by calling the operation instruction.

10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images