Code management platform, method and equipment and storage medium

Abstract

The invention discloses a code management platform, method and device and a storage medium, and relates to the technical field of code management, and the disclosed code management platform comprises a project management module which is used for responding to a project creation instruction and creating a development branch corresponding to a project version, and the development branch comprises files associated with the project version; the file management module is used for synchronizing the code of each file to the mirror image development branch associated with the project version in a code test stage; and the code publishing module is used for selecting the target code from the mirror image development branches according to the label of each code in a code publishing stage and synchronizing the target code to a preset production branch. According to the invention, a convenient and reliable code management platform can be provided to improve the project development efficiency.

Description

Technical Field

[0001] This application relates to the field of code management technology, and in particular to code management platforms, methods, devices and storage media. Background Technology

[0002] With the increasing popularity of distributed software development and collaboration, code management platforms have become a core infrastructure supporting modern software engineering.

[0003] Git (a distributed version control system) is currently the mainstream code management platform. It focuses on code version storage and basic branch management functions. However, its integration support for project management, file synchronization, and code release is not perfect. Developers usually need to manually perform code synchronization and release tasks, which increases the complexity of operations and the possibility of errors, thus affecting the development efficiency of projects.

[0004] In summary, how to provide a convenient and reliable code management platform to improve project development efficiency has become a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0005] The main purpose of this application is to provide a code management platform, method, device and storage medium, aiming to provide a convenient and reliable code management platform to improve project development efficiency.

[0006] To achieve the above objectives, this application proposes a code management platform, which includes: The project management module is used to create a development branch corresponding to the project version in response to the project creation command, wherein the development branch includes the files associated with the project version; The file management module is used to synchronize the code of each file to the mirror development branch associated with the project version during the code testing phase. The code release module is used to select target code from the mirror development branch and synchronize it to a preset production branch based on the tags of each code during the code release phase.

[0007] In one embodiment, the file management module is further configured to: During the code development phase, access control is implemented for each file based on its file status and the Gitee push callback mechanism.

[0008] In one embodiment, the file management module includes: The file status management unit is used to identify the file status of each file and to perform permission control based on the file's transformation. The file status includes initial state, checkout state, and development state. The push callback unit is used to receive code callback information pushed by Gitee and determine whether the submission of each file meets the permission requirements based on the code callback information.

[0009] In one embodiment, the file status management unit is further configured to execute file status transition instructions, which include file checkout instructions, file development allocation instructions, and file development cancellation instructions.

[0010] In one embodiment, the file management module includes: The mirror development branch creation unit is used to generate an associated mirror development branch when the development branch is created; The tag management unit is used to add tags to the code saved on each of the image development branches, wherein the tags include the project version to which the code belongs and the code modification time.

[0011] In one embodiment, the project management module further includes: The Project Version Management Unit is used to manage the various project versions of a project and the development branches corresponding to each project version. The file tree display unit is used to generate a visual file tree, which displays each file by project.

[0012] In one embodiment, the code publishing module further includes: The baseline management unit is used to reset the baseline of the test branch to a baseline state consistent with that of the development branch and the production branch before the code of each file is synchronized to the test branch.

[0013] Furthermore, to achieve the above objectives, this application also proposes a code management method applied to the code management platform described above. The code management method includes: In response to the project creation command, a development branch corresponding to the project version is created, wherein the development branch includes the files associated with the project version; During the code testing phase, the code of each of the aforementioned files will be synchronized to the mirror development branch associated with the project version; During the code release phase, target code is selected from the mirror development branch and synchronized to the preset production branch based on the tags of each code.

[0014] In addition, to achieve the above objectives, this application also proposes an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the code management method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the code management method described above.

[0016] This application proposes a code management platform, which includes: a project management module for creating a development branch corresponding to the project version in response to a project creation command, wherein the development branch includes files associated with the project version; a file management module for synchronizing the code of each file to the mirror development branch associated with the project version during the code testing phase; and a code release module for selecting target code from the mirror development branch and synchronizing it to a preset production branch based on the tags of each code during the code release phase.

[0017] In summary, the code management platform in this application provides a highly integrated code management solution through the synergistic effect of the project management module, file management module, and code release module. The project management module enables fine-grained management of project versions, the file management module ensures the synchronization and stability of code in the test environment, and the code release module improves the efficiency and reliability of code release. The combination of these modules reduces the number of manual steps for developers, lowers the complexity of operations and the possibility of errors, thereby improving the development efficiency of the project. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the module structure provided in Embodiment 1 of the code management platform of this application; Figure 2 This is a schematic diagram of the traditional code merging process provided in Embodiment 1 of the code management platform of this application; Figure 3 This is a schematic diagram of a traditional parallel code development process provided in Embodiment 1 of the code management platform of this application; Figure 4 This is a schematic diagram of the code merging process provided in Embodiment 1 of the code management platform of this application; Figure 5This is a schematic diagram of the parallel code development process provided in Embodiment 1 of the code management platform of this application; Figure 6 This is a schematic diagram of the project management process provided in Embodiment 1 of the code management platform of this application; Figure 7 This is a schematic diagram of the Gitee lifecycle provided in Embodiment 1 of the code management platform of this application; Figure 8 This is a schematic diagram of the file permission control process provided in Embodiment 2 of the code management platform of this application; Figure 9 This is a schematic diagram of the file status transition process provided in Embodiment 2 of the code management platform of this application; Figure 10 This is a flowchart illustrating the code management method of an embodiment of this application; Figure 11 This is a schematic diagram of the device structure of the hardware operating environment involved in the code management method in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] With the increasing popularity of distributed software development and collaboration, code management platforms have become a core infrastructure supporting modern software engineering.

[0024] As the current mainstream code management platform, Git focuses on code version storage and basic branch management functions. However, its integration support for project management, file synchronization, and code release is not perfect. Developers usually need to manually perform code synchronization and release tasks, which increases the complexity of operations and the possibility of errors, thus affecting the development efficiency of projects.

[0025] In summary, how to provide a convenient and reliable code management platform to improve project development efficiency has become a pressing technical problem that needs to be solved in this field.

[0026] This application provides a solution, proposing a code management platform, which includes: a project management module, used to create a development branch corresponding to the project version in response to a project creation instruction, wherein the development branch includes files associated with the project version; a file management module, used to synchronize the code of each file to the mirror development branch associated with the project version during the code testing phase; and a code release module, used to select target code from the mirror development branch and synchronize it to a preset production branch according to the tags of each code during the code release phase.

[0027] In summary, the code management platform in this application embodiment provides a highly integrated code management solution through the synergistic effect of the project management module, file management module, and code release module. The project management module enables fine-grained management of project versions, the file management module ensures the synchronization and stability of test environment code, and the code release module improves the efficiency and reliability of code release. The combination of these modules reduces the number of manual steps for developers, lowers operational complexity and the possibility of errors, thereby improving project development efficiency.

[0028] Based on this, embodiments of this application provide a code management platform, referring to... Figure 1 , Figure 1 This is a schematic diagram of the module structure of the code management platform of this application in the first embodiment.

[0029] In this embodiment, the code management platform includes: The project management module is used to create development branches corresponding to the project version in response to project creation commands. The development branches include the files associated with the project version. In this embodiment, after receiving the project creation instruction, the project management module automatically creates a development branch that strictly corresponds to the specified project version. This development branch is precisely associated with a specific iteration stage in the project lifecycle and fully contains all the code files associated with the project version, ensuring real-time matching between the development environment and the project progress.

[0030] The file management module is used to synchronize the code of each file to the mirror development branch associated with the project version during the code testing phase. In this embodiment, when the code enters the testing phase, the file management module synchronizes the current code status of each file in the development branch to a dedicated mirror development branch. This mirror branch, as a read-only snapshot, completely preserves the test baseline code, forming a one-way traceable link from the development environment to the test environment, and completely eliminating the risk of test code being accidentally modified.

[0031] The code release module is used to select target code from the mirror development branch and synchronize it to the preset production branch based on the tags of each code during the code release phase.

[0032] In this embodiment, the code release module accurately selects the target code version from the mirror development branch based on the preset version tag during the release phase, and synchronizes it to the production branch through an automated merging mechanism. This process strictly avoids interference from real-time changes in the development branch and ensures complete consistency between the production environment code and the test environment snapshot.

[0033] In one feasible embodiment, the file management module includes: The mirror development branch creation unit is used to generate associated mirror development branches when a development branch is created; The tag management unit is used to add tags to the code saved on each mirror development branch. The tags include the project version to which the code belongs and the time the code was modified.

[0034] In this embodiment, the file management module generates a corresponding mirror development branch in real time through the mirror development branch creation unit when the development branch is created. This mirror development branch serves as a read-only copy of the development branch, and its initial state is a complete copy of all file contents of the development branch. Furthermore, any manual code commit operations are prohibited to maintain the purity of the base code.

[0035] When the code on the development branch enters the testing phase, the tag management unit automatically adds structured tags to the synchronized code snapshots in the mirrored development branch. These tags can consist of a project version identifier and a code modification timestamp. The version identifier is associated with the project iteration cycle, while the timestamp records the specific moment the code was frozen. This dual-dimensional tagging system ensures that each test baseline code has a unique and traceable digital fingerprint, providing a precise version anchor for subsequent production releases.

[0036] It is worth mentioning that any merge operation on a mirror branch triggers an automatic tag generation process, ensuring that code snapshots in the test and production environments can be uniquely identified and retrieved throughout the project's entire lifecycle.

[0037] For example, traditional code releases typically involve a full release, and the most robust code merging process is as follows: Figure 2 As shown, the development branch is exemplified by DEV (Development Branch), the testing environment by UAT (User Acceptance Test Branch), and the production packaging branch by PRD (Production Branch). This ensures code consistency between the testing and production environments. This approach is suitable for trunk branch development but not for parallel project development. Figure 3 As shown, there are three projects A, B, and C being developed in parallel, with overlapping testing times and inconsistent production deployment times. Assuming project B is deployed first, when packaging the project, the code from the DEV_B branch can only be merged into the PRD branch. At this point, it cannot be guaranteed that the code currently synchronized from DEV_B to PRD is the code currently being tested in the UAT environment.

[0038] In this regard, such as Figure 4As shown, in this embodiment, when creating the DEV branch, a mirror development branch Mirror_DEV is also created simultaneously. The main function of Mirror_DEV is to save a "snapshot" of the DEV branch synchronized to the UAT branch. Developers cannot submit or upload code to the Mirror_DEV branch. During release, the code from the DEV branch is first merged into Mirror_DEV, and the Mirror_DEV branch is tagged. Then, the code from the Mirror_DEV branch is merged into the UAT branch. Before each release, the baseline of the UAT branch is reset to ensure that the baselines of DEV, UAT, and PRD are consistent. During production merge, the tag on the Mirror_DEV branch at the most recent release is selected, and the content modified from the tag is synchronized to the PRD branch. This avoids the influence of code submissions from the development branch and the mirror branch's release to other environments, ensuring the consistency between test code and production code. During parallel project development, projects being tested in parallel are detected and merged together with the code of the project currently to be released. The parallel process is as follows: Figure 5 As shown, by detecting projects undergoing parallel testing and projects that are currently being released, their code is merged together, ensuring consistency and reliability of code releases in parallel development mode.

[0039] In one feasible embodiment, the project management module further includes: The Project Version Management unit is used to manage the various project versions and the corresponding development branches of each project version; In this embodiment, the project management module dynamically maintains the version sequence of the entire project iteration lifecycle through the project version management unit. Each project version is assigned a unique digital identifier and is precisely matched with the time window of the project iteration cycle. When a new project version is added, the project version management unit can automatically create a dedicated development branch and establish a two-way binding relationship to ensure that the development branch strictly carries all the code assets of the corresponding version.

[0040] In addition, the project version management unit monitors the parallel development status of multiple versions and prevents code pollution between different versions through a branch isolation mechanism.

[0041] The file tree display unit is used to generate a visual file tree, displaying each file by project.

[0042] The file tree display unit aggregates code resources of related applications in real time based on the project dimension, generating a hierarchical visual file tree structure. The root node is the project name, the secondary nodes expand to display each application subsystem, and the last leaf nodes display the specific code files and their current status indicators, such as initial state, checkout state, or development state.

[0043] It is worth mentioning that the file tree supports dynamic refresh and visual point-and-click operation. Developers can intuitively grasp the file distribution and status changes by expanding any node. For example, clicking on a file node in the checkout state can view the checkout personnel and timestamp. Thus, the complex file management is transformed into an interactive graphical topology, completely eliminating the cognitive load of traditional list-style management.

[0044] In one feasible embodiment, the code deployment module further includes: The baseline management unit is used to reset the baseline of the test branch to a baseline state consistent with the development and production branches before the code of each file is synchronized to the test branch.

[0045] The code release module enforces a baseline reset operation before each code synchronization to the test branch via the baseline management unit. This unit first automatically obtains the baseline version number that both the current development and production branches point to, and then forcibly rolls back the code history of the test branch to this baseline node, thoroughly removing any historical remnants or unverified temporary changes that may exist in the test branch. The reset process employs a full coverage mechanism, ensuring that the codebase state, commit history, and file structure of the test branch are consistent with those of the development and production branches, forming a clean test baseline environment. After the reset is complete, the system automatically triggers a hash value comparison verification to ensure that the binary code snapshots of the three branches are completely identical, establishing a zero-bias baseline starting point for subsequent code merging of mirror branches. This mechanism fundamentally prevents the risk of test distortion caused by environmental differences, ensuring that all test results are generated based on a controllable and unified code baseline.

[0046] For example, the project management process of the code management platform summarized in this embodiment is as follows: Figure 6 As shown, the code management platform is processing Project A and Project B. Both Project A and Project B have their own version numbers (e.g., POOROOM00). Each version has a corresponding application environment (e.g., application AAAA), development management, release management, and production management. Development management is responsible for the project's development process management, release management is responsible for the project's release process management, and production management is responsible for the project's production process management.

[0047] In Project A, developer A created two branches containing the files src / main / java / xxx / Application.java and src / main / java / xxx / test.java. These branches were uploaded to Gitee via file management. Project A has two release versions, UAT_20241201_001 and UAT_20241201_002, each with corresponding commit records uploaded to Gitee. Project B has one production version, PRD_20241201_001, which is deployed by associating it with release version UAT_20241201_002.

[0048] The code storage structure on Gitee includes branches DEV_A_POOROOM00, DEV_B_POOROOM00, and PRD. Branches DEV_A_POOROOM00 and DEV_B_POOROOM00 contain the files src / main / java / xxx / Application.java and src / main / java / xxx / ipxx / Application.java, respectively. Branch PRD contains the file src / main / java / xxx / Application.java. This entire process demonstrates the complete workflow from project development to code storage.

[0049] Gitee's lifecycle is as follows Figure 7 As shown, it is divided into three main stages. The first stage is the version creation and branch creation stage, which involves creating new project versions and development branches to facilitate development. The second stage is the version release and branch merging stage, which includes releasing the completed version and merging the branches into the main branch to facilitate integration and unify the codebase. The third stage is the version closure and branch deletion stage, which involves ending the version's lifecycle, closing versions that are no longer needed, and deleting the corresponding branches to keep the codebase clean and orderly.

[0050] Therefore, the code management platform in this embodiment achieves real-time linkage between file status and project progress through end-to-end automated control. During the project creation phase, it automatically generates development branches bound to the project version and constructs a visual file tree, enabling full-chain automation. During the testing phase, it saves baseline code with version and time dual-dimensional tags through the read-only snapshot mechanism of the mirror branch, and forcibly resets the test branch baseline to a unified node of the development and production branches before code synchronization, forming a clean testing environment with unified version. During the code release phase, it accurately extracts the target code snapshot from the mirror development branch based on the tags and automatically synchronizes it to the production branch, ensuring absolute code consistency throughout the entire process from development to testing to production. This fundamentally eliminates the security risks and efficiency losses caused by branch chaos, environmental differences, and manual operation in the traditional model, thereby improving the project development efficiency.

[0051] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. In addition, the file management module is further used for: During the code development phase, access control is implemented for each file based on its file status and the Gitee push callback mechanism.

[0052] In this embodiment, the file management module implements file access control during the code development phase through file status and the push callback mechanism of the Gitee platform. Specifically, when a developer performs a code push operation, the Gitee platform triggers a WebHook (a callback mechanism) callback in real time to send the submitter's identity, file path, and changed content to the management platform. The platform first verifies whether the current status of the file is in development mode. If the status is invalid, the submission is immediately intercepted and an error code is returned. If the status is valid, the platform further verifies whether the submitter's account matches the developer assigned to the file. Only after both verifications are passed can the file be written to the repository.

[0053] The file status transition follows a strict protocol: initial state files can only be checked out by administrators (such as project managers) and converted to the checkout state. Checkout state files must be assigned to specific developer accounts by the administrator before they can enter the development state. Once a development state file is submitted, it automatically returns to the initial state to form a closed loop. That is, any push request for non-development state files or accounts that do not match is forcibly rejected. This mechanism ensures absolute and precise control over the right to modify code through the dual barriers of state locks and identity binding.

[0054] For example, such as Figure 8 As shown, the file management module, during the code development phase, implements file access control based on file status and the Gitee push callback mechanism. The process is as follows: Users push code to Gitee; after receiving the push, Gitee processes the code and returns a `pushResult` to the user. Simultaneously, Gitee triggers a WebHook event, sending information to the code management platform. Upon receiving the WebHook, the platform performs appropriate processing, such as checking code status, executing automated tests, or implementing access control. After completion, the platform sends a `checkResult` back to Gitee.

[0055] The entire process ensures that the code is processed and responded to in a timely manner after being pushed to Gitee, while also implementing file access control to guarantee the security and compliance of the code.

[0056] In one feasible embodiment, the file management module includes: The file status management unit is used to identify the file status of each file and to perform permission control based on the file's transformation. The file status includes initial state, checkout state, and development state. The push callback unit is used to receive code callback information pushed by Gitee and determine whether the submission of each file meets the permission requirements based on the code callback information.

[0057] In this embodiment, the file management module tracks the precise status of each file in real time through the file status management unit and performs access control based on the file status transitions. The push callback unit receives the submitter account, file path, and modified content data stream from the Gitee push event in real time. First, it calls the status management unit interface to verify whether the target file is in development mode. Then, it compares whether the bound account of each file in the list of files to be submitted is completely consistent with the push account. If any condition is not met, an encrypted rejection command is generated and the push process is forcibly terminated through the callback channel. Only after both verifications are passed is the code allowed to be put into the library.

[0058] In one feasible embodiment, the file status management unit is further configured to execute file status transition instructions, which include file checkout instructions, file development allocation instructions, and file development cancellation instructions.

[0059] In this embodiment, the file management module tracks the precise status of each file in real time and executes flow control through the file status management unit. Specifically, when the administrator executes a checkout command on an initial-state file, the file status management unit immediately switches the file's status to the checkout state and locks the file modification rights. At this time, only the administrator can operate on the file. If the administrator further issues a file development allocation command to a specific developer account, the file status management unit upgrades the checkout-state file to the development state and binds the developer's identity information. At this time, the file can only be modified by the bound developer account. When it is necessary to revoke development permissions, the administrator triggers a file development cancellation command to downgrade the development-state file back to the checkout state and unbind the account.

[0060] For example, such as Figure 9 As shown, the file exists in three states: initial state, checkout state, and development state. Specifically: Initial state: Newly added source code files or files that have finished development are in the initial state. Files in the initial state can be checked out.

[0061] Checked-out state: Files are checked out by code administrators. Once checked out, the file is in the checked-out state. Files in the checked-out state have no commit history and can be canceled from the checkout state.

[0062] Development state: The source code administrator assigns the checked-out files to the developers. The files are in the development state. Files in the development state can be reassigned and returned to the check-out state.

[0063] Through this status management mechanism, the code management platform can effectively control file modification permissions, avoid conflicts caused by multiple people modifying the same file at the same time, and also clearly track the development progress of the file.

[0064] Thus, the code management platform in this embodiment automatically generates development branches and constructs a visual file tree based on the project version through the project management module, realizing real-time transparent transmission of file distribution and status changes; the file management module ensures that only authorized developers can modify specified files through a three-level file status transition of initial state, checkout state, and development state, as well as a dual verification mechanism of Gitee WebHook callback, thereby blocking unauthorized operations from the source; during the testing phase, a mirror branch is automatically created to save code snapshots with version and time dual tags, and the baseline management unit forces the test branch to be reset to the unified node of the development branch and the production branch, forming a clean testing environment with unified version; the code release module accurately extracts the target snapshot in the mirror branch based on tags and automatically synchronizes it to the production branch, ensuring absolute code consistency throughout the entire chain from development to production, fundamentally eliminating the security risks and efficiency losses caused by branch chaos, environmental differences, and manual operation in the traditional model, thereby improving the development efficiency of the project.

[0065] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the code management platform of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0066] This application also provides a code management method, which is applied to the code management platform described in the above embodiments. Please refer to... Figure 10 The code management method includes steps S10 to S30: Step S10: In response to the project creation command, create a development branch corresponding to the project version, wherein the development branch includes all files associated with the project version; Step S20: During the code testing phase, synchronize the code of each file to the mirror development branch associated with the project version; Step S30: During the code release phase, select target code from the mirror development branch and synchronize it to the preset production branch according to the tags of each code.

[0067] In this embodiment, the code management platform includes a project management module, a file management module, and a code release module. Upon receiving a project creation instruction, the project management module automatically creates a development branch that strictly corresponds to the specified project version. This development branch precisely associates with a specific iteration stage in the project lifecycle and completely includes all code files associated with that project version, ensuring real-time matching between the development environment and project progress. When the code enters the testing phase, the file management module synchronizes the current code status of each file in the development branch to a dedicated mirror development branch. This mirror branch, as a read-only snapshot, completely preserves the test baseline code, forming a unidirectional traceable link from the development environment to the testing environment, completely eliminating the risk of accidental modification of test code. During the release phase, the code release module accurately selects the target code version from the mirror development branch based on preset version tags and synchronizes it to the production branch through an automated merging mechanism. This process strictly avoids interference from real-time changes to the development branch, ensuring complete consistency between the production environment code and the test environment snapshot.

[0068] The code management method provided in this application, employing the code management platform described in the above embodiments, can improve project development efficiency. Compared with the prior art, the beneficial effects of the code management method provided in this application are the same as those of the code management platform provided in the above embodiments, and other technical features in the code management method are the same as those disclosed in the code management platform of the above embodiments, and will not be repeated here.

[0069] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the code management method described above.

[0070] The following is for reference. Figure 11 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 11 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0071] like Figure 11As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0072] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0073] The electronic device provided in this application, employing the code management method described in the above embodiments, can provide a convenient and reliable code management platform to improve project development efficiency. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the code management method described in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the code management method of the previous embodiment, and will not be repeated here.

[0074] It should be understood that the various parts disclosed in the embodiments of this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0075] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0076] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the code management method described above.

[0077] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0078] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0079] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an electronic device, cause the electronic device to: respond to a project creation instruction to create a development branch corresponding to a project version, wherein the development branch includes files associated with the project version; during the code testing phase, synchronize the code of each file to a mirror development branch associated with the project version; and during the code release phase, select target code from the mirror development branch based on the tags of each code and synchronize it to a preset production branch.

[0080] Computer program code for performing the operations of the embodiments of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0083] The readable storage medium provided in this application embodiment is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described code management method. This provides a convenient and reliable code management platform to improve project development efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application embodiment are the same as those of the code management method provided in the above embodiments, and will not be repeated here.

[0084] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A code management platform, characterized in that, The code management platform includes: The project management module is used to create a development branch corresponding to the project version in response to the project creation command, wherein the development branch includes the files associated with the project version; The file management module is used to synchronize the code of each file to the mirror development branch associated with the project version during the code testing phase. The code release module is used to select target code from the mirror development branch and synchronize it to a preset production branch based on the tags of each code during the code release phase.

2. The code management platform as described in claim 1, characterized in that, The file management module is also used for: During the code development phase, access control is implemented for each file based on its file status and the Gitee push callback mechanism.

3. The code management platform as described in claim 2, characterized in that, The file management module includes: The file status management unit is used to identify the file status of each file and to perform permission control based on the file's transformation. The file status includes initial state, checkout state, and development state. The push callback unit is used to receive code callback information pushed by Gitee and determine whether the submission of each file meets the permission requirements based on the code callback information.

4. The code management platform as described in claim 3, characterized in that, The file status management unit is also used to execute file status transition instructions, which include file checkout instructions, file development allocation instructions, and file development cancellation instructions.

5. The code management platform as described in claim 1, characterized in that, The file management module includes: The mirror development branch creation unit is used to generate an associated mirror development branch when the development branch is created; The tag management unit is used to add tags to the code saved on each of the image development branches, wherein the tags include the project version to which the code belongs and the code modification time.

6. The code management platform as described in claim 1, characterized in that, The project management module also includes: The Project Version Management Unit is used to manage the various project versions of a project and the development branches corresponding to each project version. The file tree display unit is used to generate a visual file tree, which displays each file by project.

7. The code management platform as described in claim 1, characterized in that, The code publishing module also includes: The baseline management unit is used to reset the baseline of the test branch to a baseline state consistent with that of the development branch and the production branch before the code of each file is synchronized to the test branch.

8. A code management method, characterized in that, The code management method is applied to the code management platform as described in any one of claims 1 to 7, and the code management method includes: In response to the project creation command, a development branch corresponding to the project version is created, wherein the development branch includes the files associated with the project version; During the code testing phase, the code of each of the aforementioned files will be synchronized to the mirror development branch associated with the project version; During the code release phase, target code is selected from the mirror development branch and synchronized to the preset production branch based on the tags of each code.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the code management method as described in claim 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the code management method as described in claim 8.

Images