File processing method and device, electronic equipment and computer readable storage medium

Abstract

Embodiments of the present application provide a file processing method and device, electronic equipment and computer readable storage medium, and relate to the technical field of computer. In the embodiments of the present application, the target file includes the modified file corresponding to the same version management library in at least two development projects. Thus, the target file is processed based on the target parent library, for example, when the file is submitted, the target file is submitted to the target parent library, and when the target file is pulled, the target file is directly pulled from the target parent library, so that the target file no longer needs to be submitted to the version management library in each project, thereby effectively improving the processing efficiency of the file.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a file processing method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] As a core asset of a company, code is related to the company's healthy and sustainable development. Good code management can drive the company's healthy and stable development, while poor code management can hinder the company's development and even lead to bankruptcy.

[0003] Version control repositories can manage different versions of code. A development project usually corresponds to multiple version control repositories. For example, an Android development project may correspond to hundreds of version control repositories.

[0004] When developers need to handle multiple development projects, and these projects contain multiple versions of the same repository, developers need to submit the same code modification files to the same version of the repository in each of the multiple projects, resulting in low file processing efficiency. Summary of the Invention

[0005] Based on the above research, embodiments of the present invention provide a file processing method, apparatus, electronic device, and computer-readable storage medium to improve file processing efficiency.

[0006] The embodiments of the present invention can be achieved through the following four aspects:

[0007] In a first aspect, embodiments of the present invention provide a file processing method, the method comprising:

[0008] Obtain the target command;

[0009] Determine the target file corresponding to the target command;

[0010] The target file is processed based on the target parent library and the target command. The target parent library is associated with multiple development projects, and each development project corresponds to at least one version control library. The target parent library stores the modified files corresponding to the version control libraries of each development project. The target file includes the modified files corresponding to the same version control libraries in at least two development projects.

[0011] In a second aspect, embodiments of the present invention provide a document processing apparatus, the apparatus comprising:

[0012] The acquisition module is used to acquire the target command;

[0013] The determination module is used to determine the target file corresponding to the target command;

[0014] The processing module is used to process target files based on the target parent library and target commands. The target parent library is associated with multiple development projects, and each development project corresponds to at least one version control library. The target parent library stores the modified files corresponding to the version control libraries of each development project. The target file includes the modified files corresponding to the same version control libraries in at least two development projects.

[0015] Thirdly, embodiments of the present invention provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the file processing method of any of the foregoing embodiments.

[0016] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the file processing method of any of the foregoing embodiments.

[0017] The file processing method, apparatus, electronic device, and computer-readable storage medium provided in this invention allow for the processing of target files. The target file includes modified files from the same version control repository in at least two development projects and / or modified files of the same file in different version control repositories in at least two development projects. This allows for processing of the target file based on the target parent repository. For example, when submitting a file, the target file is submitted to the target parent repository; when retrieving a target file, it is retrieved directly from the target parent repository. This eliminates the need to submit the target file separately to the version control repositories of each project, thereby effectively improving file processing efficiency. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a structural block diagram of an electronic device provided in an embodiment of the present invention.

[0020] Figure 2 This is a schematic flowchart of a file processing method provided in an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram illustrating the association of multiple projects with a target parent library, as provided in an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram of a structure between multiple parent libraries created according to an embodiment of the present invention.

[0023] Figure 5 This is a block diagram of a file processing apparatus provided in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0025] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0026] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0027] As mentioned in the background section, version control repositories manage different versions of code. A development project typically corresponds to multiple version control repositories; for example, an Android development project might have hundreds of version control repositories. When developers need to handle multiple development projects, and these projects all contain multiple versions of the same version control repositories, developers need to submit the same code modifications to the same version control repositories in each of the multiple projects, resulting in inefficient file processing.

[0028] Based on this, embodiments of the present invention provide a file processing method, apparatus, electronic device, and computer-readable storage medium. The target file includes modified files of the same version control library in at least two development projects and / or modified files of the same file in different version control libraries in at least two development projects. In this way, the target file is processed based on the target parent library. For example, when submitting a file, the target file is submitted to the target parent library, and when retrieving a target file, it is directly retrieved from the target parent library. Therefore, it is no longer necessary to submit the target file to the version control library of each project separately, thereby effectively improving the file processing efficiency.

[0029] Please see Figure 1 , Figure 1This is a structural block diagram of an electronic device 100 provided in this embodiment. The electronic device may include a file processing device 10, a memory 20, a processor 30, a communication unit 40, and a display unit 50. The memory 20 stores machine-readable instructions that can be executed by the processor 30. When the electronic device 100 is running, the processor 30 and the memory 20 communicate via a bus. The processor 30 executes the machine-readable instructions and performs a file processing method.

[0030] The memory 20, processor 30, and communication unit 40 are electrically connected to each other directly or indirectly to achieve signal transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The file processing device 10 includes at least one software function module that can be stored in the memory 20 in the form of software or firmware. The processor 30 is used to execute the executable module (e.g., the software function module or computer program included in the file processing device 10) stored in the memory 20.

[0031] The memory 20 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0032] In some embodiments, processor 30 is used to perform one or more functions described in this embodiment. In some embodiments, processor 30 may include one or more processing cores (e.g., a single-core processor (S) or a multi-core processor (S)). By way of example only, processor 30 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), an application-specific instruction-set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a microcontroller unit, a reduced instruction set computing (RISC) computer, or a microprocessor, or any combination thereof.

[0033] For ease of explanation, only one processor is described in electronic device 100. However, it should be noted that electronic device 100 in this embodiment may also include multiple processors, and therefore the steps performed by one processor as described in this embodiment may also be performed jointly or individually by multiple processors. For example, if the server's processor performs steps A and B, it should be understood that steps A and B may also be performed jointly by two different processors or individually by one processor. For example, one processor performs step A, and a second processor performs step B, or the first and second processors jointly perform steps A and B.

[0034] In this embodiment, the memory 20 is used to store the program, and the processor 30 is used to execute the program after receiving the execution instruction. The process definition method disclosed in any implementation of this embodiment can be applied to the processor 30, or implemented by the processor 30.

[0035] The communication unit 40 is used to establish a communication connection between the electronic device 100 and other devices via a network, and to send and receive data via the network.

[0036] In some implementations, the network can be any type of wired or wireless network, or a combination thereof. By way of example only, the network may include wired networks, wireless networks, fiber optic networks, telecommunications networks, intranets, the Internet, local area networks (LANs), wide area networks (WANs), wireless local area networks (WLANs), metropolitan area networks (MANs), public switched telephone networks (PSTNs), Bluetooth networks, ZigBee networks, or near field communication (NFC) networks, or any combination thereof.

[0037] In this embodiment, the display unit 50 provides an interactive interface (e.g., a user interface) between the electronic device 100 and the user for displaying image information. In this embodiment, the display unit 50 can be a liquid crystal display (LCD) or a touch display. If it is a touch display, it can be a capacitive touchscreen or a resistive touchscreen that supports single-point and multi-point touch operations. Supporting single-point and multi-point touch operations means that the touch display can sense touch operations generated from one or more locations on the touch display and pass the sensed touch operations to the processor 30 for calculation and processing.

[0038] To facilitate interaction between the developer and the display unit 50, in this embodiment, the electronic device 100 may further include an input / output unit. The input / output unit provides data input to the developer, enabling interaction between the developer and the electronic device 100. The input / output unit may be, but is not limited to, a mouse and keyboard.

[0039] In some embodiments, the electronic device 100 may include one or N display units 50, where N is a positive integer greater than 1.

[0040] In this embodiment, the electronic device 100 may be, but is not limited to, mobile phones, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), and other electronic devices. This embodiment does not impose any restrictions on the specific type of electronic device.

[0041] Understandably, Figure 1The structure shown is for illustrative purposes only. The electronic device 100 may also have... Figure 1 Showing more or fewer components, or having with Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0042] based on Figure 1 The implementation architecture of this embodiment provides a file processing method, which is based on... Figure 1 The electronic device shown performs the following based on Figure 1 The structural diagram of the electronic device 100 shown illustrates in detail the steps of the file processing method provided in this embodiment. Please refer to the attached diagram. Figure 2 The file processing method provided in this embodiment includes steps S101 to S103.

[0043] Step S101: Obtain the target command.

[0044] Target commands are commands entered by developers through a local electronic device for processing files. The local electronic device can be, but is not limited to, a local desktop computer or a local laptop, and the file can be, but is not limited to, a code file; for example, it can also be a text file.

[0045] Step S102: Determine the target file corresponding to the target command.

[0046] The target file is the file that the target command points to. For example, if the target command is a command to commit a file, then the target file is the file to be committed; if the target command is a command to view a file, then the target file is the file to be viewed; and if the target command is a command to delete a file, then the target file is the file to be deleted.

[0047] Step S103: Process the target file based on the target parent library and the target command; the target parent library is associated with multiple development projects, and each development project corresponds to at least one version control library. The target parent library stores the modified files corresponding to the version control libraries of each development project; the target file includes the modified files corresponding to the same version control libraries in at least two development projects.

[0048] The target parent repository is a version control repository (Git repository) used to manage multiple development projects. The target parent repository is associated with multiple development projects, thus enabling the management of these projects. Figure 3 As shown, the target parent repository manages three development projects: development project 1 to development project 3, and each development project has at least one version control repository.

[0049] The version control repository can be seen as a distributed version management tool. The version control repository stores multiple files. If each modification of a file is considered as a version, and a file has undergone M modifications, then including the original version, the file will have M+1 versions. Furthermore, as long as all M+1 versions of the file are committed to the version control repository, the version control repository will record the M+1 versions of the file. Thus, all M+1 versions of the file can be traced back.

[0050] The target parent repository stores modified files corresponding to existing files in the version control repository, or newly created files within the version control repository of the development project. For example, if version control repository A contains 50 files, all 50 files can be committed to the target parent repository. The target parent repository will then store all 50 files from version control repository A. If each of these 50 files is modified, the target parent repository will also store the corresponding modified files. Furthermore, if a 51st file is added to version control repository A, this 51st file can be committed to the target parent repository after its creation.

[0051] Each development project may include at least one version control repository. For example, development project 1 includes version control repositories A, B, and C; development project 2 includes version control repositories A, C, and D; and development project 3 includes version control repositories K and U. Multiple development projects can be derived from the same original project. For example, if the original project includes version control repositories A and B, then development projects 1 through 3 are continuously updated based on the original project to form the final development projects 1 through 3. Alternatively, multiple development projects can be derived from different original projects. For example, development project 1 is derived from original project 1, which includes version control repository A; development project 2 is derived from original project 2, which includes version control repository C; and development project 3 is derived from original project 3, which includes version control repository U.

[0052] Assuming the target parent repository is associated with development projects 1 through 3, where development project 1 contains version control repositories A, B, and C; development project 2 contains version control repositories A, C, and D; and development project 3 contains version control repositories K and U, then the modified files corresponding to the version control repositories of each development project stored in the target parent repository fall into two categories: Scenario 1: The target parent repository stores modified files corresponding to the same version control repositories in at least two development projects. For example, the target parent repository stores modified files corresponding to version control repositories A and C. Scenario 2: The target parent repository stores modified files corresponding to a unique version control repositories. A unique version control repositories means that a particular version control repository exists uniquely within a specific development project. For example, version control repositories B, C, K, and U are unique version control repositories, meaning the target parent repository can also be used to store modified files from versions control repositories B, C, K, and U.

[0053] Continuing the example, suppose a developer manages three development projects: Project 1 through Project 3. If a developer wants to modify a file J in version control repository A, after modifying file J, the developer needs to commit the modified file J to version control repository A in both Project 1 and Project 2. This is inefficient, as the same file J is committed twice. With a target parent repository, the modified file J only needs to be committed once, improving file processing efficiency. Furthermore, without a target parent repository, viewing the file modification history in version control repository A is inefficient because it stores all files. However, with a target parent repository, the number of files stored is relatively small, resulting in improved query efficiency.

[0054] The file processing method provided in this embodiment includes modified files corresponding to the same version management libraries in at least two development projects. In this way, the target file is processed based on the target parent library. For example, when submitting a file, the target file is submitted to the target parent library. When retrieving a target file, it is directly retrieved from the target parent library. Therefore, it is no longer necessary to submit the target file to the version management libraries of each project separately, thereby effectively improving the file processing efficiency.

[0055] In this embodiment, the target parent library needs to be created before it can be applied.

[0056] Specifically, before obtaining the target command, the process also includes:

[0057] Determine the target path to use for creating the target parent library.

[0058] The target parent library is generated using the version control library initialization method under the target path.

[0059] Associate the target parent library with the comprehensive branches corresponding to multiple development projects.

[0060] The target path refers to the path on the developer's local electronic device. For example, if the target parent library's target path is E:\root, then the target parent library will be created under E:\root.

[0061] The initialization method for a version control repository is `git init`, which creates the repository. In this example, the target parent repository is generated by using the initialization method under the target path `E:\root`. After executing `git init`, a folder named `.git` will be generated under `E:\root`, thus completing the creation of the target parent repository. The `.git` folder contains several files, such as the `HEAD` file, which contains a reference pointing to the currently used branch; the `config` file, which stores the version control repository's attribute configuration information; and the `objects` folder, which stores commits, trees, and blobs generated after commits. Commits include information such as the file's commit author, comments, and commit time, while blobs contain the file content.

[0062] During project development, developers can create numerous branches. For example, to test the project code, they can create a test branch; to further develop the code, they can create a development branch. After creating the branches, developers can switch to the corresponding branch to work and complete the development for that branch. Developers can not only create branches for the development project but also delete unnecessary branches. Once all necessary branches have been developed, the development work for the project is complete. In this embodiment, to manage multiple development projects, the target parent library needs to create multiple comprehensive branches corresponding to each development project. Then, the target parent library is switched to these comprehensive branches. Afterward, files from multiple development projects can be processed based on the target parent library, for example, committing modified files from the development projects to the target parent library. Assuming multiple custom development projects (Project 1 to Project 3) have a combined branch of FZ-1-2-3, we first create the combined branch for Project 1 to Project 3 using the `git branch FZ-1-2-3` command. Then, we use the `git checkout FZ-1-2-3` command to switch the target parent repository to FZ-1-2-3, thus associating the target parent repository with the combined branch for multiple development projects. Before the branch switch, assuming the HEAD file in the target parent repository's `.git` directory records the branch as `master`, after the switch, the branch recorded in the HEAD file of the target parent repository's `.git` directory will become FZ-1-2-3.

[0063] In this embodiment, as the amount of modified code in the development project increases, more parent libraries can be created to manage the development project. The following provides a management structure that, after associating the target parent library with the comprehensive branches corresponding to multiple development projects, further includes:

[0064] Determine the management path used to create the parent repository.

[0065] The parent repository is generated under the management path using the initialization method of the version management repository.

[0066] Associate the management parent library with at least two target parent libraries, where the development projects associated with the at least two target parent libraries contain the same development projects.

[0067] The management parent repository and the target parent repository are essentially the same—both are version control repositories. Therefore, the method for generating the management parent repository is the same as that for generating the target parent repository, and will not be detailed here. Similarly, to associate the management parent repository with at least two target parent repositories, you can first create a synthesis branch corresponding to the two target parent repositories, and then switch the management parent repository to the synthesis branch corresponding to the two target parent repositories. The structure between the created multiple parent repositories (management parent repository and two target parent repositories) can be as follows: Figure 4 As shown, by managing the parent repository, management of development projects 1 to 4 can be achieved. That is, the modified files corresponding to the version management repositories under development projects 1 to 4 can be submitted to the parent repository. It should be noted that the parent repository can focus on the management of development project 3. For example, the modified files corresponding to development project 3 can be submitted to the parent repository.

[0068] In this embodiment, to facilitate developers downloading development projects, corresponding scripts can also be added to the target parent library. Specifically, the file processing method further includes:

[0069] Add a script to the target parent library to download a specified development project, which can be any of the multiple development projects.

[0070] For example, if the target parent repository is associated with development projects 1, 2, and 3, then scripts for downloading development project 1, 2, and 3 can be created first. Then, these scripts can be added to the target parent repository. Since the target parent repository already contains these scripts, running them allows for convenient and quick downloading of all files for each development project from the remote server to the developer's local electronic device. Understandably, without these scripts in the target parent repository, downloading each project might require multiple commands, resulting in inefficient downloading.

[0071] In this embodiment, developers can add target files to areas of the target parent library according to different commands. Specifically, the target commands include add commands; the steps of processing the target file based on the target parent library and the target commands may include:

[0072] The target area is determined based on the add command.

[0073] In response to the add command, the target file is added to the target region of the target parent library.

[0074] The target parent repository consists of three areas: the working area, the staging area, and the repository area. In the working area of ​​the target parent repository (for example, if the target path of the target parent repository is E:\root, meaning the .git folder is under E:\root, then the working area of ​​the target parent repository can be E:\root, where all files are stored, and files can be added, modified, or deleted), after modifying or adding files, you need to commit the modified or added files. This can be done by committing the modified or added files to the staging area or further to the repository area. The staging area is used to temporarily store files to be committed to the repository area. After all files in the staging area are committed to the repository area, the staging area is empty. The repository area is used for the final storage of modified or added files on your local electronic device.

[0075] Sometimes, developers may forget which files they have modified, and therefore, they are unsure which files to commit to the repository. Developers can use the `git status` command to check which files have been modified but not yet committed to the staging area.

[0076] The `git add` command is used to commit files to the staging area or repository area of ​​the target parent repository. For example, if the `git add` command is a staging add command, the target area is the staging area; if it's a repository add command, the target area is the repository area. It's important to note that the staging add command must be executed before the repository add command. That is, committing modified files or adding new files requires first committing to the staging area, and then from there to the repository area. The staging add command includes full add commands and partial add commands. A full add command adds all modified files in the target parent repository to the staging area. A partial add command adds only the modified files corresponding to the partial add command to the staging area. For example, a full add command like `git add .` will result in all modified files in the working directory as the target file. A partial add command like `git add YYY` will result in the target file being YYY, where YYY is the filename, for example, YYY might be "test.txt". If developers find that further modifications are needed to the files in the staging area, they can revert the files from the staging area to the working directory. For example, they can use the `git reset HEAD` command to revert the files from the staging area to the working directory. It's important to note that each commit in the version control repository corresponds to a commitid, which can be considered a version identifier. Changing the commitid will change the files in the working directory; specifically, the files in the working directory will be updated to match the commitid.

[0077] Optionally, after adding the modified or newly added files to the repository area using the repository add command, you can also use the remote commit command gitpush to commit the modified or newly added files to the remote server.

[0078] Optionally, the modified or added file is a code file. After adding the modified or added file to the repository area using the repository add command, you can also submit the modified or added file to the Gerrit code review tool and add reviewers in the Gerrit code review tool. Reviewers will review the modified or added file, and after the review is approved, the modified or added file will be submitted to the remote server.

[0079] In this embodiment, developers can not only commit modified or newly added files to the repository area, but also pull the latest commit files of the development project from the remote server and merge them with the local files, thereby synchronizing the local development project to the latest version. Specifically, the file processing method also includes:

[0080] In response to a remote project pull command, determine the target development project corresponding to the remote project pull command, and pull the remote files of the target development project from the remote server to the path where the target parent library is located;

[0081] In response to a project merge command, merge the local files of the target development project with the remote files of the target development project pulled from a remote server.

[0082] The `git fetch` command retrieves the latest commit files of a development project from a remote server. The remote files are the latest commit files of the development project stored on the remote server. As you can understand, many developers may be working on Development Project 1 simultaneously, so the latest commit files on the remote server will be constantly updated. Therefore, the `git fetch` command can retrieve the remote files of the development project from the remote server. The `git merge` command merges local files with remote files, specifically combining the latest commit files from the local development project with the latest commit files from the remote server. The local files are the latest commit files of the development project stored on your local electronic device. These latest commit files include the most recent commit ID and HEAD of the development project (branch), with HEAD pointing to the most recent commit ID.

[0083] For example, if the target parent repository is associated with development project 1, development project 2, and development project 3, and on the remote server, the branch corresponding to development project 1 is Proj1, the branch corresponding to development project 2 is Proj2, and the branch corresponding to development project 3 is Proj3, and the remote server name is YCFWQ, then if the remote project pull command is `git fetch YCFWQ Proj1`, the target development project corresponding to the remote project pull command is development project 1, and the latest commit file of development project 1 will be pulled. If the remote project pull command is `git fetch YCFWQ Proj2`, the target development project corresponding to the remote project pull command is development project 2, and the latest commit file of development project 2 will be pulled. If the remote project pull command is `git fetch YCFWQ Proj3`, the target development project corresponding to the remote project pull command is development project 3, and the latest commit file of development project 3 will be pulled.

[0084] Assuming the target path of the parent repository is E:\root, and the development project is Development Project 1, before fetching the latest commit files of Development Project 1 from the remote server, you can first create a subpath for Development Project 1 under the local E:\root path. For example, the subpath for Development Project 1 can be created as E:\root:\Proj1. After creation, you can develop Development Project 1 on your local electronic device. Furthermore, you can use the remote project fetch command gitfetchYCFWQ Proj1 to fetch the latest commit files of Development Project 1 from the remote server to E:\root:\Proj1. Even further, you can use the project merge command gitmerge Proj1 to merge the local files of Development Project 1 with the remote files of Development Project 1 fetched from the remote server, thereby synchronizing the development project to the latest version.

[0085] Taking development project 1 as an example, this section further explains the effect of combining the `git fetch` and `git merge` commands. First, it's important to note that the local electronic device stores both the local commit ID and the commit ID from the remote server for development project 1. Assume the local commit ID for development project 1 on the local electronic device is `commitidA`, and the commit ID on the remote server for development project 1 is also `commitidA`. Now, a modification is made to development project 1 on the remote server and committed. The commit ID on the remote server then changes to `commitidB`. Therefore, before using `git fetch YCFWQ Proj1`, the local commit ID for development project 1 on the local electronic device is `commitidA`, and the commit ID on the remote server for development project 1 is also `commitidA`. After using `git fetch YCFWQ`... After Proj1, the local commitid of development project 1 on the local electronic device remains commitidA, while the commitid of the remote server of development project 1 on the local electronic device changes to commitidB. This shows that the version identifier of the remote server of development project 1 on the local electronic device has been updated. Furthermore, executing the gitmerge command again changes the local commitid of development project 1 on the local electronic device to commitidB, and the current commitid of the remote server of development project 1 on the local electronic device is also commitidB. Thus, development project 1 on the local device is synchronized to the latest version.

[0086] In this embodiment, developers can not only pull development projects from a remote server and merge them locally, but also pull the latest commit files from the target parent repository on the remote server to their local machine and merge them with the latest commit files from the local target parent repository, thereby synchronizing the local target parent repository to the latest version. Specifically, the file processing method further includes:

[0087] In response to a remote parent database pull command, the remotely modified files in the target parent database on the remote server are pulled to the local target parent database.

[0088] In response to the parent repository merge command, it merges local modified files and remote modified files in the target parent repository.

[0089] The `git fetch` command retrieves the latest commit files from the target parent repository on a remote server. The `git fetch` command retrieves the latest commit files from the target parent repository stored on the remote server. Similarly, the `git fetch YCFWQroot` command retrieves the remote files from the target parent repository on the remote server. The `git merge` command merges local files from the target parent repository with remote files, specifically merging the latest commit files from the target parent repository locally and from the remote server. Local files are the latest commit files from the target parent repository stored on the local electronic device. These latest commit files include the target parent repository's most recent commit ID and HEAD, with HEAD pointing to the most recent commit ID. The execution in this embodiment is the same as the previous embodiment and will not be detailed further.

[0090] Based on the same inventive concept, please refer to the following: Figure 5 This invention also provides a document processing device 10, applied to... Figure 1 The electronic device shown, in this embodiment of the invention, allows each functional module of the file processing device 10 to be stored in the electronic device's memory in the form of software or firmware, such as... Figure 5 As shown, the file processing device 10 includes an acquisition module 11, a determination module 12, and a processing module 13.

[0091] Module 11 is used to acquire the target command;

[0092] Module 12 is used to determine the target file corresponding to the target command;

[0093] Processing module 13 is used to process target files based on target parent library and target commands; the target parent library is associated with multiple development projects, each development project corresponds to at least one version control library, and the target parent library stores the modified files corresponding to the version control libraries of each development project; the target file includes the modified files corresponding to the same version control libraries in at least two development projects.

[0094] In an optional implementation, the target command includes an add command; the processing module 13 is specifically used for:

[0095] The target area is determined based on the add command.

[0096] In response to the add command, the target file is added to the target region of the target parent library.

[0097] In an optional embodiment, the file processing apparatus 10 further includes: a first response module, configured to:

[0098] In response to a remote project pull command, determine the target development project corresponding to the remote project pull command, and pull the remote files of the target development project from the remote server to the path where the target parent library is located;

[0099] In response to a project merge command, merge the local files of the target development project with the remote files of the target development project pulled from a remote server.

[0100] In an optional embodiment, the file processing device 10 further includes: a second response module, configured to:

[0101] In response to a remote parent database pull command, it pulls remotely modified files from the target parent database on the remote server to the local target parent database.

[0102] In response to the parent repository merge command, it merges local modified files and remote modified files in the target parent repository.

[0103] In an optional embodiment, the file processing apparatus 10 further includes: a creation module, configured to:

[0104] Determine the target path to use for creating the target parent library.

[0105] The target parent library is generated using the version control library initialization method under the target path.

[0106] Associate the target parent library with the comprehensive branches corresponding to multiple development projects.

[0107] In an optional embodiment, the file processing device 10 further includes: a management creation module, used for:

[0108] Determine the management path used to create the parent repository;

[0109] Generate the parent management repository under the management path using the version management repository initialization method;

[0110] Associate the management parent library with at least two target parent libraries, where the development projects associated with the at least two target parent libraries contain the same development projects.

[0111] In an optional embodiment, the file processing device 10 further includes: a script creation module, used for:

[0112] Add a script to the target parent library to download a specified development project, which can be any of the multiple development projects.

[0113] The file processing apparatus 10 provided in this embodiment of the invention includes target files that are modified files corresponding to the same version management libraries in at least two development projects. In this way, the target files are processed based on the target parent library. For example, when submitting a file, the target file is submitted to the target parent library, and when retrieving a target file, it is directly retrieved from the target parent library. Therefore, it is no longer necessary to submit the target files to the version management libraries of each project separately, thereby effectively improving the file processing efficiency.

[0114] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the document processing device 10 described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0115] Based on the above, this embodiment provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the file processing method of any of the foregoing embodiments.

[0116] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the electronic device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0117] Based on the above, this embodiment provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the file processing method of any of the foregoing embodiments.

[0118] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the computer-readable storage medium described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0119] In summary, the file processing method, apparatus, electronic device, and computer-readable storage medium provided in the embodiments of the present invention include modified files corresponding to the same version management libraries in at least two development projects as target files. In this way, the target files are processed based on the target parent library. For example, when submitting a file, the target file is submitted to the target parent library, and when retrieving a target file, it is directly retrieved from the target parent library. Therefore, it is no longer necessary to submit the target files to the version management libraries of each project separately, thereby effectively improving the file processing efficiency.

[0120] The above descriptions are merely various embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A file processing method, characterized in that, include: Obtain the target command; Determine the target file corresponding to the target command; The target file is processed based on the target parent library and the target command; The target parent library is associated with multiple development projects, and each development project corresponds to at least one version control library. The target parent library stores the modified files corresponding to the version control libraries of each development project. The target file includes modified files corresponding to the same version control libraries in at least two development projects. Before obtaining the target command, the following is also included: Determine the target path used to create the target parent library; The target parent library is generated under the target path using the initialization method of the version management library; Associate the target parent library with the comprehensive branch corresponding to the multiple development projects.

2. The method according to claim 1, characterized in that, The target command includes an add command; the processing of the target file based on the target parent library and the target command includes: Based on the added command, determine the target area; In response to the add command, the target file is added to the target region of the target parent library.

3. The method according to claim 1, characterized in that, The method further includes: In response to a remote project pull command, the target development project corresponding to the remote project pull command is determined, and the remote files of the target development project are pulled from the remote server to the path where the target parent library is located; In response to the project merge command, the local files of the target development project are merged with the remote files of the target development project pulled from the remote server.

4. The method according to claim 1, characterized in that, The method further includes: In response to a remote parent database pull command, the remotely modified files in the target parent database on the remote server are pulled to the local target parent database. In response to the parent library merge command, the local modified files in the target parent library and the remote modified files are merged.

5. The method according to claim 1, characterized in that, After associating the target parent library with the comprehensive branches corresponding to the multiple development projects, the method further includes: Determine the management path used to create the parent repository; The parent management repository is generated under the management path using the version management repository initialization method; The management parent library is associated with at least two target parent libraries, and the development projects associated with the at least two target parent libraries contain the same development projects.

6. The method according to claim 1, characterized in that, Also includes: Add a script to the target parent library for downloading a specified development project, where the specified development project is any one of the plurality of development projects.

7. A document processing device, characterized in that, include: The acquisition module is used to acquire the target command; The determination module is used to determine the target file corresponding to the target command; The processing module is used to process the target file based on the target parent library and the target command; The target parent library is associated with multiple development projects, and each development project corresponds to at least one version control library. The target parent library stores the modified files corresponding to the version control libraries of each development project. The target file includes modified files corresponding to the same version control libraries in at least two development projects. Create a module for: Determine the target path used to create the target parent library; Generate the target parent library under the target path using the version control library initialization method; Associate the target parent library with the comprehensive branches corresponding to multiple development projects.

8. 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, wherein the processor executes the computer program to implement the file processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the file processing method according to any one of claims 1 to 6.

Images