preface

In the previous article, we learned a little bit about repositories and commits. In this article, we’ll learn about Git Tag, Git Branch, Git Checkout, and Git Merge. The following describes the functions of several commands:

  • usegit tagYou can tag specific submissions. Tags are additional tags submitted to indicate useful information.
  • usegit branchYou can create branches. Different functions for parallel development projects. Without getting confused about which commits belong to that feature.
  • usegit checkoutYou can switch between different branches and labels.
  • usegit mergeChanges on different branches can be merged together automatically

The label

Let’s start with the simplest tag.

Let’s say we have committed A, B, C, and D to the repository. The last commit, D, marks version 1.0 of our project. How do you point this out in Git? You might think that we could say in the D submission that this is our version 1.0. But that’s not ideal. Git, like other version control systems, provides the ability to Tag commits. That means we can tag the D submission. As follows:

Tags generally indicate important node information.

Even if more commits are added to the repository (in the figure below, we assume that E, F, and G are committed after D commits), the Tag still locks a commit as follows:

Since tags are so important, let’s take a look at creating tags in Git. There are two types of tags in Git: lightweight tags and annotation tags.

  • Lightweight tags in Git don’t store any information, just a reference to a specific commit.
  • The annotation tag is stored in Git data, and the annotation tag contains the name of the tag maker, email, date and other information. Generally, we use the annotation tag.

Create lightweight labels

The way to create lightweight tags is very simple using git tag+ tag name. As follows:

Git tag v1.0.0Copy the code

Create an annotation label

Creating an annotation label is very simple. You need to add option -A to the way you create a lightweight label. As follows:

git tag -a v1.0.0
Copy the code

In this way, Git will run your configured text editor to enter tag information. As follows:

In the image above, I configured Sublime Text, but you can also configure your favorite editor using git config –global core.editor.

In addition to creating annotation tags in this way, you can also specify the information stored in the tags using the -m option. If you add the -m option, Git will bypass your configured editor. As follows:

git tag -aV1.0.0 -m"Release new version V1.0.0"
Copy the code

Difference between lightweight label and note label

Git show > git show > git show > git show > Git show > Git show > Git show > git show

By using git show v1.0.0, you can see that the command line output contains the Tag information:

Tag v1.0.0 Tagger: AndyJennifer <[email protected]> Date: Sun Sep 15 18:20:28 2019 +0800 Release v1.0.0Copy the code

The lightweight label created does not contain this information, as shown below:

Note that the label created is always bound to commit. For example, in the image above, the tag points to 441796… This is submitted.

Tag deletion

Git tag -d

to delete a local tag, use git tag -d

. For example, use the following command to delete labels:

git tag -dV1.0.0 does tag'v1.0.0' (was 3132ff5)
Copy the code

The -d option indicates delete.

Add labels to previous commits

By running Git tag -a v1.0.0, we can tag the most recent commit, but what if you want to tag a long time ago commit in the repository? Very simple! We can add the SHA of the commit from the previous command.

Run the git log command to view historical commit records. Here we can provide the full SHA, or the first seven characters of SHA,

git tag -aV1.0.0 abd12d0Copy the code

In the above command, we labeled the commit abd12d0.

branch

In Git, branching is like a parallel world out of a science fiction movie. Each parallel world operates in its own environment, and under normal circumstances, what is done in each parallel world is imperceptibly and has no effect on the real world or the other parallel world. In some special cases, parallel worlds may overlap with the real world, and chaos and conflict can result. Then it is up to us to solve these conflicts and problems.

Branching in Git is primarily used to develop projects or make modifications to projects. Because all changes are made in the branch, they do not affect the project (the project is usually on the main branch, usually the master branch). When we make changes in a branch, we can merge the contents of the branch into the branch. This branch composition process is called merge. We’ll talk about all of this later.

So let’s take a look at how branches are used and the important concepts in Git.

Master branch and HEAD pointer

In the repository below, we create some commits and create a label named V1.0 in commit D that contains a hidden master branch in addition to the label. Git will create a branch called Master for us if we don’t have one. The master is essentially a pointer.

There’s nothing special about master, it’s just the first default branch name.

As we continue to make commits to the repository, they are added to the branch. The master pointer also points to the commit. As follows:

In the figure above, the MASETR pointer moves as it is committed. The commits connected by the red line in the figure belong to the Master branch.

In contrast to a Tag, the branch pointer does not permanently point to a commit, but moves as the commit moves.

Pointer to the HEAD

In some cases, we might create another branch. In the figure below, we create another branch branch1.

If we make another commit at this point, which branch will move? Is it the master branch or branch1 branch? Here’s another point —-> HEAD pointer.

In Git, HEAD always points to the currently active branch. The default is to point to the master branch if you don’t switch branches. As shown in the figure below.

Because the current HEAD pointer points to the Master branch, when we submit another I commit object to the repository, the commit will still be on the Master branch. As follows:

Git checkout is the branch to which the HEAD pointer points. Git checkout is the branch to which the HEAD pointer points. For example, we can use git checkout branch1 to point the HEAD pointer to branch1.

When we switch branches to Branch1, our subsequent commits are added to the Branch1 branch. For example, if we create another A commit, the Branch1 branch pointer will point to that commit.

Visibility of commits in branches

Note that commits in a branch are not visible to other branches.

In the figure above, if we are currently switching to the Master branch, the changes to the files committed by A on branch1 and J on Branch2 will not appear in any files on the Master branch in our working directory and file system. If we need to see the two corresponding file changes, we can simply switch to the branch where we want to find the commit.

Now that we are familiar with the concepts of branching and the overall process, let’s learn how to use the commands.

Create a branch

Creating a branch is as simple as using Git branch + branch name. If you want to create a branch called “branch1”, simply run the following command:

git branch branch1
Copy the code

It is important to note that if you create a branch on a commit, all commits before the commit belong to the branch1 branch. In the following figure, D, E, F, and G before commit H belong to the Branch1 branch.

The branch1 branch is shown in blue.

The previous commit adds the branch

Of course, as with creating labels, we can also add branches to previous commits. In the following command, we create the test branch in SHA’s commit for DFS14fo.

git branch test dfs14fo
Copy the code

Switch branch

To switch to another branch, use the git checkout command. For example, if you want to switch to branch dev, you can use the following command:

git checkout dev
Copy the code

The HEAD pointer points to dev. Note that when you switch branches, all files referenced by the commit in the dev branch will be removed from your working directory, as well as files referenced by the commit in the dev branch. Of course you don’t have to worry about actually deleting files on your other branch. Git stores them all in a repository. When you switch back, the file referenced by the branch will be displayed in your working directory.

View of branches

If you need to see the branches of your current project, you can use the Git branch command to see not only the branches that have been created in the repository, but also the branches that are currently active, to which the HEAD pointer points.

In the figure below, the asterisk (*) marks the currently active branches.

View all branches

Using the Git branch command, we can only see the branch that is currently active. If our project has different branches and we want to see all branch submissions, what do we do? Remember the Git log directive we mentioned earlier, where we added the –graph and –all options.

  • --graphOptions: Add entries and lines to the far left of the output.
  • --allOption: Displays all branch information in the repository.

Then we can use the following command:

git log --oneline --graph --all
Copy the code

— Oneline can omit the date, author, and other information in commit. Display the COMMIT information in its simplest form.

With this command, we can view all branches and commit information in the repository:

Branches deleted

In the previous article, we mentioned that branches are generally used to do development or make modifications to a project. When we merge the changes of the branch into the master branch, we may no longer need the branch. Git branch -d + branch name git branch -d + branch name Here we use the dev branch as an example:

git branch -d dev
Copy the code

When deleting branches, we need to pay attention to the following two points:

  • If we already usegit checkout devCommand switch todevOn the branch, then we can’t delete itdevThe branch. We need to switch to another branch to delete it.
  • ifdevIf there are any commits on the branch, pass-dThe option cannot delete the branch, you need to use uppercaseDOption, which is to usegit branch -D dev.

merge

The main purpose of a branch is to allow us to make changes that don’t affect the master branch. When we make a change on a non-master branch, we can delete the branch if we don’t feel we need the change, or you can merge the content on the branch with other branches.

The act of combining branches together is called a merge.

Use Git merge to merge branches in Git:

git merge <other-branch>
Copy the code

There are two types of merge in Git. One is plain merge, and the other is fast-forward merge. Let’s take a look at these two types of merging.

Ordinary merger

Let’s say our project has these two branches, master and branch1.

At this point we want to merge Branch1 on the master branch. Since HEAD currently points to the Master branch, when the two branches merge, a merge commit B will be generated and placed on the Master branch, and the master pointer will move forward. As follows:

Note that submission B links to submission 4 and submission A in Branch1. At the same time, when branches are merged, the previous branches are not affected. For example, we can still switch to branch1 and create a new commit J, as shown below:

Fast forward to merge

Suppose our project has these two branches, master and branch1. And branch1 comes before the master branch. As follows:

The commit (I,K,2) in Branch1 is not included in the master. If we want to merge these commits into the master branch, we need to merge the Branch1 branch into the Master branch. Git merge branch1 when we use git merge branch1 on the master branch, because branch1 precedes the master branch, Git does a so-called fast-forward merge. As shown below:

In the figure above, the Master branch moves to the COMMIT that branch1 points to. It is important to note that a fast-forward merge does not create another commit like a normal merge.

Merge conflicts

Most of the time, you can merge branches successfully, but in some cases Git doesn’t merge automatically, and when a merge fails, it’s called a merge conflict. When conflicts occur, we need to manually repair the conflicts in the file. Look at the following example:

In this example, we have created a repository named GitTestProject, where we have added a general.md file named Jvm family to the repository, as shown below:

The general catalog of the Jvm family. Md file contains the following contents

At this point we create the dev branch with git branch dev command and switch to the dev branch. At this point we add the content in the red box below.

Note that you need to use Git Branch frequently to see active branches

After modifying the file and saving it, we can check the current repository status using git status, and then commit the changes on the dev branch. The content is as follows:

We added a Java Class file format to the original file. Git checkout Master > git checkout Master > Git checkout Master > Git checkout Master > Git checkout Master > git checkout Master

Also, after we make our changes, we commit the changes on the Master branch. The content is as follows:

Git merge dev: merge dev: merge dev: merge dev: merge dev: merge dev

When using git merge, you must be aware of the branch you are currently in. You can view this by using git branch or git status.

In the figure above, Git tells us that there is a conflict in the.md directory of the Jvm family of files. When we open the file again, we might see something like this:

In this file, some special symbols are displayed. These symbols are actually merge conflict indicators defined by Git. These indicators are described below:

  • <<<<<<< HEADEverything below this line (up to the next indicator) shows the line on the current branch
  • = = = = = = =Represents where the content of the original line ends, and all subsequent lines (up to the next indicator) are the contents of the line on the current branch that was merged
  • >>>>>>> devIs the end-of-line indicator on the branch to be merged (in this case, the dev branch)

Note that a file may have merge conflicts in multiple parts, so checking for merge conflict indicators throughout the file and searching for <<< can help you find all of them.

When a conflict occurs, we need to manually remove these indicators. In this case, we want to keep the content submitted by both branches, so we can do as follows:

Note: Since the dev branch and the master branch modify the same file, the commit in the above example is a normal merge, and a new commit is required because of the type of merge we described above.

Of course, when we resolve the conflict, we still need to add the changes to the staging area and commit them. As follows:

When the commit is complete, we can use git log to see our commit record.

In the above commit record, we can see that the master branch contains not only the commit on the dev branch, but also a merge branch commit (merge branch ‘dev’).

IntelliJ IDEA or Android Sutdio graphical interface use

Finally, we return to the familiar process of using graphical interfaces. Let’s take a look at what IDEA offers us.

The creation of the Tag

Go to Version Control -> Log at the bottom of the compiler, select commit where we want to create the Tag, right click, select New -> Tag, and enter the name of the Tag you want to enter, as shown below:

After the Tag is successfully created, there is a gray label in the commit record.

The deletion of the Tag

Deleting tags is also very easy. In Git commit, click Commit containing the tags we created, then right-click anywhere, and choose tag name -> Delete. You can delete the tag. The details are as follows;

Branch creation

In IntelliJ IDEA or Android Sutdio, there are about three places to create branches. Let me tell you where they are and what the difference is between them.

The first way

In the compiler, just go to VCS->Git->Branches on the toolbar to create Branches.

After doing this, the following selection box will pop up, and you can create a Branch by selecting the New Branch option.

The following is a brief introduction to the contents of the selection box:

  • New Branch: Creates a New Branch.
  • Checkout Tag or Revision… : Switches to the appropriate Tag or branch.
  • Local Branches: All Local Branches.
  • Branches: Remote Branches. (More on remote branches later).

Note that branches are created this way. The commit to which the branch pointer points is the latest commit for your branch!!!! .

The second way

The second way to create a branch is by clicking on Git:master in the bottom right corner of the compiler. Here we use the master branch as an example to create a branch.

A branch created in this way. The branch pointer points to Commiit, which is the latest commit for your branch!!!! .

The third way

By clicking Version Control->Log at the bottom of the compiler in turn, then selecting Commmit where we want to create the Branch, right clicking on the mouse button, and selecting New ->Branch

For branches created in this way, the commit to which the branch pointer points is the commit you selected.

Branch deletion

Deleting branches is also easy. Go to Version Control->Log at the bottom of the compiler, then find the commit that has branches, right click, find the name of the branch you want to delete, and select Delete. Here, delete branch fiX-23 as an example:

Merging of branches

Merging branches is equally simple.

  • Or we can just go to the toolbarVCS->Git->BranchesThe following selection box pops up,
  • Or by clicking on the compilerThe lower right cornertheGit:master(The content in the lower left corner may change, for example, if you switch todevOn the branch, so this time it’s going to beGit:dev)

Then we can select the corresponding branch to merge under the corresponding branch, for example, we use the master branch to merge with the dev branch:

In the figure above, we can simply select Merge into Current. Note that when we select Merge branches, we need to switch to the correct branch.

Branch switching

How do I switch branches? When we select the Dev branch, we have a Checkout option on the right. By clicking this option, we can switch to the branch

Resolve the conflict

When the merge branch conflicts, the compiler will prompt us to merge the conflict, and the following code box will pop up:

The entire code block is divided into three parts:

  • The left (Left) Your version: represents changes on your current branch.
  • (on the rightRight) Change from branch: represents your merged branch.
  • In the middle of theResultRepresents the processed content.

The code colors for the content area are divided into four parts:

  • Red: represents the content edited by both the current and merged branches, which is a conflict
  • Blue: represents content that has been unilaterally edited, which is a change.
  • Gray area: indicates the deleted content, which is a change.
  • Green area: indicates the new content, which belongs to the change.

For both conflicts and changes, we can use the >> buttons on the left or right to apply the changes you want to apply, and if you don’t want to apply the changes you can use the X button. Eventually all of your actions will be applied to the middle Result code.

After all conflicts have been resolved and all changes have been applied. We can click the Apply button to complete our final merge.

You can also click the Accept Left or Accept Right button to apply content from the current branch or from other branches. This depends on your immediate practical needs.

Deep learning: Check out the official presentation in IntelliJ IDEA: Resolve Conflicts

tip

If you accidentally hit the Abort button when merging Conflicts, don’t worry; you can still right click and select the Git -> Resolve Conflicts option in order to Resolve Conflicts. As follows:

The last

Standing on the shoulders of giants, can see further ~

  • Git- Branch – Branch introduction