Detailed explanation with pictures and text! Understand how Git works

This article brings you relevant knowledge about the working principle of Git, which is mainly used to explain in detail with pictures and text. I hope it will be helpful to everyone.

Illustration of how git works

This article illustrates the most commonly used commands in Git. If you have a little understanding of how Git works, this article can give you a more thorough understanding.

The four commands above copy files between the working directory, the staging directory (also called the index), and the warehouse.

• git add files puts the current file into the staging area.

• git commit generates a snapshot of the staging area and submits it.

• git reset – files is used to undo the last git add files. You can also use git reset to undo all temporary area files.

• git checkout – files copies files from the staging area to the working directory to discard local modifications.

You can use git reset -p, git checkout -p, or git add -p to enter interactive mode.

You can also skip the staging area and directly retrieve files from the warehouse or submit the code directly.

• git commit -a is equivalent to running git add to add all files in the current directory to the staging area and then run it.

• git commit filesMake a commit that contains the last commit plus a snapshot of the files in the working directory. And the file is added to the staging area.

• git checkout HEAD – files rollback to copy the last commit.

In the following text, pictures are used in the following form.

#The green 5-digit characters represent the submitted ID, which points to the parent node respectively. Branches are shown in orange and point to specific commits. The current branch is identified by the HEAD attached to it. This picture shows the last 5 submissions, ed489 is the latest submission. The master branch points to this commit, and the other maint branch points to the grandparent commit node.

Diff

There are many ways to view changes between commits, here are some examples.

Commit

When submitting, Git creates a new submission using the files in the staging area and puts the node at that time Set as parent node. Then point the current branch to the new commit node. In the picture below, the current branch is master. Before running the command, master points to ed489. After submission, master points to the new node f0cec with ed489 as the parent node.

#Even if the current branch is the grandparent node of a certain submission, git will operate in the same way. In the figure below, a commit is made on the maint branch, the grandfather node of the master branch, and 1800b is generated. In this way, the maint branch is no longer the grandparent of the master branch. At this time, merging [1] (or rebasing [2]) is necessary.

If you want to change a commit, use git commit –amend. Git will make a new commit using the same parent node as the current commit, and the old commit will be cancelled.

Another example is to separate the HEAD submission [3], which will be discussed later.

Checkout

The Checkout command is used to copy files from historical submissions (or staging area) to the working directory, and can also be used to switch branches.

When a file name is given (or the -p option is turned on, or the file name and the -p option are turned on at the same time), Git will copy the file from the specified commit to the staging area and working directory. For example, git checkout HEAD~ foo.c will copy foo.c in the commit node HEAD~ (that is, the parent node of the current commit node) to the working directory and add it to the staging area. (If no commit node is specified in the command, the content will be copied from the staging area.) Note that the current branch will not change.

When the file name is not specified, but a (local) branch is given, the HEAD identifier will be moved to that branch (that is, we "switch" to that branch), and then the staging area and working directory The content in will be consistent with the submission node corresponding to HEAD. All files in the new submission node (a47c3 in the figure below) will be copied (to the staging area and working directory); files that only exist in the old submission node (ed489) will be deleted; files that do not belong to the above two files will be ignored and not affected.

If neither a file name nor a branch name is specified, but a tag, remote branch, SHA-1 value or something similar like master~3, You get an anonymous branch called detached HEAD (detached HEAD identifier). This makes it easy to switch between historical versions. For example, if you want to compile version 1.6.6.1 of Git, you can run git checkout v1.6.6.1 (this is a label, not a branch name), compile, install, and then switch back to another branch, such as git checkout master. However, when a commit operation involves a "detached HEAD", the behavior is slightly different, as detailed below.

Follow the public account "Java Backend Technology Full Stack", reply to the interview, and obtain high-quality interview materials

When the HEAD logo is in the detached state Commit operation

When HEAD is in a detached state (not attached to any branch), the commit operation can proceed normally, but any named branches will not be updated. (You can think of this as updating an anonymous branch.)

Once you switch to another branch, such as master, then this commit node (maybe) will no longer be available It will not be referenced and will be discarded. Note that nothing will reference 2eecb after this command.

However, if you want to save this state, you can use the command git checkout -b name to create a new branch.

Reset

The Reset command points the current branch to another location and optionally changes the working directory and index. Also used to copy files from the historical repository to the index without touching the working directory.

If no option is given, the current branch points to that commit. If the –hard option is used, the working directory is also updated, and if the –soft option is used, it remains unchanged.

If the version number of the submission point is not given, HEAD is used by default. In this way, the branch point remains unchanged, but the index will be rolled back to the last commit. If the –hard option is used, the working directory will be the same.

If a file name (or -p option) is given, the working effect is similar to checkout with a file name, except that the index is updated.

Merge

The Merge command merges different branches. Before merging, the index must be the same as the current commit. If another branch is the grandparent of the current commit, the merge command will do nothing. Another situation is if the current commit is the grandparent of another branch, causing a fast-forward merge. The pointer is simply moved and a new commit generated.

Otherwise it’s a real merge. By default, a three-way merge is performed between the current commit (ed489 shown below) and another commit (33104) and their common grandparent node (b325c) [4]. The result is to save the current directory and index first, and then make a new commit together with the parent node 33104.

Cherry Pick

The cherry-pick command "copies" a commit node and makes an identical new commit on the current branch .

Rebase

Rebasing is an alternative to merging commands. Merge merges two parent branches into one commit, and the commit history is not linear. Rebasing replays the history of another branch on the current branch, and the commit history is linear. Essentially, this is linearized automatic cherry-picking.

The above commands are all executed in the topic branch, not the master branch. They are repeated on the master branch and point the branch to the new node. Note that the old commit is not referenced and will be recycled.

To limit the rollback scope, use the –onto option. The following command replays the last few commits of the current branch since 169a6 on the master branch, which is 2c33a.

There is also git rebase –interactive, which allows you to complete some complex operations more conveniently, such as discarding, rearranging, modifying, and merging commits. There are no pictures showing this, see here for details: git-rebase(1)[5].

The file content is not actually stored in the index (.git/index) or the submission object, but is stored in the database (.git/objects) in the form of blobs, and is calibrated with the SHA-1 value. test. The index file lists related blob files and other data with identifiers. For submissions, they are stored in the form of a tree and are also identified by their hash values. The tree corresponds to the folder in the working directory, and the tree or blob object contained in the tree corresponds to the corresponding subdirectory and file. Each submission stores the identification code of its upper-level tree.

If you submit using detached HEAD, the last submission will be referenced by the reflog for HEAD. But it becomes invalid after a while and is eventually recycled, much like git commit –amend or git rebase.

Recommended study: "Git Tutorial"

The above is the detailed content of Detailed explanation with pictures and text! Understand how Git works. For more information, please follow other related articles on the PHP Chinese website!