CN118034777A - FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium - Google Patents
FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium Download PDFInfo
- Publication number
- CN118034777A CN118034777A CN202410433851.9A CN202410433851A CN118034777A CN 118034777 A CN118034777 A CN 118034777A CN 202410433851 A CN202410433851 A CN 202410433851A CN 118034777 A CN118034777 A CN 118034777A
- Authority
- CN
- China
- Prior art keywords
- git
- version
- log
- log file
- version number
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000013507 mapping Methods 0.000 claims description 49
- 230000006870 function Effects 0.000 claims description 36
- 238000012545 processing Methods 0.000 claims description 6
- 230000000007 visual effect Effects 0.000 abstract description 5
- 230000008569 process Effects 0.000 description 6
- 238000011161 development Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000004075 alteration Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Landscapes
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium, relates to the technical field of software development, and is used for solving the problems that log information display is not visual and version information retrieval is difficult. The method is applied to FTTR frames and comprises the following steps: under the condition of no parameters, adopting a- -no-merges- -remotes- -reverse option to display the Git log; adding a plurality of version numbers into the initial git.log file to obtain a target git.log file; and displaying detailed information of the version number specified in the target git.log file by adopting a-v < version > option. Therefore, not only can log information be displayed more intuitively, but also detailed information specifying the version number can be displayed.
Description
Technical Field
The application relates to the technical field of software development, and provides FTTR-based log management and version control method, device, equipment and medium.
Background
With the development of science and technology, the version control system (Version Control System, VCS) is gradually becoming the foundation of modern software development, with distributed version control system Git being one of the most popular version control systems, which provides powerful branching and merging capabilities. However, as project sizes expand, the log management and version backtracking functions of Git become increasingly inefficient and intuitive.
In particular when dealing with large numbers of commits and branches, there are several problems: (1) Because the traditional Git log display mode contains a large number of merged records, a developer is easy to track detailed information of each submission when looking up the submission history, and furthermore, the examination and the tracing of a specific submission are difficult and log information display is not intuitive; (2) In the Git, since searching detailed information of a specific version needs to execute a plurality of commands or view a plurality of files, workload and complexity of a developer in the history examination and error tracking process are increased, and further version information retrieval is difficult; (3) Because of the limited flexibility of conventional Git in terms of version rollback and branch management, if a warehouse needs to be traced back to a particular historical version, multiple commands or manual operations need to be performed, which in turn introduces errors or unnecessary complexity, resulting in limited version control flexibility.
Disclosure of Invention
The application provides a FTTR-based log management and version control method, a FTTR-based log management and version control device and a FTTR-based log management and version control medium, which are used for solving the problems that log information display is not visual and version information retrieval is difficult.
In one aspect, a FTTR-based log management and version control method is provided, and is applied to a FTTR framework, and the method includes:
Under the condition of no parameters, adopting a- -no-merges- -remotes- -reverse option to display the Git log;
Adding a plurality of version numbers into the initial git.log file to obtain a target git.log file;
And displaying detailed information of the version number specified in the target git.log file by adopting a-v < version > option.
Optionally, before adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further includes:
Acquiring a log view in reverse order according to the submitting sequence by adopting a-no-merges-remotes-reverse option; wherein the log view has no merged record;
And storing the log view into a git.log empty file after processing, and obtaining the initial git.log file.
Optionally, before adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further includes:
splitting the content in the output variable into lines line list by using len (output. Strip ("\n")) function, and generating a mapping relation table of sequence numbers and keywords;
Traversing the lines line list by adopting enumerate (lines) functions to generate element indexes and values.
Optionally, the step of adding the plurality of version numbers to the initial git.log file to obtain the target git.log file includes:
Traversing the mapping relation table by adopting a mapping.item () function, and determining whether a keyword matched with the lines list exists in the mapping relation table;
if the fact that keywords matched with the lines row table exist in the mapping relation table is determined, generating a character string version_line containing version information;
Inserting the character string version_line into the next row in the content list by adopting a content.insert (i+1, version_line) function to obtain an updated content list;
Adopting a file.trunk () function to empty the original content of the initial git.log file to obtain a first git.log file;
and writing the updated content list into the first git log file by using a file.writelines (content) function to obtain the target git log file.
Optionally, the step of displaying detailed information of the specified version number in the target git.log file by adopting a-v < version > option includes:
for any version number, adopting a-v < version > option to determine whether the any version number exists in the mapping relation table;
If any version number is determined to exist in the mapping relation table, constructing a git show-no-patch < commit hash > command; wherein, the gate show-no-latch < commit hash > command corresponds to the key word of any version number;
Executing the gate show-no-latch < commit hash > command by using subprocess module to obtain an execution result, and storing the execution result in the output variable;
Searching a Change-Id row according to the content of the output variable, and storing the Change-Id row in a change_id variable;
A Change-Id line showing any version number, a date of submission, and a submitter.
Optionally, after adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further includes:
Determining detailed information of all submitted versions in the Git log by adopting a git.log file name option, and displaying the version number of each submitted version information;
And displaying various information in the target git.log file by adopting an open function.
Optionally, after adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further includes:
For any version number, determining whether the any version number exists in the mapping relation table using a reset < version > option;
If the fact that any version number exists in the mapping relation table is determined, acquiring a keyword of any version number;
Constructing a git reset-hard < commit hash > command, wherein the git reset-hard < commit hash > command corresponds to the keyword of any version number;
And executing the gitreset-hard < commit hash > command by adopting a subprocess module, and resetting the Git warehouse at the position of any version number.
In one aspect, a FTTR-based log management and version control device is provided, and is applied to a FTTR framework, and the device includes:
The log display unit is used for displaying the Git log by adopting a-no-merges-remotes-reverse option under the condition of no parameters;
The file obtaining unit is used for adding a plurality of version numbers into the initial git.log file to obtain a target git.log file;
and the version number display unit is used for displaying detailed information of the specified version number in the target git.log file by adopting a-v < version > option.
Compared with the prior art, the application has the beneficial effects that:
In the embodiment of the application, firstly, the Git log can be displayed by adopting a-no-merges-remotes-reverse option under the condition of no parameters; then, a plurality of version numbers can be added into the initial git.log file to obtain a target git.log file; finally, the-v < version > option may be employed to display detailed information of the specified version number in the target git. Therefore, in the embodiment of the application, because the Git log is displayed by directly adopting the-no-merges-remotes-reverse option under the condition of no parameters, the merging record can be removed, so that a developer can more clearly track the history of each submission, and the log information display is more visual. In addition, since the detailed information of the version number specified in the target git.log file is displayed by adopting the-v < version > option, compared with the 'based on git command, only one version information can be queried in other more complex ways' in the prior art, the application can query the information of each version number by using the version number, thereby displaying the detailed information of a specific version more quickly.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the related art, the drawings that are required to be used in the embodiments or the related technical descriptions will be briefly described, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the provided drawings without inventive effort for those skilled in the art.
Fig. 1 is a schematic view of an application scenario provided in an embodiment of the present application;
FIG. 2 is a schematic flow chart of a FTTR-based log management and version control method according to an embodiment of the present application;
Fig. 3 is a schematic diagram of a FTTR-based log management and version control device according to an embodiment of the present application.
The marks in the figure: 10-FTTR-based log management and version control equipment, 101-processor, 102-memory, 103-I/O interface, 104-database, 30-FTTR-based log management and version control device, 301-log display unit, 302-file obtaining unit, 303-version number display unit, 304-mapping relation table generating unit and 305-version resetting unit.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application. Embodiments of the application and features of the embodiments may be combined with one another arbitrarily without conflict. Also, while a logical order is depicted in the flowchart, in some cases, the steps depicted or described may be performed in a different order than presented herein.
With the development of science and technology, the version control system (Version Control System, VCS) is gradually becoming the foundation of modern software development, with distributed version control system Git being one of the most popular version control systems, which provides powerful branching and merging capabilities. However, as project sizes expand, the log management and version backtracking functions of Git become increasingly inefficient and intuitive.
In particular when dealing with large numbers of commits and branches, there are several problems: (1) Because the traditional Git log display mode contains a large number of merged records, a developer is easy to track detailed information of each submission when looking up the submission history, and furthermore, the examination and the tracing of a specific submission are difficult and log information display is not intuitive; (2) In the Git, since searching detailed information of a specific version needs to execute a plurality of commands or view a plurality of files, workload and complexity of a developer in the history examination and error tracking process are increased, and further version information retrieval is difficult; (3) Because of the limited flexibility of conventional Git in terms of version rollback and branch management, if a warehouse needs to be traced back to a particular historical version, multiple commands or manual operations need to be performed, which in turn introduces errors or unnecessary complexity, resulting in limited version control flexibility.
Based on this, the embodiment of the application provides a FTTR-based log management and version control method, in which firstly, the Git log can be displayed by adopting a-no-merges-remotes-reverse option under the condition of no parameters; then, a plurality of version numbers can be added into the initial git.log file to obtain a target git.log file; finally, the-v < version > option may be employed to display detailed information of the specified version number in the target git. Therefore, in the embodiment of the application, because the Git log is displayed by directly adopting the-no-merges-remotes-reverse option under the condition of no parameters, the merging record can be removed, so that a developer can more clearly track the history of each submission, and the log information display is more visual. In addition, since the detailed information of the version number specified in the target git.log file is displayed by adopting the-v < version > option, compared with the 'based on git command, only one version information can be queried in other more complex ways' in the prior art, the application can query the information of each version number by using the version number, thereby displaying the detailed information of a specific version more quickly.
After the design idea of the embodiment of the present application is introduced, some simple descriptions are made below for application scenarios applicable to the technical solution of the embodiment of the present application, and it should be noted that the application scenarios described below are only used for illustrating the embodiment of the present application and are not limiting. In the specific implementation process, the technical scheme provided by the embodiment of the application can be flexibly applied according to actual needs.
Fig. 1 is a schematic diagram of an application scenario provided in an embodiment of the present application. The application scenario may include FTTR-based log management and version control device 10.
The FTTR-based log management and version control device 10 can perform log management and version control under the FTTR framework, for example, a personal computer (Personal Computer, PC), a server, a portable computer, and the like. FTTR-based log management and version control device 10 may include one or more processors 101, memory 102, I/O interfaces 103, and databases 104. In particular, the processor 101 may be a central processing unit (Central Processing Unit, CPU), or a digital processing unit, or the like. The memory 102 may be a volatile memory (RAM), such as a random-access memory (RAM); the memory 102 may also be a non-volatile memory (non-volatile memory), such as a read-only memory (rom), a flash memory (flash memory), a hard disk (HARD DISK DRIVE, HDD) or a solid state disk (solid-state drive (STATE DRIVE, SSD); or memory 102, is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory 102 may be a combination of the above. The memory 102 may store part of program instructions of the FTTR-based log management and version control method provided by the embodiment of the present application, where the program instructions, when executed by the processor 101, can be used to implement the steps of the FTTR-based log management and version control method provided by the embodiment of the present application, so as to solve the problems that log information presentation is not intuitive and version information retrieval is difficult. The database 104 may be used to store data, such as-no-merges-remotes-reverse option, git log, initial Git log file, target Git log file, -v < version > option, -reset < version > option, and mapping table, which are involved in the scheme provided by the embodiment of the present application.
In the embodiment of the present application, the FTTR-based log management and version control device 10 may obtain the-no-merges-remotes-reverse option through the I/O interface 103 under the condition of no parameters, and then the processor 101 of the FTTR-based log management and version control device 10 may intuitively display the log information and the specified version number information according to the program instruction of the FTTR-based log management and version control method provided by the embodiment of the present application in the memory 102. In addition, data such as- -no-merges- -remotes- -reverse option, git log, initial git.log file, target git.log file, - -v < version > option, - -reset < version > option, and mapping table may also be stored in database 104.
Of course, the method provided by the embodiment of the present application is not limited to the application scenario shown in fig. 1, but may be used in other possible application scenarios, and the embodiment of the present application is not limited. The functions that can be implemented by each device in the application scenario shown in fig. 1 will be described together in the following method embodiments, which are not described in detail herein. The method according to the embodiment of the present application will be described below with reference to the accompanying drawings.
As shown in fig. 3, a flowchart of a FTTR-based log management and version control method according to an embodiment of the present application is shown, the method may be performed by the FTTR-based log management and version control apparatus 10 in fig. 1, and the FTTR-based log management and version control method is applied to the FTTR framework. Specifically, the flow of the method is described below.
Step 301: in the absence of parameters, the Git log is displayed using the- -no-merges- -remotes- -reverse option.
In the embodiment of the application, before log management and version control are performed, environment configuration can be performed, specifically, first, the Git and Python environments can be installed on a computer using a target script; the target script is written in Python, and extends the log management and version control functions of Git. Then, ensure that the Git repository for the item has been initialized and that the target script runs under the root directory of the Git repository.
The entire Git log may then be displayed by default without running the target script with any parameters, similar to executing the Git log command. Specifically, the- -no-merges- -remotes- -reverse option may be employed without parameters to provide a clear, merge-free log view in reverse order of commit order to display the Git log. At the same time, the log view may also be saved to the output temporary variable.
Furthermore, the application can realize a new mode to display the Git log through the customized Python script. This new approach supports reverse log viewing without consolidated records, enabling the developer to track the history of each submission more clearly.
Step 302: and adding a plurality of version numbers into the initial git.log file to obtain a target git.log file.
In the embodiment of the application, before adding a plurality of version numbers into the initial git.log file to obtain the target git.log file, the initial git.log file can be generated. Specifically, firstly, a log view in reverse order according to the submitting sequence can be obtained by adopting a-no-merges-remotes-reverse option; the log view is clear and has no merging record; the log view may then be processed and stored in a git.log blank file to obtain an initial git.log file.
In addition, before adding a plurality of version numbers to the initial git.log file, a target git.log file is obtained, a serial number can also be generated. Specifically, first, a len (output. Strip ("\n")) function may be used to split the content in the output variable into a lines line list, generate a mapping relation table of sequence numbers and keywords, and calculate the total number of lines; then, the lines line list may be traversed using the enumerate (lines) function to generate element indices and values. Where the sequence number may start at 1 and an index and corresponding value is generated for each element.
Further, after the initial git.log file and the mapping relation table are determined, the target git.log file can be obtained specifically. Specifically, firstly, mapping.item () function can be adopted to traverse each row of the mapping relation table and the line row list, and whether keywords matched with the lines row list exist in the mapping relation table or not is determined; then, if the keyword matched with the lines row table exists in the mapping relation table, a character string version_line containing version information can be generated; next, a content. Insert (i+1, version_line) function may be used to insert a character string version_line into the next row in the content list, obtain an updated content list, and perform buffering; then, a file.truncate () function may be employed to empty the original content of the initial git.log file to obtain a first git.log file; finally, a file.writelines (content) function may be used to write the updated content list in the cache into the first git.log file, so as to obtain the target git.log file. That is, in the embodiment of the present application, by such a continuous traversal, all log logs in the initial git.log file can be added with the corresponding version number version, so as to obtain the final target git.log file. Furthermore, after the traversal is complete, the file pointer may also be moved to the beginning of the target git log file using the file.seek (0) function.
Step 303: the detailed information of the specified version number in the target git.log file is displayed using the-v < version > option.
In the embodiment of the application, when the targeted version information is displayed, firstly, for any version number, a-v < version > option can be adopted to check whether the number and the format of command line parameters are correct; then, if the number and format of the command line parameters are correct, analyzing any version number into an integer and storing the integer in a version_number variable; next, it may be determined whether any version number exists in the mapping relation table mapping; then, if any version number is determined to exist in the mapping relation table mapping, a git show-no-patch < commit hash > command can be constructed; wherein, the gate show-no-patch < commit hash > command corresponds to a keyword of any version number; next, a subprocess module may be used to execute a gate show-no-latch < commit hash > command to obtain a corresponding execution result, and store the execution result in an output variable; then, the Change-Id row can be searched according to the content of the output variable, and the Change-Id row is stored in the change_id variable; next, the content of the output variable may be split into lines line lists by lines and all lines in the lines list printed before any version number. Then, the any one version number and change_id may be printed; finally, the Change-Id row, date submitted, and presenter information for any version number may be presented.
Therefore, the application can display the detailed information of appointed submission by inquiring version number version and utilizing the show command of Git, thereby simplifying the processes of history examination and error tracking and reducing the time and workload of searching and analyzing code change.
If the Version number is not present in the mapping table mapping, a print "Version < Version > not found". Any of the version numbers corresponds here to the order of commit in the Git log.
In one possible implementation, after adding a plurality of version numbers to the initial git.log file, the target git.log file is obtained, all version information may also be "displayed". Specifically, firstly, a git.log file name option (python+script file name option) can be adopted to determine detailed information of all submitted versions in a Git log, and a version number of each submitted version information is displayed, so that a specific use version can be conveniently checked; the open function may then be employed to read and display various information in the target git log file.
In one possible implementation, after adding a plurality of version numbers to the initial git.log file, and obtaining the target git.log file, a "version reset" may also be performed, i.e., the current version may be rolled back to the corresponding version number location. Specifically, first, for any version number, a-reset < version > option may be employed to check whether the number and format of command line parameters are correct; then, if the number and format of the command line parameters are correct, analyzing any version number into an integer and storing the integer in a version_number variable; next, it may be determined whether any version number exists in the mapping relation table mapping; then, if it is determined that any version number exists in the mapping relation table mapping, a keyword (commit hash) of any version number may be acquired; next, a gitreset-hard < commit hash > command may be constructed, wherein the gitreset-hard < commit hash > command corresponds to a key of any version number; finally, the subprocess module may be employed to execute the gitreset-hard < commit hash > command, resetting the Git repository to the location of any version number. If the Reset is successful, "Reset to version < version > success" may be printed to indicate that the Reset operation was successfully completed. Of course, if the arbitrary Version number does not exist in the mapping relation mapping, a "Version < Version > not found" may be printed to indicate that the reset operation fails.
Thus, in the embodiment of the application, the version reset function is introduced, so that a developer can easily trace back the warehouse to any specific historical version. Meanwhile, by using the version number as the condition of the version reset function, a user can conveniently inquire about the commit number of a certain version without spending more time and effort, so that a developer can flexibly manage different versions of the code, support rollback to the previous submission or create a new branch for experimental development and test, and improve the controllability and testability of the code.
In one possible implementation, the version numbers submitted in the Git log may also be automatically marked. Specifically, the target script may automatically process the initial git.log file to add a Version stamp (Version: < Version number >) for each commit, thereby assigning an easily understood and referenced Version number to each commit in the Git log. Therefore, in the embodiment of the application, the version mark can be automatically inserted in the Git log to allocate a unique version number for each submission, so that the version management is more visual and easy to track.
In one possible implementation, the "display help information" may also be performed after adding a plurality of version numbers to the initial git.log file to obtain the target git.log file. Specifically, the "-h option" or "-hellp option" may be employed to display the program command help file, i.e., to display help information.
In the embodiment of the application, the target script mainly depends on the command line tool of the Git, so that the performance of the target script is closely related to the performance of the Git. Thus, for large warehouses, the Git log generation and version reset operations may take a long time.
Further, since the target script is based on Python and Git command line tools, it can run on any operating system (e.g., windows, linux and macOS) that supports these tools to improve software compatibility.
Moreover, since the git.log file is generated and modified in the execution process, the generated/modified git.log file is deleted when the execution is finished. Therefore, the direct modification to the original Git log can be greatly reduced, and the purpose of protecting the data integrity is achieved.
In summary, in the embodiment of the application, the use efficiency and convenience of Git in large projects can be improved by optimizing log information display, providing detailed information display for specific versions and improving version control flexibility, so that developers can browse, manage and trace back version histories of the projects more intuitively, easily and flexibly, thereby improving development efficiency, reducing errors and improving code quality, helping to optimize development flow and improving team cooperation and project maintainability.
Based on the same inventive concept, an embodiment of the present application provides a FTTR-based log management and version control device 30, as shown in fig. 3, the FTTR-based log management and version control device 30 includes:
the log display unit 301 is configured to display the Git log using a-no-merges-remotes-reverse option in the absence of parameters;
A file obtaining unit 302, configured to add a plurality of version numbers to the initial git.log file to obtain a target git.log file;
and a version number display unit 303 for displaying detailed information of the specified version number in the target git.log file using the-v < version > option.
Optionally, the file obtaining unit 302 is further configured to:
acquiring a log view in reverse order according to the submitting sequence by adopting a-no-merges-remotes-reverse option; the log view has no merging record;
and storing the log view into a git.log empty file after processing, and obtaining an initial git.log file.
Optionally, the log management and version control device 30 based on FTTR further includes a mapping relationship table generating unit 304, configured to:
splitting the content in the output variable into lines line list by using len (output. Strip ("\n")) function, and generating a mapping relation table of sequence numbers and keywords;
and traversing the lines line list by adopting enumerate (lines) functions to generate element indexes and values.
Optionally, the file obtaining unit 302 is further configured to:
Traversing the mapping relation table by adopting mapping.item () function, and determining whether keywords matched with lines row table exist in the mapping relation table;
If the fact that the keywords matched with the lines row list exist in the mapping relation list is determined, generating a character string version_line containing version information;
inserting a character string version_line into the next row in the content list by adopting a content.insert (i+1, version_line) function to obtain an updated content list;
adopting a file.trunk () function to empty the original content of the initial git.log file to obtain a first git.log file;
And writing the updated content list into a first git.log file by using a file.writelines (content) function to obtain a target git.log file.
Optionally, the version number display unit 303 is further configured to:
For any version number, adopting a-v < version > option to determine whether any version number exists in the mapping relation table;
If any version number is determined to exist in the mapping relation table, constructing a git show-no-patch < commit hash > command; wherein, the gate show-no-patch < commit hash > command corresponds to a keyword of any version number;
executing a gate show-no-latch < commit hash > command by using subprocess module to obtain an execution result, and storing the execution result in an output variable;
Searching a Change-Id row according to the content of the output variable, and storing the Change-Id row in the change_id variable;
Change-Id line showing any version number, date submitted, and submitter.
Optionally, the version number display unit 303 is further configured to:
Determining detailed information of all submitted versions in the Git log by adopting a git.log file name option, and displaying the version number of each submitted version information;
and displaying various information in the target git.log file by adopting an open function.
Optionally, the FTTR-based log management and version control device 30 further includes a version resetting unit 305 for:
For any version number, determining whether any version number exists in the mapping relation table by using a reset < version > option;
If any version number is determined to exist in the mapping relation table, acquiring a keyword of any version number;
Constructing a git reset-hard < commit hash > command, wherein the git reset-hard < commit hash > command corresponds to a keyword of any version number;
The subprocess module is used to execute the Git reset-hard < commit hash > command and the Git warehouse is relocated to any version number.
The FTTR-based log management and version control device 30 may be used to perform the method performed in the embodiment shown in fig. 2, so the description of the functions that can be implemented by the functional modules of the FTTR-based log management and version control device 30 and the like can be referred to in the embodiment shown in fig. 2, and will not be repeated.
In some possible implementations, aspects of the method provided by the present application may also be implemented in the form of a program element comprising program code for causing a computer device to carry out the steps of the method according to the various exemplary embodiments of the application described herein above, when the program element is run on the computer device, e.g. the computer device may carry out the method as carried out in the example shown in fig. 2.
Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware associated with program instructions, where the foregoing program may be stored in a computer readable storage medium, and when executed, the program performs steps including the above method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk or optical disk, or the like, which can store program codes. Or the above-described integrated units of the invention may be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as separate parts. Based on such understanding, the technical solution of the embodiments of the present invention may be embodied in essence or a part contributing to the prior art in the form of a software component stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the embodiments of the present invention. And the aforementioned storage medium includes: a removable storage device, ROM, RAM, magnetic or optical disk, or other medium capable of storing program code.
While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
Claims (10)
1. A FTTR-based log management and version control method, which is applied to a FTTR framework, the method comprising:
Under the condition of no parameters, adopting a- -no-merges- -remotes- -reverse option to display the Git log;
Adding a plurality of version numbers into the initial git.log file to obtain a target git.log file;
And displaying detailed information of the version number specified in the target git.log file by adopting a-v < version > option.
2. The method of claim 1, wherein prior to adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further comprises:
Acquiring a log view in reverse order according to the submitting sequence by adopting a-no-merges-remotes-reverse option; wherein the log view has no merged record;
And storing the log view into a git.log empty file after processing, and obtaining the initial git.log file.
3. The method of claim 1, wherein prior to adding the plurality of version numbers to the initial git.log file to obtain the target git.log file, the method further comprises:
splitting the content in the output variable into lines line list by using len (output. Strip ("\n")) function, and generating a mapping relation table of sequence numbers and keywords;
Traversing the lines line list by adopting enumerate (lines) functions to generate element indexes and values.
4. A method according to claim 3, wherein the step of adding a plurality of version numbers to the initial git.log file to obtain a target git.log file comprises:
Traversing the mapping relation table by adopting a mapping.item () function, and determining whether a keyword matched with the lines list exists in the mapping relation table;
if the fact that keywords matched with the lines row table exist in the mapping relation table is determined, generating a character string version_line containing version information;
Inserting the character string version_line into the next row in the content list by adopting a content.insert (i+1, version_line) function to obtain an updated content list;
Adopting a file.trunk () function to empty the original content of the initial git.log file to obtain a first git.log file;
and writing the updated content list into the first git log file by using a file.writelines (content) function to obtain the target git log file.
5. A method according to claim 3, wherein the step of displaying detailed information of the specified version number in the target git.log file using a-v < version > option comprises:
for any version number, adopting a-v < version > option to determine whether the any version number exists in the mapping relation table;
If any version number is determined to exist in the mapping relation table, constructing a git show-no-patch < commit hash > command; wherein, the gate show-no-latch < commit hash > command corresponds to the key word of any version number;
executing the gate flash-no-latch < commit hash > command by using subprocess module to obtain an execution result, and storing the execution result in an output variable;
Searching a Change-Id row according to the content of the output variable, and storing the Change-Id row in a change_id variable;
A Change-Id line showing any version number, a date of submission, and a submitter.
6. The method of claim 1, wherein after adding a plurality of version numbers to the initial git.log file to obtain a target git.log file, the method further comprises:
Determining detailed information of all submitted versions in the Git log by adopting a git.log file name option, and displaying the version number of each submitted version information;
And displaying various information in the target git.log file by adopting an open function.
7. A method according to claim 3, wherein after adding a plurality of version numbers to the initial git.log file to obtain a target git.log file, the method further comprises:
For any version number, determining whether the any version number exists in the mapping relation table using a reset < version > option;
If the fact that any version number exists in the mapping relation table is determined, acquiring a keyword of any version number;
Constructing a git reset-hard < commit hash > command, wherein the git reset-hard < commit hash > command corresponds to the keyword of any version number;
And executing the gitreset-hard < commit hash > command by adopting a subprocess module, and resetting the Git warehouse at the position of any version number.
8. A FTTR-based log management and version control device for use in a FTTR framework, the device comprising:
The log display unit is used for displaying the Git log by adopting a-no-merges-remotes-reverse option under the condition of no parameters;
The file obtaining unit is used for adding a plurality of version numbers into the initial git.log file to obtain a target git.log file;
and the version number display unit is used for displaying detailed information of the specified version number in the target git.log file by adopting a-v < version > option.
9. An electronic device, the device comprising:
A memory for storing program instructions;
A processor for invoking program instructions stored in the memory and for performing the method of any of claims 1-7 in accordance with the obtained program instructions.
10. A storage medium having stored thereon computer executable instructions for causing a computer to perform the method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410433851.9A CN118034777B (en) | 2024-04-11 | 2024-04-11 | FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410433851.9A CN118034777B (en) | 2024-04-11 | 2024-04-11 | FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN118034777A true CN118034777A (en) | 2024-05-14 |
| CN118034777B CN118034777B (en) | 2024-06-25 |
Family
ID=90989816
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410433851.9A Active CN118034777B (en) | 2024-04-11 | 2024-04-11 | FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118034777B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200104121A1 (en) * | 2018-09-28 | 2020-04-02 | Atlassian Pty Ltd | Efficient storage and analysis of source code modification history data |
| CN112698866A (en) * | 2021-01-06 | 2021-04-23 | 中国科学院软件研究所 | Code line life cycle tracing method based on Git and electronic device |
| CN112947992A (en) * | 2021-03-31 | 2021-06-11 | 建信金融科技有限责任公司 | Method and device for managing code version |
| CN117251197A (en) * | 2023-07-20 | 2023-12-19 | 浪潮云信息技术股份公司 | Method for realizing management of Submodule item Git based on node. Js |
-
2024
- 2024-04-11 CN CN202410433851.9A patent/CN118034777B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200104121A1 (en) * | 2018-09-28 | 2020-04-02 | Atlassian Pty Ltd | Efficient storage and analysis of source code modification history data |
| CN112698866A (en) * | 2021-01-06 | 2021-04-23 | 中国科学院软件研究所 | Code line life cycle tracing method based on Git and electronic device |
| CN112947992A (en) * | 2021-03-31 | 2021-06-11 | 建信金融科技有限责任公司 | Method and device for managing code version |
| CN117251197A (en) * | 2023-07-20 | 2023-12-19 | 浪潮云信息技术股份公司 | Method for realizing management of Submodule item Git based on node. Js |
Non-Patent Citations (2)
| Title |
|---|
| 李冬男等: "基于Web的Git可视化设计与实现", 《现代计算机(专业版)》, no. 19, 5 July 2016 (2016-07-05), pages 40 - 45 * |
| 鳌白白: "Git使用手册/Git教程：git log 查看git提交版本历史日志记录", pages 1 - 11, Retrieved from the Internet <URL:https://blog.csdn.net/u013374164/article/details/79091677> * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN118034777B (en) | 2024-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220342875A1 (en) | Data preparation context navigation | |
| US8307010B2 (en) | Data feature tracking through hierarchical node sets | |
| US10691584B2 (en) | Behavior driven development integration with test tool | |
| CN109471851B (en) | Data processing method, device, server and storage medium | |
| US20150248404A1 (en) | Database schema migration | |
| US9390111B2 (en) | Database insert with deferred materialization | |
| US8589454B2 (en) | Computer data file merging based on file metadata | |
| CN112035443A (en) | Big data execution method, system, equipment and storage medium based on Linux platform | |
| CN112799718A (en) | Enumerated document generation method and device, electronic equipment and storage medium | |
| US10592400B2 (en) | System and method for creating variants in a test database during various test stages | |
| CN115238655A (en) | Json data editing method and device | |
| CN113094625B (en) | Page element positioning method and device, electronic equipment and storage medium | |
| US11556531B2 (en) | Crux detection in search definitions | |
| CN118034777B (en) | FTTR-based log management and version control method, FTTR-based log management and version control device, FTTR-based log management and version control equipment and medium | |
| CN112463896B (en) | Archive catalogue data processing method, archive catalogue data processing device, computing equipment and storage medium | |
| CN112783927B (en) | Database query method and system | |
| CN110688103B (en) | Code writing method, device, electronic equipment and computer readable storage medium | |
| CN114968725A (en) | Task dependency relationship correction method and device, computer equipment and storage medium | |
| CN111427902B (en) | Metadata management method, device, equipment and medium based on lightweight database | |
| CN113901025A (en) | Database management method, device, equipment and storage medium | |
| CN113504904A (en) | User-defined function implementation method and device, computer equipment and storage medium | |
| CN115248803B (en) | Collection method and device suitable for network disk file, network disk and storage medium | |
| CN111626585B (en) | Script data extraction method and device, computer equipment and storage medium | |
| CN118210488A (en) | Method, system and terminal equipment for generating codes and interface documents based on sql | |
| CN117785698A (en) | Software test case method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |