Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the working principle of Git". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the working principle of Git"?

This article illustrates the most common commands in Git. If you have a little understanding of how Git works, this article will give you a better understanding.

Basic usage

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

Git add files puts the current file in the temporary storage 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, or you can 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 changes.

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

You can also skip the temporary storage area and retrieve the file directly from the warehouse or submit the code directly.

Git commit-an is equivalent to running git add to add all the files in the current directory to the staging area and run again.

Git commit files makes a commit that includes the last commit plus a snapshot of the file in the working directory. And the file is added to the staging area.

Git checkout HEAD-files rollback to copy the last commit.

Agreement

Use the picture in the following form later.

The green five-digit characters represent the submitted ID, pointing to the parent node. Branches are shown in orange, each pointing to a specific submission. The current branch is identified by the HEAD attached to it. This picture shows the last 5 submissions, and ed489 is the latest submission. The master branch points to this submission, and another maint branch points to the grandfather submission node.

Detailed explanation of command

Diff

There are many ways to see the changes between commits, and here are some examples.

Commit

When submitting, Git creates a new commit with the file in the staging area and sets the node at this time as the parent node. Then point the current branch to the new submission node. In the following figure, the current branch is master. Before running the command, master points to ed489, and after commit, master points to the new node f0cec with ed489 as the parent.

Even if the current branch is the grandfather node of a commit, git will do the same. In the following figure, the maint branch, the grandfather node of the master branch, makes a commit and generates 1800b. In this way, the maint branch is no longer the grandfather node of the master branch. At this point, merging [1] (or derivative [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 submission will be cancelled.

Another example is the separation of HEAD submissions [3], which will be discussed later.

Checkout

The Checkout command is used to copy files from the history commit (or staging area) to the working directory, or to switch branches.

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

When a (local) branch is given instead of a file name, the HEAD logo moves to that branch (that is, we "switched" to that branch), and then the contents of the staging area and working directory are consistent with the corresponding commit node of HEAD. All files in the new commit node (a47c3 in the following figure) will be copied (to the staging area and working directory); files that only exist in the old commit node (ed489) will be deleted; and files that do not belong to the above two will be ignored and unaffected.

If you specify neither a file name nor a branch name, but a label, remote branch, SHA-1 value, or something like master~3, you get an anonymous branch called detached HEAD (detached HEAD identity). 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 tag, not a branch name), compile, install, and switch back to another branch, such as git checkout master. However, when the commit operation involves a "detached HEAD", the behavior is slightly different, as detailed below.

HEAD identifies the commit operation when it is in a detached state

When the HEAD is detached (not attached to either branch), the commit operation can proceed normally, but no named branches are updated. (you can think of this as updating an anonymous branch. )

Once you switch to another branch, such as master, then the submission node will never be referenced again and will then be discarded. Notice that there is nothing to quote 2eecb after this command.

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

Reset

The Reset command points the current branch to another location, and changes the working directory and index selectively. It is also used to copy files from the history repository to the index without changing the working directory.

If no option is given, the current branch points to that submission. If you use the-hard option, the working directory is also updated, and if you use the-soft option, it remains the same.

If the version number of the submission point is not given, HEAD is used by default. In this way, the branch direction remains the same, but the index rolls back to the last commit, and if you use the-hard option, the working directory is the same.

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

Merge

The Merge command merges the different branches. Before merging, the index must be the same as the current commit. If the other branch is the grandfather node of the current submission, the merge command will do nothing. Another situation is that if the current commit is the grandfather node of another branch, it results in a fast-forward merge. Point to simply move and generate a new submission.

Otherwise, it would be a real merger. By default, the current submission (ed489 is shown below) and another submission (33104) and their common grandfather node (b325c) are merged once [4]. The result is to save the current directory and index, and then make a new commit with the parent node 33104.

Cherry Pick

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

Rebase

Derivative is another option for merge commands. Merge merges two parent branches for a single commit, and the submission history is not linear. The derivative repeats the history of another branch on the current branch, and the submission history is linear. In essence, this is a linearized automatic cherry-pick.

The above command is done in the topic branch, not the master branch, repeats itself on the master branch, and points the branch to the new node. Note that the old submission is not referenced and will be recycled.

To limit the scope of the rollback, use the-onto option. The following command repeats the most recent commit of the current branch since 169a6, 2c33a, on the master branch.

There is also git rebase-interactive that makes it easier for you to perform complex operations, such as discarding, rearranging, modifying, merging and submitting. There are no pictures to show these. See here for details: git-rebase (1) [5].

Technical description

The contents of the file are not actually stored in the index (.git / index) or the commit object, but are stored in the database (.git / objects) in the form of blob and verified with the SHA-1 value. The index file lists the relevant blob files and other data with an identification code. For a submission, it is stored as a tree, which is also identified by the hash value of the. The tree corresponds to the folder in the working directory, and the tree or blob objects contained in the tree correspond to the corresponding subdirectories and files. Each submission stores the identification code of its upper tree.

If you commit with detached HEAD, the last commit will be referenced by the reflog for HEAD. But it fails after a period of time and is eventually recycled, much like git commit-amend or git rebase.

Thank you for your reading, the above is the content of "what is the working principle of Git". After the study of this article, I believe you have a deeper understanding of what the working principle of Git is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.