git version history

Version: Git rev-parse

--GIT-DIR Displays the location of the Git repository--show-cdup displays the depth of the current workspace directory--parseopt parsing command-line arguments

$ git rev-parse--symbolic--branches display Branch

$ git rev-parse--symbolic--tags show milestone

$ git rev-parse--symbolic--glob=refs/* displays all references that are defined. Where references under the refs/remotes/directory are referred to as remote branches (or remote references)

$ git rev-parse head display head corresponding to SHA1 hash value

$ git rev-parse a^{tree} A: Shows the directory tree for milestone a

$ git rev-parse a^{tree}:src/makefile a:src/makefile display the file inside the tree

$ git rev-parse:/"Commit A" displays a commit by looking up a string in the commit log

Version range: Git rev-list

A commit ID can actually represent a list of versions, meaning that all the history of that version is submitted $git rev-list--oneline A

Two or more versions, equivalent to the set of the list of the referring generation when each version is used alone

Precede a version with the symbol ^ meaning is reversed, that is, exclude this version and its historical version ^g D is equivalent to G. D

... The notation meaning is the exception of the two versions that are common to access

B^@ represents the historical submission of a submission, excluding itself

B^! that the submission itself does not include its historical submission

Browsing logs: Git log

You can then follow the parameters that represent the version range (as on Git rev-list)

The--graph parameter can display the commit graph of the character interface, and different branches can be represented in different colors

-<n> show the most recent n logs

-P can display the changes at the same time when the log is displayed

You can use the--stat parameter when you don't need to know the specific changes and only want to know which files are changed

--pretty=raw displays the original data of the commit and can display the tree ID of the commit

--pretty=fuller both the author and the submitter, which can be different

--pretty=oneline provides the most streamlined log output, or you can use the--oneline parameter

If you want to view and parse only one commit, you can also use Git cat-file (the meaning of the-p parameter is beautiful output) or git show command

Difference comparison: Git diff

$ git diff b A compare Milestone B and milestone a

$ git diff a compare workspaces and milestone a

$ git diff--cached a compare staging area and milestone a

$ git diff compare workspaces and staging area

$ git diff--cached compare staging area and head

$ git diff head compare workspaces and head

$ git diff <commit1> <commit2>-<paths> show file differences between different versions of this path

$ git diff <path1> <path2> can be executed outside of the Git repository, compared to a non-git directory

$ git diff--word-diff-word comparison

File traceability: Git blame

When a bug is found in the software development process and the specific code is located, you can indicate when and what version introduced the bug.

When the git blame command is executed against a file, the file is displayed row by line, showing at the beginning of each line what version of the row was first introduced and by whom

If you want to display only a few rows, use the-l N,M parameter

Binary search: Git bisect

$ git bisect start binary search

$ git bisect bad A will mark a version as a dirty commit

$git bisect Good mark the current version as good commit

$ git checkout Bisect/bad switch to the final location of the bad commit version

$ git bisect reset when locating and repairing bugs, Undo binary finds temporary files and references left over from the repository. After undoing a binary lookup, the repository switches back to the branch where the binary search was performed before

If a good commit is treated as a bad commit:

$ git bisect log > LogFile Save the binary lookup log in a file, edit the file, and delete the line that recorded the wrong action.

$ git bisect reset ends an error binary lookup in progress

$ git bisect replay logfile recovery Progress via log file, restart binary lookup

Automated testing:

With the RUN subcommand, you can run an automated test script that enables automatic binary lookups. If the script exit code is 0, the version being tested is a good version, the exit code is 125, the version being tested is skipped, the exit code is 1~127 (except 125), the version being tested is a bad version

To test the script good-or-bad.sh, follow these steps:

(1) $ git bisect start Master G starting a new round of binary search from known bad version Master and good version G

(2) $ git bisect run SH good-or-bad.sh automated test

(3) $ git describe Refs/bisect/bad display defined to bad version

Get the File History version command:

$ git ls-tree <tree-ish> <paths> View History submitted directory tree

$ git checkout <commit> entire workspace switch to historical version

$ git checkout <commit>--<paths> Check out the historical version of a file

$ git show <commit>:<file> > new_name Check out the historical version of a file to another filename

git version history