GitHub introductory tutorial-Git branch, merge and backtrack

Foreword:
In the previous article, the blogger told you some basic concepts of Git and some simple command usage. Today, the blogger of this article will tell you about some of Git that will be often used in our daily development. The command and how to use it, today I mainly talk about the concept of branching, as well as merging and backtracking. It is not long-winded here, directly today's topic;
follow a blog post on the topic

1. Branch

• Branching can be said to be a big mountain on the learning path of many small partners who are first exposed to Git. Many of them will stop after walking down the mountain. In fact, this concept is not difficult. As a programmer, branch should be familiar and difficult to imagine. If there is no branch in the programming world, we start with the first step of learning a programming language (print Hello word), and the second step is to learn the branch (if else), which can also be seen When it comes to the importance of branches, the same is true for branches in Git. Everything is the same. If you understand the basic principles and practices, it will be easy to learn this thing again.
• Let me first talk about why there are branches?
  • Let's first look at a problem taught in elementary school:
    get up for 2 minutes, steam rice for 10 minutes, brush your teeth for 2 minutes, wash your face for 3 minutes, and eat for 5 minutes. So how many minutes will it take you to finish everything in the end?
    Obviously The first is to get up, then steam the rice, while steaming the rice, we can brush our teeth and wash our face, and finally eat. That is to say, the steaming and washing are carried out at the same time. This is the parallel concept. This greatly shortens our time and improves our time utilization Rate, development is the same, we can also divide a development process into different stages (stages), and then predict the required execution time according to different stages, and then allocate tasks reasonably, because the technical industry specializes in each person's strengths. , We only need to arrange people who are suitable for this task to complete this task, so as to maximize the use of talents. These concepts are the knowledge of working directory decomposition (WBS)
  • Haven't understood the case after reading the case? Look at the picture:
    
    our task has always been a main task (master), and then these tasks will be split and decomposed into secondary tasks according to the needs, and then after the secondary tasks are completed, they will follow the main tasks. Merging, this is the idea in the Git branch;
• git branch display branch information
  This command is used to show which branches are under the current working tree, and which branch is currently on, we still enter the last newly created working directory. Execute this command to see :
  
  You can see that there is only one master branch in the current project. This branch is automatically created for us when the project's Git is initialized. Generally speaking, the version on the master branch is a stable version for release, and the version on the branch is used as To develop new functions, the * sign in front of the branch name indicates the current branch.
• git branch branch_name creates a new branch. The
  difference from the previous command is that we add a branch name of our own at the back, and a branch with that name will be created:
  
  we use the command to create a new branch named branch1 , And then checked all the branches in the current project, and you can see that there is one more branch we just created.
• git checkout branch_name Choose to switch branches.
  If we want to switch to another branch, we can use this command.
  
  We use the command to switch to the specified branch and check the branch situation again. You can see when * has jumped to the front of the newly created branch, indicating that we have switched This branch is here.
  
  We check the logs in the newly created branch and we can find that there is no difference between the logs on both sides, which means that the process of creating a branch is to copy the state of the current master branch into the new branch and try again Try adding another line to the REDEME.md file in the new branch
  
  !!! Note that I have to hit the blackboard here, there are a lot of commands, let me explain, we first add a line to the REDEME.md file in the branch1 branch Content, and then we submitted this operation in branch1, and then viewed the content of the REDEME.md file in branch1, and then switched to the master branch through the command, and checked the contents of the REDEME.md file in the master branch again to find out We can't see the changes in branch1 in the master branch, which means that the branches are independent.
• git checkout -b branch_name creates and switches to the target branch. After
  using the -b parameter, it will directly create and switch to that point. If the target branch exists, you will be prompted
  
  to see that it is more convenient to use this method. The method used to create the branch is the same.

2. Branch merger

• git merge
  because we want to record the merge when we merge, we also need to add the parameter "--no-ff", which will submit the merge to create a collection and record it in the log;
  
  from the figure As you can see, we first switched to the master branch, and then executed the command to merge with the branch1 branch. When this command is executed, an edit box will pop up for you to fill in the description of this submission, Ctrl + X can save and exit, Then this merge was submitted successfully, and then let's check the log.
  
  Here to check the log, we used a new parameter "--graph". As the name suggests, after adding this parameter, the log will be displayed as a graph, and we can see it on this To the process line of the project version, the lines at different positions represent different branches, and the overlap of the lines represents the merge operation of the branches.

Three. Back to the historical version

• git reset
  Everyone wants to have the ability to shuttle time, although you can not do in real life, but in Git You can be a real time travel are, where you are God, you are free to distort history , Some friends may ask why you have this ability, I will make an analogy here, you can imagine what happens in this world without Ctrl + z, it should be a mess, all your slave operations have to be on thin ice , Be careful, because you can't go back and you can only start again once you are wrong. Fortunately, Git is humane. As a powerful version tool, how can it tolerate such a situation, so it has the function of backtracking .But let’s take a look at what to do if we want to go back to branch1 when it was created. First of all, you have to remember the hash code in the log in the first article. Yes, it is the symbol of time, which is to open time and space. The key to travel. Let's see how to do it:
  
  We use'--hard' to specify the hash code value at the time point, and we change back to the time point at that time. After the execution, we will check the log and find that the submission after that point in time The incidents have all disappeared. Don’t worry, we have a way to go back.
  Let’s create a branch at the current point in time and try again:
  
  You can see that the file is still the content at that point in time, without a trace of change. Now we add another line of content to the REDEME.md file in the newly created branch and submit it for a try.
  
  There is no problem, everything is normal; now we want to go back to the original time point. What should I do, careful buddy I have found the problem. Didn't we start to say that the Hash code can be used as the key to shuttle at any time. Now the log we are viewing only shows the current time point, and there is no original operation log. What should we do? Maybe you have to take a screenshot and remember the Hash code at the time before going back. Hahaha of course...
  No, Git is a powerful version control tool. It must be considered at the beginning of the design. We only need one command. You can view all log information of the current warehouse
• The git reflog
  command can take you to view all the operation records. Take a look at the following use cases: After
  
  using this command, we can see all the operation records, including branch switching, etc., we find the time point of reset execution , We only need to switch to before this point in time, or use the previous reset command to transfer, in fact, only the first few Hash codes are needed, let's try it:
  Note that you have to switch to the master before proceeding Shuttle, otherwise you are advancing at the time of the current branch. Here the blogger forgot to cut the step chart for switching master, so pay attention!
  You can see that we have successfully returned to the original point in time. Let's try Try to merge the created branch_pre:
  
  Unfortunately, the merge was not successful. It prompts us that there is a conflict. Let us modify the conflicting file (README.md) and then submit it. Then let's see what the REDEME.md file becomes Look;
  you can see that it is very strange that it has become like this, ======= The above is the content of the current HEAD, and the following is the content to be merged, that is, the two lines have an error. In this case, we often only need to keep it The next line is fine, let's modify it once.
  
  You can see that we submit again after resolving the conflict, so that this merge is successful.

This is the whole content of this article, I hope it can help you, if you like this article, you may wish to use your little hand to like it before leaving! Thank you