I like to start every blog post with an opening

Remember the first Git introduction? There are three features that Git itself agrees with

cheap local branching, convenient staging areas, and multiple workflows

Lightweight local branches, convenient staging, and multiple workflows. Branch is one of the most important features of Git, as it is a feature of multiple workflows. This blog, mainly with you to learn about light if a feather, handsome to burst the branch son.

The concept of the Branch

The concept of branching, in my opinion, comes in two versions:

In terms of usage scenarios, this is the concept

A branch of Git is a path to be taken in the development process. You can choose to take the same path with other partners or take the same path by yourself. The paths have no influence on each other, and as the master of the paths, you can merge the two paths at any time.

If you dig a little deeper, it’s this concept:

Git branches are essentially just mutable Pointers to commit objects, and this mutable pointer points to the end of the path. There is also a special HEAD pointer, which is used to record where you are working. To borrow from the example above, the HEAD pointer is equal to you walking on the road, where you are, the pointer to the branch you are in, the HEAD pointer to the branch.

In fact, when we use Git, we use the branch because Git’s default branch name is master. If you’re interested, you’ll notice that the output header of Git init is already in the master branch by default. However, at this point, the master branch is not created yet, and will only be created if there is a commit. The reason is that the pointer to the branch should point to the commit. Suddenly, I understand why every Android Studio tutorial has a preliminary commit.

No picture no truth, don’t believe the following:

Essential skills to play Branch

Branch commands are few and far between. Get a good grasp of these basic commands and you’ll be riding your horse down the Branch prairie

Create a branch

 git branch <name>
Copy the code

This command seems so simple that all you need to do is think of the name of the branch. But when creating a branch, think about whether you want to create a new branch based on the content of the current branch.

See the branch

Three commands, so you can look at whatever branch you want, and that’s how convenient it is, right

Git branch -r // Check the local branch-a// View all branches, local and remoteCopy the code

Delete the branch

When the local branch is deleted, the remote repository cannot automatically delete the remote branch after it is pushed to the remote repository (the reason is decomposed next time). Therefore, the complete deletion of a branch is divided into two parts, one local and one remote.

Local delete operations require the -d or -d parameter. The name of the parameter comes from the abbreviation for delete. Remember it so easy!

The difference is that -d is a little bit rougher than -d. If -d is used to delete a branch that has new content that is not merged, the branch will be directly deleted. If -d is used, the branch will prompt that there is new content that is not merged, and the branch will not be deleted. Delete need to be careful, it is recommended that in non-special circumstances, the use of gentle -D is better, so as not to shake a small hand, tears long flow.

 git branch -d<name> git branch -d <nameCopy the code

Deleting a remote branch requires a push operation.

git push origin :<name>
Copy the code

Renaming a branch

In fact, this is a false proposition.

But a lot of people, including me, have had the idea that they don’t like the branch name and they want to change it, so there’s this pseudo-proposition.

In fact, there is no renaming of branches. There is no such command as rename. If you don’t like the name and want to start over, simply create the same branch as the one you want to change, name it as you like, and delete the previous one.

Check out the branch

The word “check out” is a technical term for Git branches, and you can think of it as switching to the current branch. In essence, the checkout operation moves the HEAD pointer to the branch to be switched.

There are two use scenarios:

1. An existing branch, now to switch over.

 git checkout <name>
Copy the code

2. Create a new branch and switch to the new branch. To do this in one step, you need the -b parameter.

   Create a new branch based on the current branch

   git checkout -b <branch name>
   Copy the code

   Creates a new branch with the specified commit

   git checkout -b <branch name> <SHA1>
   Copy the code

Merging branches

These branches can be added, deleted, and checked independently, but Git creates branches not just for them to play with, but for them to work together. For example, when writing a project, you should divide the development tasks. You and your partner create two branches, you write your Anglela and he writes his baby. After the development is completed, they must be combined together to make Anglelababy. The action of merging involves the concept of merging branches.

The command used for branch merge is

git merge <branch name>
Copy the code

Branch merge is a bit more complicated than the other branch operations, but it is also a multi-branch operation, at least worthy of its high-end name, so I decided to make branch merge a major title.

A Branch merger is a big deal

Two merge modes in Git

Branch merging is very intelligent. Currently, there are two modes. We do not need to participate in the choice of the two modes. When I was using Git, sometimes I needed to input the commit information to execute branch merge, sometimes I didn’t need to input the commit information. As a little white, I didn’t know why, and later I realized that it was because of the merge mode.

The two modes are:

1. “Fast Forward” (PS: The name is official)
2. Recursive Strategy Merge (PS: Unofficial, my own name, sometimes called triple Strategy Merge)

• Fast Forward

As shown in the figure, there are two branches, the master branch and the feature branch. When the two branches are in the relationship above, a fast-forward occurs when a merge operation is performed.

The reason is; Because the commit that the master branch points to is directly upstream of the feature branch, Git simply moves the pointer forward. In other words, when you try to merge two branches, if go down a branch to another branch, so Git in together, will only simple pointer pushed forward (the pointer moves to the right), because there is no need to solve this case, the merging of differences – this is called “fast forward, fast – forward).

The position of the merged branch pointer is as follows:

• Recursive Strategy Merge

This combination is to supplement the fast-forward, because you know, in the process of project development, a lot of people in the development of the situation, there is not a lot of fast-forward, a lot of things like this. The commit history is forked and cannot satisfy the conditions for fast-forward execution:

Because the commit in the master branch is not a direct ancestor of the commit in the Feature branch, Git has to do some extra work. When this happens, Git does a simple three-way merge using the snapshots at the ends of the two branches (C4 and C5) and their working ancestor (C3) to generate a new commit (C6).

Have a practice run

It’s a lot of theories. I can’t even remember them. Here’s an example:

Git add. Git add. Git add -m'Add master file'// From the end of the master branch, create and switch the featureA branch and create a commit git checkout -b featureA touch a. TB git add. git commit -m'Add file A'Git checkout -b featureB touch b. checkout git add. Git commit -b featureB touch B. checkout git add'Add file B'

//切换 master 分支
git checkout master

//master 合并 featureA 分支
git merge featureA

//master 合并featureA 后再合并 featureB 分支
git merge featureB

Copy the code

The blogger doesn’t want to talk to you and is throwing a bunch of commands at you. Go ahead and tap, you’ll see two merge modes!

When the master branch merged With featureA, it was a fast-forward merger:

After the master branch merged With featureA and then merged with featureB, the fast-forward condition was no longer met and a three-way merge was triggered, resulting in a new commit. So, executing the Merge command takes us to the following page, which lets us edit the commit information for this new commit. The default commit information is “Merge branch ‘branch name'”. Press I to edit to submit information, :wq! Save the Settings and exit the page.

The following message is displayed after the merge is successful:

Draw the branch merge diagram of the small example above, as follows:

Peacefully resolve the Branch merger conflict

Where there are people, there are rivers and lakes; where there are branches, there are conflicts. Sometimes the merge operation does not go so smoothly. If you make different changes to the same part of the same file in two different branches, Git will not be able to merge them cleanly, resulting in conflicts.

As follows, add a sentence to the first line of the master.txt file, for master and For featureA, respectively, and then the two branches merge, resulting in a conflict.

In the conflict information, the conflict file is master.txt. You can also run the git status command to view detailed information about the conflict

If you encounter a conflict, git cannot automatically merge it. It is up to you to resolve the conflict manually.

1. View the conflicting files and modify the conflicting parts
2. To modify the conflicting files, rungit addoperation
3. Create a commit that modifies the conflict.

First know the idea, have a simple concept in mind, next, step by step carefully look ~

Step 1: View the conflicted file and modify the conflicted part

Git can’t solve the conflict, but it has helped us to the end. It uses three simple symbols to indicate the place where the conflict occurs and the contents of the two branches where the conflict occurs.

symbol	meaning
= = = = = = =	The separator
< < < < < < < HEAD to = = = = = = =	The contents of this place in the master branch
= = = = = = = to > > > > > > > featureA	This place is the content of the featureA branch

Next edit the master. TXT file, complete the merge, confirm, git conflict identifier to delete.

Step 2 & step 3: Modify the conflict file, add && commit

Branch rollback, there is regret road can go

In reality, there will be times when you will regret it. For example, every day when I am late, I will regret why I did not get up when the alarm clock rang the first time. But in this world, there is no way to regret. I can only try to get up early tomorrow.

However, Git does! Thanks to the magic of the reset and revert commands ~, both commands can be used to roll back. The difference between the two will be discussed later, but we’ll use reset here.

An early warning: Don’t forget to back up before you roll back.

Local branch rollback:

Determine which commit to roll back to, find the COMMIT ID for that commit, and execute the following command

git reset --hard commit id
Copy the code

Description The remote branch was rolled back

It’s still a false proposition. There is no rollback for remote branches. To achieve the effect of rollback, delete the previous remote branch and push the local branch that has been rolled back to the remote.

Git push origin :<name> git push origin :<name> git push origin <nameCopy the code

I’m used to having an end to every blog post

This post uses a lot of my prehistorical power and I hope it helps you understand the Git branch. Git series has started recently, see you in the next blog!

---