CN119806487A - A branch synchronization method, system, device and readable storage medium for a low-code development platform - Google Patents
A branch synchronization method, system, device and readable storage medium for a low-code development platform Download PDFInfo
- Publication number
 - CN119806487A CN119806487A CN202411784424.1A CN202411784424A CN119806487A CN 119806487 A CN119806487 A CN 119806487A CN 202411784424 A CN202411784424 A CN 202411784424A CN 119806487 A CN119806487 A CN 119806487A
 - Authority
 - CN
 - China
 - Prior art keywords
 - branch
 - database
 - data
 - code
 - git
 - Prior art date
 - Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
 - Pending
 
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
 
Abstract
The embodiment of the specification relates to the technical field of computers and provides a branch synchronization method, a system, equipment and a readable storage medium of a low-code development platform, wherein the method comprises the steps of newly adding branch name fields for all data in a database to associate corresponding git branches; when a platform builds a git branch, synchronizing the corresponding branch codes of the database if the database does not have the branch data, developing the database based on the database if the database has the branch data, synchronizing the data of the git branch and the corresponding branch of the database to realize the new addition and deletion of the operation branch of a client and the synchronous new addition and removal of the database data, adopting the same set of database table structure design according to different environments, and determining the data quantity according to a user branch strategy. The embodiment of the specification can fully utilize the characteristic of git, manage the code version of the low code like the high code, better adapt to the development process of the DevOps and lay a foundation for continuous delivery of the low code application.
    Description
Technical Field
      The present application relates to the field of computer technologies, and in particular, to a branch synchronization method, system, device, and readable storage medium for a low code development platform.
    Background
      The low code is an application development method, and compared with the traditional application development, the program code of the low code is actually a piece of data in the database. However, since program development is performed, the requirement of multi-branch parallel development is faced, and version management problems such as history archiving, branch management, code review, synchronous merging and the like are performed on the branch codes.
      Currently, the low-code platform in the industry generally only supports single-branch development iteration, and version management can not flexibly iterate and manage changes like high-code development by performing version filing on the final product or the metadata of the final state. The prior art CN114661337A patent technology uses JGit to maintain the version of metadata of a service subsystem, is mainly used for a middle platform system to acquire different version data, is limited in application scene, does not manage the code version of each state in the low code development process, and is not capable of effectively avoiding conflicts of multi-person collaborative development due to the fact that the prior art CN118642751A patent technology focuses on managing low code application version products after application development is completed, and cannot perform code management, baseline management, historical trace and the like of each development state of the low code in the development process.
      Therefore, the technical scheme is provided that before low-code application development, a development baseline can be confirmed according to a version management record, new requirements are changed or iterated, iterative development is carried out on the basis of a corresponding correct production operation version, in the development process, different branch strategies can be selected to be used for collaborative parallel development with each developer according to project characteristics and development progress and development habits of the developer, after development is completed, each branch code can be combined, handover test versions are controlled, single products are guaranteed, and baseline version following and label management are carried out on an online version.
    Disclosure of Invention
      In order to solve the problems, the technical scheme adopted by the application is as follows:
       in a first aspect, an embodiment of the present application provides a branch synchronization method of a low-code development platform, where the method includes the following steps: 
       Step S1, newly adding branch name fields for all data in a database to associate corresponding git branches; 
       Step S2, synchronizing a branch code corresponding to the database if the database has no branch data when a building of a git branch is established on the platform; 
       Step S3, synchronizing the data of the git branch and the corresponding branch of the database to realize the new addition and deletion of the operation branch of the client and the new addition and removal of the database data; 
       And S4, adopting the same set of database table structural design according to different environments, and determining the data quantity according to a user branching strategy. 
      Optionally, the method further comprises:
       step S201, configuring the git tool chain information after logging in and configuring an associated git warehouse; 
       step S202, developing and synchronously using standard warehouse catalogs by a local warehouse at a background server, and merging and displaying historical version use temp catalogs. 
      Optionally, the method further comprises:
       Step S301, based on the development of the database, modifying the stored changed content to be the database directly; 
       Step S302, when branch development is selected, synchronization of a database branch and a remote branch is firstly carried out, if the database does not have the branch data, remote corresponding branch data are pulled gitlab to be written into a warehouse for development, and if the database has the branch data, based on the database development, the database record is changed to a low-code data record requiring synchronization git, and the low-code data record is modified to be submitted by modifying a resource version management state corresponding to a resource snapshot table. 
      Optionally, the method further comprises:
       Step S401, detecting an original branch and a target branch to a server local warehouse temporary storage area through JGit; 
       step S402, obtaining a file set of the branch merging resource change according to JGit to realize Git diff-merge-base-name-status; 
       Step S403, providing a resource list for processing the merging conflict by a user, and performing visual anti-display according to the current situation of each branch data in the redis; 
       And S404, overwriting and writing the local temporary storage area file coverage according to the resource object after conflict resolution, then resolving conflict for file marks, and performing Git commit & push operation by utilizing JGit after the conflict is completely resolved. 
      Optionally, the method further comprises:
       step S501, synchronizing data of a selected branch database with the data of the git remote warehouse; 
       step S502, the synchronous local warehouse is to develop the same set of warehouse; 
       Step S503, the synchronous conflict resource is derived from the situation that a resource list set after analysis of a file set changed between the last commitID of the branch of the database and the remote corresponding branch commitID is compared with a resource set marked as modification to be submitted by the database and is used as a conflict resource list; 
       Step S504, aiming at the resource needing conflict resolution, when the remote branch data state is selected to be put in storage, the corresponding resource state of the database is marked as submitted, and when the database is selected to be used or the conflict is resolved by editing and developing, the corresponding resource state of the database is modified as to be submitted; 
       step S505, after the resource conflict is resolved and put in storage, providing a resource to-be-submitted list for the user to select and process according to the database resource state; 
       Step S506, identifying the resources to be synchronized according to the database resource state. 
      Optionally, the method further comprises:
       step S601, acquiring a branch history submitting record through JGit, acquiring a concrete commitID, acquiring a file change set of a current submitting change according to commitID, and analyzing the file change set into a low-code metadata object through a unified rule; 
       and (3) performing resource comparison with the current data object according to the selection of the corresponding metadata object or the selection commitID of the user, analyzing the change difference by the user through the visualized low-code configuration page, and simultaneously selecting a use history version or writing the use history version into the database after new editing on the basis. 
      Optionally, the method further comprises:
       step S701, deleting a local branch, and performing branch delete operation on a temporary storage area corresponding to an application branch under a server user name by utilizing JGit; 
       Step S702, completing the remote deletion of the git branch, and utilizing JGit to delete the remote branch; 
       step 703, the remote branch deletion is successful, and the corresponding branch data of the database is deleted. 
      In a second aspect, the invention provides a branch synchronization system of a low-code development platform, which comprises an association module, a creation module, a synchronization module and an auditing module, wherein,
      The association module is used for newly adding branch name fields for all data in the database so as to associate corresponding git branches;
       The creation module is used for synchronizing the corresponding branch codes of the database if the database has no branch data when the platform creates the git branch, and developing based on the database if the database has the branch data; 
       The synchronization module is used for synchronizing the data of the git branch and the corresponding branch of the database so as to realize the synchronization of the addition and deletion of the operation branch of the client and the data addition and deletion of the database; 
       and the auditing module is used for adopting the same set of database table structural design according to different environments and determining the data quantity according to the user branching strategy. 
      In a third aspect, the present invention provides an electronic device comprising a processor and a memory;
       The memory is used for storing operation instructions; 
       and the processor is used for executing the branch synchronization method of the low-code development platform by calling the operation instruction. 
      In a fourth aspect, the present invention provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method of branch synchronization for a low code development platform as described above.
      The branch synchronization scheme of the low-code development platform disclosed by the specification is characterized in that branch name fields are newly added for all data in a database to correlate corresponding git branches, when the platform builds a git branch, if the database does not have the branch data, the database is synchronized to correspond to branch codes, if the database has the branch data, the database is developed based on the database, the data of the git branch and the data of the database corresponding to the branch are synchronized, so that the new addition and deletion of a client operation branch and the synchronization and the new addition and removal of the database data are realized, the same set of database table structural design is adopted according to different environments, and the data quantity is determined according to a user branch strategy. The beneficial effects brought are as follows:
       1. After the low code platform is integrated gitlab, the characteristics of git can be fully utilized to manage the code version of the low code like the high code, such as branch merging, checking and backspacing of branch history submitting records, checking and peer-to-peer of resource history submitting records, and supporting the independent selection of a branch strategy by a user. 
      2. Unlike the high code, the low code resource alignment has visual data pages, rather than simple file content alignment, and provides a conflict resolution page of visual orchestration configuration.
      3. After the low code platform is integrated Gitlab, metadata codes are managed by git, so that the development process of the DevOps can be better adapted, and a foundation is laid for continuous delivery of low code application.
    Drawings
      In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings that are required to be used in the description of the embodiments of the present application will be briefly described below.
      FIG. 1 is a schematic flow chart of a branch synchronization method of a low-code development platform according to an embodiment of the present application;
       FIG. 2 is a schematic diagram of a branch policy of a method for synchronizing branches of a low-code development platform according to an embodiment of the present application; 
       FIG. 3 is a diagram illustrating an exemplary database design of a branch synchronization method for a low-code development platform according to an embodiment of the present application; 
       FIG. 4 is a development flow chart of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 5 is a branch list management diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 6 is a code synchronization (commit and rollback) diagram of a branch synchronization method for a low code development platform according to an embodiment of the present application; 
       FIG. 7a is a branch merging diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 7b is a branch merging diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 8 is a merging (synchronization) conflict resolution diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 9 is an application and branch development diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 10 is a branch merging diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 11 is a branch synchronization diagram of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 12 is a diagram of a combined synchronization scenario for the development of a branch synchronization method of a low-code development platform according to an embodiment of the present application; 
       FIG. 13 is a schematic diagram of a branch synchronization system of a low-code development platform according to an embodiment of the present application; 
       Fig. 14 is a schematic structural diagram of an electronic device according to an embodiment of the present application. 
    Detailed Description
      Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative only and are not to be construed as limiting the application.
      As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The term "and/or" as used herein includes all or any element and all combination of one or more of the associated listed items.
      Aiming at the characteristics of a low-code development platform, the invention realizes integration and flexible application of various processes in a high-code development flow for supporting various branch strategies, breaks the gap between high and low codes, reserves the advantages of low-code development and is fully compatible with various advantages of high-code development.
      In order to make the objects, technical solutions and advantages of the present application more apparent, the following detailed description of the present application will be given with reference to the accompanying drawings.
      The core of the present invention is to provide a branch synchronization method of a low-code development platform, fig. 1 is a flow chart of the branch synchronization method of the low-code development platform provided in this embodiment, and in order to better understand the method, a technical scheme of this embodiment will be discussed in detail with reference to fig. 1:
       Step S1, newly adding branch name fields for all data in a database to associate corresponding git branches; 
       Step S2, synchronizing a branch code corresponding to the database if the database has no branch data when a building of a git branch is established on the platform; 
       Step S3, synchronizing the data of the git branch and the corresponding branch of the database to realize the new addition and deletion of the operation branch of the client and the new addition and removal of the database data; 
       And S4, adopting the same set of database table structural design according to different environments, and determining the data quantity according to a user branching strategy. 
      For example, the production environment keeps iterative version of single-branch data, the branch fields can be controlled to be consistent all the time, the service test environment also controls the branch fields to be consistent if adopting a release one-branch strategy, and the development environment supports multi-branch parallel development, so that different branch data exist in the database.
      In this embodiment, the data is stored in the database according to branches, so that different git branching strategies can be satisfied. The data of the database is provided with a branch mark field, the data of the git library is not provided with a branch mark field (the branch name is a mark, even if the branch field exists in the file data, the branch field needs to be ignored in some comparison or warehousing operations and is based on the actual branch name), and the same resource is judged according to the same file with the same resource number when the branches are combined. Different branch resources are newly allocated with different resource numbers (the same resource cannot be newly built).
      The preferred mode of this embodiment further includes:
       step S201, configuring the git tool chain information after logging in and configuring an associated git warehouse; 
       step S202, developing and synchronously using standard warehouse catalogs by a local warehouse at a background server, and merging and displaying historical version use temp catalogs. 
      The preferred mode of this embodiment further includes:
       Step S301, based on the development of the database, modifying the stored changed content to be the database directly; 
       Step S302, when branch development is selected, synchronization of a database branch and a remote branch is firstly carried out, if the database does not have the branch data, remote corresponding branch data are pulled gitlab to be written into a warehouse for development, and if the database has the branch data, based on the database development, the database record is changed to a low-code data record requiring synchronization git, and the low-code data record is modified to be submitted by modifying a resource version management state corresponding to a resource snapshot table. 
      The preferred mode of this embodiment further includes:
       Step S401, detecting an original branch and a target branch to a server local warehouse temporary storage area through JGit; 
       step S402, obtaining a file set of the branch merging resource change according to JGit to realize Git diff-merge-base-name-status; 
       Step S403, providing a resource list for processing the merging conflict by a user, and performing visual anti-display according to the current situation of each branch data in the redis; 
       And S404, overwriting and writing the local temporary storage area file coverage according to the resource object after conflict resolution, then resolving conflict for file marks, and performing Git commit & push operation by utilizing JGit after the conflict is completely resolved. 
      The merging aims at a far-end git branch, and the operation does not influence database data;
       The temporary local warehouse is utilized in combination, and development synchronization is not affected during combination; 
       and after merging, clearing the temporary warehouse, analyzing a resource list needing pull warehousing before re-branch submission according to the file change difference between the last commitId of the current branch of the database and the last commitId of the remote corresponding branch during branch synchronization, and judging whether the resources conflict according to the version management state of the corresponding resources of the database. And (5) forcedly warehousing the conflict without conflict, and warehousing the conflict after forcedly resolving the conflict. 
      And when merging, supporting to check the comparison condition of the two branch resources, identifying the difference of specific fields through the comparison resource objects, and performing visual anti-display on the page.
      The conflict resolution function comprises comparison capability and editing capability, and supports selection of a single side and storage after re-editing.
      The preferred mode of this embodiment further includes:
       step S501, synchronizing data of a selected branch database with the data of the git remote warehouse; 
       step S502, the synchronous local warehouse is to develop the same set of warehouse; 
       Step S503, the synchronous conflict resource is derived from the situation that a resource list set after analysis of a file set changed between the last commitID of the branch of the database and the remote corresponding branch commitID is compared with a resource set marked as modification to be submitted by the database and is used as a conflict resource list; 
       Step S504, aiming at the resource needing conflict resolution, when the remote branch data state is selected to be put in storage, the corresponding resource state of the database is marked as submitted, and when the database is selected to be used or the conflict is resolved by editing and developing, the corresponding resource state of the database is modified as to be submitted; 
       step S505, after the resource conflict is resolved and put in storage, providing a resource to-be-submitted list for the user to select and process according to the database resource state; 
       Step S506, identifying the resources to be synchronized according to the database resource state. 
      The preferred mode of this embodiment further includes:
       step S601, acquiring a branch history submitting record through JGit, acquiring a concrete commitID, acquiring a file change set of a current submitting change according to commitID, and analyzing the file change set into a low-code metadata object through a unified rule; 
       and (3) performing resource comparison with the current data object according to the selection of the corresponding metadata object or the selection commitID of the user, analyzing the change difference by the user through the visualized low-code configuration page, and simultaneously selecting a use history version or writing the use history version into the database after new editing on the basis. 
      The preferred mode of this embodiment further includes:
       step S701, deleting a local branch, and performing branch delete operation on a temporary storage area corresponding to an application branch under a server user name by utilizing JGit; 
       Step S702, completing the remote deletion of the git branch, and utilizing JGit to delete the remote branch; 
       step 703, the remote branch deletion is successful, and the corresponding branch data of the database is deleted. 
      The preferred mode of this embodiment further includes:
       and (3) emptying the local warehouse, namely deleting the local warehouse, so that the local warehouse data can be conveniently initialized from new. 
      And (3) emptying the database, namely deleting the database, and redeveloping the data from the newly imported database after updating according to the local warehouse.
      The combination of the first two empties, distinguished from branch deletion, is that remote branches are not deleted.
      In the embodiment of the application, branch name fields are newly added for all data in a database to correlate corresponding git branches, when a platform builds a git branch, if the database does not have the branch data, the database corresponds to a branch code, if the database has the branch data, the database is developed based on the database, the data of the git branch and the database corresponds to the branch are synchronized, so that the new addition and deletion of a client operation branch and the synchronous new addition and removal of the database data are realized, the same set of database table structural design is adopted according to different environments, and the data quantity is determined according to a user branch strategy.
      Compared with the CN114661337A patent technology, the technology uses various low-code development business scenes to support various branch strategy models, and can realize code version management on the whole life cycle of low-code development;
       In contrast to the CN118642751a patent technology, the present technology implements version management of individual artifacts through baselines of the git code, not limiting the final artifact, but the final code state. And simultaneously, the hot repair development or the branch demand development is supported by detecting each final state code. 
      The beneficial effects of this embodiment are:
       1. After the low code platform is integrated gitlab, the characteristics of git can be fully utilized to manage the code version of the low code like the high code, such as branch merging, checking and rollback of a branch history submitting record, checking and comparing a resource history submitting record, and the like. And supports the autonomous selection of a branching strategy by the user. 
      2. Unlike the high code, the low code resource alignment has visual data pages rather than simple file content alignment. And provide a conflict resolution page that visualizes the orchestratable configuration.
      3. After the low code platform is integrated Gitlab, metadata codes are managed by git, so that the development process of the DevOps can be better adapted, and a foundation is laid for continuous delivery of low code application.
      Based on the branch synchronization method of the low-code development platform provided by the embodiment shown in fig. 1, fig. 13 shows a branch synchronization system of the low-code development platform provided by the embodiment of the application, and as shown in fig. 13, the system mainly includes a 201 association module, a 202 creation module, a 203 synchronization module, and a 204 auditing module, wherein,
      The 201 association module is used for newly adding branch name fields for all data in the database so as to associate corresponding git branches;
       202 creating module for synchronizing the corresponding branch code of the database if the database has no branch data when the platform creates the git branch, and developing based on the database if the database has the branch data; 
       203 a synchronization module for synchronizing the data of the git branch and the corresponding branch of the database to realize the new addition and deletion of the operation branch of the client and the synchronization of the data addition and deletion of the database; 
       And 204, an auditing module is used for adopting the same set of database table structural design according to different environments and determining the data quantity according to the user branching strategy. 
      In the embodiment of the application, branch name fields are newly added for all data in a database to correlate corresponding git branches, when a platform builds a git branch, if the database does not have the branch data, the database corresponds to a branch code, if the database has the branch data, the database is developed based on the database, the data of the git branch and the database corresponds to the branch are synchronized, so that the new addition and deletion of a client operation branch and the synchronous new addition and removal of the database data are realized, the same set of database table structural design is adopted according to different environments, and the data quantity is determined according to a user branch strategy.
      The embodiment of the application has the beneficial effects that:
       1. After the low code platform is integrated gitlab, the characteristics of git can be fully utilized to manage the code version of the low code like the high code, such as branch merging, checking and rollback of a branch history submitting record, checking and comparing a resource history submitting record, and the like. And supports the autonomous selection of a branching strategy by the user. 
      2. Unlike the high code, the low code resource alignment has visual data pages rather than simple file content alignment. And provide a conflict resolution page that visualizes the orchestratable configuration.
      3. After the low code platform is integrated Gitlab, metadata codes are managed by git, so that the development process of the DevOps can be better adapted, and a foundation is laid for continuous delivery of low code application.
      It will be appreciated that the above modules of the branch synchronization system of the low code development platform in this embodiment have the functionality to implement the corresponding steps of the method in the embodiment shown in fig. 1. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above. The modules may be software and/or hardware, and each module may be implemented separately or may be implemented by integrating multiple modules. The functional description of the above modules may be specifically referred to the corresponding description of the method in the embodiment shown in fig. 1, and will not be repeated herein.
      The embodiment of the application provides electronic equipment, which comprises a processor and a memory;
       a memory for storing operation instructions; 
       and the processor is used for executing the branch synchronization method of the low-code development platform provided in any embodiment of the application by calling the operation instruction. 
      As an example, fig. 14 shows a schematic structural diagram of an electronic device to which the embodiment of the present application is applied, and as shown in fig. 14, the electronic device 2000 includes a processor 2001 and a memory 2003. The processor 2001 is coupled to a memory 2003, such as via a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that, in practical applications, the transceiver 2004 is not limited to one, and the structure of the electronic device 2000 is not limited to the embodiment of the present application.
      The processor 2001 is used 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, and the transceiver 2004 is employed in embodiments of the present application to perform functions that enable an electronic device of embodiments of the present application to communicate with other devices.
      The Processor 2001 may be a CPU (Central Processing Unit ), general purpose Processor, DSP (DIGITAL SIGNAL Processor, data signal Processor), ASIC (Application SPECIFIC INTEGRATED Circuit), FPGA (Field Programmable GATE ARRAY ) or other programmable logic device, transistor logic device, hardware component, or any combination thereof. Which may implement or perform the various exemplary logic blocks, modules and circuits described in connection with this disclosure. The processor 2001 may also be a combination of computing functions, e.g., comprising one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.
      Bus 2002 may include a path to transfer information between the components. Bus 2002 may be a PCI (PERIPHERAL COMPONENT INTERCONNECT, peripheral component interconnect Standard) bus or an EISA (Extended Industry Standard Architecture ) bus, or the like. The bus 2002 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 14, but not only one bus or one type of bus.
      The Memory 2003 may be, but is not limited to, a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory ) or other type of dynamic storage device that can store information and instructions, an EEPROM (ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY ), a CD-ROM (Compact Disc Read Only Memory, compact disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
      Optionally, a memory 2003 is used for storing application code for executing aspects of the present application and is controlled for execution by the processor 2001. Processor 2001 is operative to execute application code stored in memory 2003 to implement the branch synchronization method of the low code development platform provided in any of the embodiments of the present application.
      The electronic device provided by the embodiment of the present application is applicable to any embodiment of the above method, and will not be described herein.
      The embodiment of the application provides a computer readable storage medium, and a computer program is stored on the computer readable storage medium, and when the program is executed by a processor, the branch synchronization method of the low-code development platform shown in the embodiment of the method is realized.
      The computer readable storage medium provided in the embodiments of the present application is applicable to any one of the embodiments of the above method, and will not be described herein.
      The branch synchronization scheme of the low-code development platform provided by the embodiment of the application is characterized in that branch name fields are newly added for all data in a database to correlate corresponding git branches, when the platform builds a git branch, if the database does not have the branch data, the database is synchronized to correspond to branch codes, if the database has the branch data, the database is developed based on the database, the git branch and the data of the database corresponding to the branch are synchronized, so that the synchronization of the addition and deletion of a client operation branch and the synchronization and the new addition and removal of the database data are realized, the same set of database table structural design is adopted according to different environments, and the data quantity is determined according to a user branch strategy.
      The beneficial effects are as follows:
       1. After the low code platform is integrated gitlab, the characteristics of git can be fully utilized to manage the code version of the low code like the high code, such as branch merging, checking and rollback of a branch history submitting record, checking and comparing a resource history submitting record, and the like. And supports the autonomous selection of a branching strategy by the user. 
      2. Unlike the high code, the low code resource alignment has visual data pages rather than simple file content alignment. And provide a conflict resolution page that visualizes the orchestratable configuration.
      3. After the low code platform is integrated Gitlab, metadata codes are managed by git, so that the development process of the DevOps can be better adapted, and a foundation is laid for continuous delivery of low code application.
      From the foregoing description of the embodiments, it will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of functional modules is illustrated, and in practical application, the above-described functional allocation may be implemented by different functional modules according to needs, i.e. the internal structure of a specific system is divided into different functional modules to implement all or part of the functions described above.
      Those of ordinary skill in the art will appreciate that the various illustrative modules and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
      In several embodiments covered by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the division of modules is merely a logical function division, and there may be another division manner in actual implementation, for example, multiple modules or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices, or modules, or may be an electrical, mechanical, or other form of connection.
      The modules illustrated as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment of the application.
      In addition, each functional module in the embodiments of the present application may be implemented in the form of hardware or software functional modules. These functional modules, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application is essentially or partly contributing to the prior art, or all or part of the technical solution may be embodied in the form of a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable devices. The computer program product is stored on or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer readable storage media can be any available media that can be accessed by a computer or data storage devices, such as servers, data centers, etc., that contain an integration of one or more available media. Usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tape), optical media (e.g., DVD), or semiconductor media (e.g., solid state disk Solid STATE DISK (SSD)), among others.
      The foregoing is merely illustrative of the structures of this invention and various modifications, additions and substitutions for those skilled in the art can be made to the described embodiments without departing from the scope of the invention or from the scope of the invention as defined in the accompanying claims.
    Claims (10)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title | 
|---|---|---|---|
| CN202411784424.1A CN119806487A (en) | 2024-12-06 | 2024-12-06 | A branch synchronization method, system, device and readable storage medium for a low-code development platform | 
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title | 
|---|---|---|---|
| CN202411784424.1A CN119806487A (en) | 2024-12-06 | 2024-12-06 | A branch synchronization method, system, device and readable storage medium for a low-code development platform | 
Publications (1)
| Publication Number | Publication Date | 
|---|---|
| CN119806487A true CN119806487A (en) | 2025-04-11 | 
Family
ID=95264781
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date | 
|---|---|---|---|
| CN202411784424.1A Pending CN119806487A (en) | 2024-12-06 | 2024-12-06 | A branch synchronization method, system, device and readable storage medium for a low-code development platform | 
Country Status (1)
| Country | Link | 
|---|---|
| CN (1) | CN119806487A (en) | 
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| CN120491951A (en) * | 2025-07-16 | 2025-08-15 | 苏州元脑智能科技有限公司 | Cross-platform visualization system, method, device, medium and program product | 
- 
        2024
        
- 2024-12-06 CN CN202411784424.1A patent/CN119806487A/en active Pending
 
 
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| CN120491951A (en) * | 2025-07-16 | 2025-08-15 | 苏州元脑智能科技有限公司 | Cross-platform visualization system, method, device, medium and program product | 
| CN120491951B (en) * | 2025-07-16 | 2025-10-03 | 苏州元脑智能科技有限公司 | Cross-platform visualization system, method, device, medium and program product | 
Similar Documents
| Publication | Publication Date | Title | 
|---|---|---|
| EP2260413B1 (en) | Web content management | |
| US10725976B2 (en) | Fast recovery using self-describing replica files in a distributed storage system | |
| CN100377099C (en) | Method for managing multiple file states for replicated files | |
| CN109086388B (en) | Block chain data storage method, device, equipment and medium | |
| EP1559039B1 (en) | Methods and systems for controlling access to a data object by means of locks | |
| US8756196B2 (en) | Propagating tables while preserving cyclic foreign key relationships | |
| CN103890709A (en) | Cache based key-value store mapping and replication | |
| US20070214195A1 (en) | Idempotent journal mechanism for file system | |
| CN110941547B (en) | Automatic test case library management method, device, medium and electronic equipment | |
| CN119806487A (en) | A branch synchronization method, system, device and readable storage medium for a low-code development platform | |
| CN116450107B (en) | Method and device for secondary development of software by low-code platform and electronic equipment | |
| US8589454B2 (en) | Computer data file merging based on file metadata | |
| US20080059941A1 (en) | Method and system for supporting a collaborative development environment | |
| CN117573564B (en) | Method for automatically identifying differences based on gitlab code submitted log | |
| CN111813346A (en) | Method, system, device and medium for establishing Ceph distributed storage based on cloud platform | |
| US8214410B2 (en) | Conflict management in a versioned file system | |
| CN105808451B (en) | Data caching method and related device | |
| US20080046676A1 (en) | Efficient synchronised updates to a data record in a data store | |
| CN111984598A (en) | High-performance metadata log file management method, system, medium and terminal | |
| US20240394226A1 (en) | System and method for editing a file-backed database table | |
| JP7703652B2 (en) | Intent Tracking for Asynchronous Behavior | |
| TWI796943B (en) | A processing system that realizes high-efficiency computing by using cache mirroring data | |
| CN109918355A (en) | Realize the virtual metadata mapped system and method for the NAS based on object storage service | |
| US11948024B2 (en) | Automated dynamic payload testing of OData APIs | |
| CN120670401A (en) | Data migration method, device, medium and program product | 
Legal Events
| Date | Code | Title | Description | 
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |