Graphical Git_ diagram

Diagram git Other languages: Deutsch 中文版 Español français italiano Japanese language 한국어polski Portuguêsрусскийslovenčina tiếng Việt Body Chinese

This page illustrates the most common commands in Git. If you understand a little bit about how git works, this article will give you a more thorough understanding. If you want to know how this site is generated, please go to GitHub repository. Text Basic Usage Agreement command details Diff Commit Checkout Detached Head (anonymous branch submission) Reset Merge Cherry Pick Rebase Technical Description Basic usage

The above four commands 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 commits a snapshot to the staging area and commits it. Git reset-Files are used to undo the last Git add files, and you can also undo all staging areas with Git reset. Git checkout-Files copy the file 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 into interactive mode.

You can also skip the staging area to remove files directly 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 before running. Git commit. Git commit files contains a submission for 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 Roll back to replication for the last commit. Conventions

The following text uses pictures in the form below.

The green 5-bit character represents the submitted ID, pointing to the parent node, respectively. Branches are shown in orange, pointing to specific submissions. 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 submission, and the other Maint branch points to the grandparent submission node. Command detailed Diff

There are a number of ways to view changes between submissions for two of times. Here are some examples. Commit

At the time of submission, Git creates a new commit with the file in the staging area and sets the node at this point to the parent node. The current branch is then pointed to the new submission node. In the following illustration, the current branch is master. Before running the command, Master points to ed489, and after committing, master points to the new node F0CEC and ed489 as the parent node.

Git does the same thing even if the current branch is a grandparent that was submitted some time. In the following figure, the grandfather node Maint branch of the master branch is committed once, generating a 1800b. In this way, the Maint branch is no longer the grandparent node of the master branch. At this point, merging (or blending) is necessary.

If you want to change a commit, use Git commit--amend. Git uses the same parent node as the current commit to make a new commit, and the old commit is canceled.

Another example is the separation head submission, after the text is spoken. Checkout

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

When given a filename (or if the-P option is turned on, or the file name and the-P option open simultaneously), Git copies the files from the specified commit to the staging area and working directory. For example, git checkout head~ foo.c copies foo.c from the submission node head~ (that is, the parent of the current submission node) to the working directory and to the staging area. (If no submission node is specified in the command, the content is copied from the staging area.) Note that the current branch is not changed.

When no filename is specified, but a (local) branch is given, the head ID is moved to that branch (that is, we "switch" to that branch), and the contents of the staging area and the working directory are aligned with the submission node of the head. All files in the new submission node (A47C3 in the following figure) are copied (to the staging area and working directory), files that exist only in the old commit node (ed489) are deleted, and files that do not belong to both are ignored and unaffected.

If you do not specify a filename or a branch name, but a label, remote branch, SHA-1 value, or something like master~3, you get an anonymous branch called the detached head (the separated head ID). This makes it easy to switch between historical versions. For example, if you want to compile the 1.6.6.1 Version of Git, you can run git checkout v1.6.6.1 (this is a tag, not a branch name), compile, install, and then switch back to another branch, such as Git checkout master. However, when the commit operation involves a "separate head", the behavior is slightly different and the details are shown below. Commit action when head identity is in a detached state

When the head is in a detached state (not attached to any branch), the commit operation works, 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, the submission node (possibly) will no longer be referenced, and it will be discarded. Note that this command will not have anything to quote 2EECB.

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 has a selected change of working directory and index. It is also used to copy files from the history warehouse to the index without moving the working directory.

If the option is not given, then the current branch points to that commit. If you use the--hard option, the working directory is also updated and will not change if you use the--soft option.

If no version number is given for the submission point, the head is used by default. In this way, the branch point does not change, but the index rolls back to the last commit and, if you use the--hard option, the working directory is the same.

If the filename (or the-P option) is given, the work effect is similar to the checkout with the filename, except that the index is updated. Merge

The merge command merges the different branches. The index must be the same as the current commit before merging. If another branch is the currently committed grandparent, then the merge command does nothing. Alternatively, if the current commit is a grandparent node of another branch, it causes the fast-forward to merge. Point to simply move and generate a new commit.

Otherwise it would be a real merger. The default is a three-party merge of the current submission (ed489 below) and another commit (33104) and their common grandparents node (b325c). The result is to save the current directory and index first, and then make a new commit with the parent node 331,041. Cherry Pick

The Cherry-pick command "replicates" a submission node and makes the exact same new commit in the current branch. Rebase

Blending is another option for merging commands. Merging two parent branches for one commit, and submission history is not linear. It repeats the history of another branch on the current branch, and the submission history is linear. In essence, this is the linearized automatic Cherry-pick

The above commands are performed in the topic branch, not the master branch, which repeats on the master branch and points the branch to the new node. Note that the old commit is not referenced and will be reclaimed.

To limit the rollback scope, use the--onto option. The following command repeats the most recent submissions from 169A6, the 2c33a, on the master branch.

Also, git rebase--interactive makes it easier for you to perform complex operations, such as discarding, rearrangement, modifying, and merging submissions. No picture embodies these, details look here: git-rebase (1) 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 a blob, and are validated with SHA-1 values. The index file lists the associated blob file and other data with the identifier. For submissions, storage in tree form is also identified with the hash value for. The tree corresponds to a folder in the working directory, and the tree or Blob object contained in the tree corresponds to the corresponding subdirectory and file. Each commit stores the identification number of its upper-level tree.

If submitted with detached head, the last commit will be referenced by the Reflog for head. But after a while it's not going to end up being recycled, like git commit--amend or git rebase.

From:https://marklodato.github.io/visual-git-guide/index-zh-cn.html