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

This article introduces the knowledge of "what is the essence of Git instructions". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Preface

As the most powerful code management tool in the world, Git is familiar to everyone, but as far as I know, there are a large number of people staying in clone, commit, pull and push.... In the stage of rebase, do you dare to use merge only if you are not sure about it?

Catch blind when you run into a version of fallback? Don't ask me how I know, ask: "I used to be like this."

In view of these problems, today I will share my understanding and understanding of Git in the past few years, explain Git from the essence as much as possible, and help you understand the underlying principles of Git step by step. I believe that after reading this article, you can change your attitude and use Git instructions more coquettish.

Catalogue

1. Basic concept

1.1 benefits of Git

1.2 File status

1.3 commit nodes

1.4 HEAD

1.5 remote warehouse

two。 Branch

2.1 what is a branch?

3. Detailed explanation of command

3.1 submit relevant

3.2 Branch correlation

3.3 merge correlation

3.4 fallback correlation

3.5 remote correlation

1. Basic Concepts 1.1 advantages of Git

Git is a distributed code management tool. Before discussing distribution, we can't avoid mentioning what is a centralized code management repository.

Centralized: all the code is stored in the central server, so the submission must rely on the network, and each submission will be brought to the central warehouse, if it is collaborative development may frequently trigger code merging, thus increasing the cost and cost of submission. The most typical one is svn.

Distributed: can be submitted locally without relying on the network, and each submission will be automatically backed up locally. Every developer can send a copy of the remote repository clone locally and bring the submission history along with it. The representative is Git.

So what are the advantages of Git over svn?

For example, "Barabala wrote a lot of code and suddenly found that there was something wrong with it. I want to go back to an hour ago." in this case, the advantage of Git is obvious, because the cost of commit is relatively low and all submission records are kept locally, which can be rolled back at any time.

It's not that svn can't do this, it's just that Git fallback will be more elegant. Git has many advantages over centralized tools, so you can learn about them if you are interested.

1.2 File status

In Git, files are roughly divided into three states: modified (modified), temporarily saved (staged), and submitted (committed).

Modification: Git can sense which files in the working directory have been modified, and then add the modified files to the modified area

Temporary storage: submit the modified files in the working directory to the temporary storage area through the add command, waiting to be commit

Submit: permanently save the staging area file commit to the Git directory

1.3 commit nodes

For ease of expression, I will submit this article through the node surrogate commit.

In Git, each commit will generate a node, and each node will have a hash value as a unique indicator, multiple submissions will form a linear node chain (regardless of merge), as shown in figure 1-1

Above the node is the hash value calculated by SHA1

C2 nodes contain C1 submissions, and C3 nodes also contain C1 and C2 submissions

1.4 HEAD

HEAD is a very important concept in Git, you can call it a pointer or reference, it can point to any node, and the node it points to is always the current working directory, in other words, the current working directory (that is, the code you see) is the node that HEAD points to.

Taking figure 1-1 as an example, if HEAD points to C2, the working directory corresponds to C2 nodes. Exactly how to move the HEAD will be discussed later, so don't worry about it here.

At the same time, HEAD can also point to a branch and indirectly point to the node that the branch points to.

1.5 remote warehouse

Although Git saves the code and history locally, it will eventually be submitted to a remote repository on the server. Through the clone command, you can download the code of the remote repository locally, and synchronize the submission history, branch, HEAD and other status to the local location. However, these statuses are not updated in real time and need to be pulled manually from the remote repository. When to pull and how to pull will be discussed in later chapters.

Through the remote warehouse as an intermediary, you can collaborate with your colleagues to develop new features, you can apply for submission to the remote warehouse, and you can also pull your colleague's code from the remote warehouse.

Pay attention

Because you and your colleagues are based on the code of the remote warehouse, always ensure the quality of the code of the remote warehouse and remember not to submit untested code to the remote warehouse.

two。 Branch 2.1 what is a branch?

Branch is also a very important concept in Git. When a branch points to a node, the content of the current node is the content of the branch. Its concept is very close to HEAD and can also be regarded as a pointer or reference, except that there can be multiple branches, while there is only one HEAD. Different branches are usually established based on the function or version.

What's the use of that branch?

For example: after a lot of hardships, your App finally released v1.0. Due to the urgent need for v1.0, it started v1.1 non-stop after the launch of v1.0. Just when your development was on the rise, QA said that users gave feedback on some bug, which needed to be repaired and then reissued. Repairing v1.0 must be based on v1.0 code, but you have already developed a part of v1.1. What happens at this time?

The above problems can be solved elegantly by introducing the concept of branching, as shown in figure 2-1.

First look at the diagram on the left, assuming that the C2 node is v1.0 version code, and then create a new branch ft-1.0 based on C2 after launch.

Looking at the diagram on the right, we can develop v1.1 content in the master branch after v1.0 is launched. After receiving feedback from QA classmates, submit v1.1 code generation node C3, then switch to ft-1.0 branch for bug repair, submit code generation node C4 after repair, and then switch to master branch and merge ft-1.0 branch. So we have solved the above problem.

In addition, there are many things you can do with branches. For example, there is a requirement that you are not sure whether you want to go online, but you have to do it first. At this time, you can create a separate branch to develop this function, and when you need to go online, you can merge it directly into the main branch. There are many scenarios in which branches are applicable.

Pay attention

When a branch is created in a node, the corresponding code of the node is not copied, but the new branch is pointed to the node, so the space overhead can be greatly reduced. It is important to remember that both HEAD and branches are just references and are of a very light order of magnitude.

3. Command explanation 3.1 submit relevant

As we mentioned earlier, if you want to commit the code, you must first add it to the staging area, which is achieved by the command add in Git.

Add a file to the staging area:

Git add file path

Add all files to the staging area:

Git add.

At the same time, Git also provides commands to undo workspaces and staging areas

Undo workspace changes:

Git checkout-File name

Clear the staging area:

Git reset HEAD file name

Submit:

After adding the change file to the temporary storage area, you can submit it, and a new submission node will be generated after submission. The specific commands are as follows:

Git commit-m "description of this node" 3.2 Branch related

Create a branch

After creating a branch, the branch will point to the same node as HEAD. The popular point is that the new branch created by HEAD will point to where it points. The command is as follows:

Git branch Branch name

Switch branch

When a branch is switched, HEAD points to the current branch by default, that is, HEAD indirectly points to the node that the current branch points to

Git checkout Branch name

At the same time, you can also switch immediately after creating a branch, as follows:

Git checkout-b branch name

Delete Branch

In order to keep the warehouse branch concise, it should be deleted when a branch has completed its mission. For example, as mentioned earlier, opening a separate branch to complete a function, when this function is merged into the main branch, the branch should be deleted in time.

The delete command is as follows:

Git branch-d branch name 3. 3 merge related

The command for merging is the most difficult and important to master. Our common merge commands are about three merge, rebase, and cherry-pick

Merge

Merge is the most commonly used merge command, which merges the code of a branch or node into the current branch. The specific commands are as follows:

Git merge Branch name / Node Hash value

If the branch that needs to be merged is completely ahead of the current branch, as shown in figure 3-1

Because the branch ft-1 is completely ahead of the branch ft-2, that is, the ft-1 fully contains ft-2, the ft-2 executes a "git merge ft-1" and triggers a fast forward (fast merge), where the two branches point to the same node, which is the ideal state.

But in actual development, we often encounter the following situation: figure 3-2 (left)

This situation cannot be closed directly. When ft-2 executes "git merge ft-1", Git merges nodes C3 and C4 to form a new node C5, and finally points ft-2 to C5 as shown in figure 3-2 (right).

Note:

If C3 and C4 modify the same sentence of code in the same file at the same time, merging will make an error, because Git does not know which node to use as the standard, so we need to merge the code manually at this time.

Rebase

Rebase is also a merge instruction, and the command line is as follows:

Git rebase Branch name / Node Hash value

Unlike merge, a rebase merge does not seem to produce new nodes (it actually does, just a copy), but directly accumulates the nodes that need to be merged as shown in figure 3-3.

When the ft-1.0 in the diagram on the left performs git rebase master, it makes a copy of the C4 node after C3, that is, C4 corresponds to C4', but the hash value is different.

Rebase is more linear and cleaner than merge submission history, making parallel development processes look serial and more intuitive. Since rebase is so easy to use, can we abandon merge? Actually, no, here are some of the advantages and disadvantages of merge and rebase:

Advantages and disadvantages of merge:

Advantages: each node is arranged strictly according to time. When there is a conflict in the merger, you only need to resolve the conflict between the nodes pointed to by the two branches.

Disadvantages: when two branches are merged, there is a high probability that new nodes will be generated and bifurcated, and over time the submission history will become a mess.

Advantages and disadvantages of rebase:

Pros: it makes the submission history look more linear and clean

Cons: although the submission looks linear, it is not really sorted by time, as in figure 3-3, whether C4 is submitted earlier or later than C3, it will eventually be placed after C3. And when there is a conflict in the merge, theoretically speaking, it is possible to deal with several conflicts when there are several nodes rebase to the target branch.

For some of the views on the network that only use rebase, the author disagrees that if different branches merge to use rebase, it may need to repeatedly resolve conflicts, so the loss outweighs the gain. However, if it is pushed locally to the remote and corresponds to the same branch, rebase can be given priority. So my view is to use merge and rebase reasonably according to different scenarios. If you think it's all right, then use rebase first.

Cherry-pick

The merge of cherry-pick is different from merge and rebase. It can select certain nodes to merge, as shown in figure 3-4.

Command line:

Hash value of git cherry-pick node

Assuming that the current branch is master, the command git cherry-pick C3 (hash value) and C4 (hash value) will directly grab the C3 and C4 nodes and put them behind, corresponding to C3' and C4'.

3.4 fallback correlation

Separate HEAD

By default, HEAD points to the branch, but you can also remove the HEAD from the branch and point it directly to a node. This process is to separate the HEAD. The specific command is as follows:

The hash value / / of the git checkout node can also be directed directly from the branch to the current node git checkout-detach

Because the hash value is a long string of garbled codes, it is troublesome to use the hash value to separate HEAD in practice, so Git also provides the command that HEAD points directly to the first or the first N nodes based on a special location (branch / HEAD), that is, relative reference, as follows:

/ / HEAD detach and point to the previous node git checkout branch name / head ^ / / HEAD detach and point to the first N nodes git checkout branch name ~ N

What is the use of separating the HEAD to point to the node? For example, if the development process finds that there is a problem with the previous submission, you can point the HEAD to the corresponding node at this time, modify it and then submit it. You certainly do not want to regenerate into a new node, but you just need to add-- amend when submitting. The specific command is as follows:

Git commit-amend

Fallback

Fallback scenarios are quite common in normal development. For example, Barabara writes a lot of code and then submits it, and later finds that there is something wrong with the writing, so you want to return the code to the previous submission. This scenario can be solved through reset. The specific commands are as follows:

/ / fallback N submission git reset HEAD~N

Reset is very similar to relative references, except that reset causes both branches and HEAD to fall back.

3.5 remote correlation

When we come into contact with a new project, the first thing to do is to take down its code. In Git, you can copy a copy of the code from the remote repository to the local through clone, as follows:

Git clone warehouse address

As I mentioned in the previous section, clone doesn't just copy the code, it also removes the reference (branch / HEAD) from the remote repository and saves it locally, as shown in figure 3-5:

Origin/master and origin/ft-1 are branches of the remote repository, and the remote reference status will not be updated locally in real time. For example, the origin/master branch of the remote repository adds a commit, so the local origin/master branch still points to the C4 node. We can manually update the remote warehouse status through the fetch command

Tips:

It doesn't exist on the server to call it a remote warehouse. You can also clone the local warehouse as a remote. Of course, in actual development, we can't regard the local warehouse as a public warehouse, saying that this is simply to help you understand the distribution more clearly.

Etch

To put it more colloquially, the fetch command is a download operation, which downloads the newly added remote nodes and the status of the reference (branch / HEAD) locally, as follows:

Git fetch remote warehouse address / branch name

Pull

The pull command can pull the code from a reference in the remote repository, as follows:

Git pull remote branch name

In fact, the essence of pull is fetch+merge, which first updates all the status of the remote warehouse locally, and then merges it. After the merge, the local branch will point to the latest node.

In addition, the pull command can also be merged through rebase, as follows:

Git pull-- rebase remote branch name

Push

The push command can push the local submission to the remote, as follows:

Git push remote branch name

If the direct push may fail, because there may be conflicts, so there is often a pull before the push, if there is a conflict to resolve locally. When the push succeeds, the local remote branch reference is updated to point to the same node as the local branch.

To sum up

Whether it is HEAD or branch, they are just references. Reference + node is the key to the distribution of Git.

Merge has a clearer time history than rebase, while rebase makes submissions more linear and should be used first.

You can view the corresponding code for each submission by moving HEAD.

Clone or fetch will keep all submissions and references from the remote warehouse in a local copy.

The essence of pull is actually fetch+merge, and you can also join-- rebase merges through rebase.

This is the end of the content of "what is the essence of Git instructions". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.