git tool use -- branch management

git tool use – branch management

understanding branch

Branch management is one of Git's killer features. Branch: It is the parallel universe in science fiction. When you are learning C++ in front of the computer, another you are learning Java in another parallel universe. If the two parallel universes do not interfere with each other, it will have no effect on you now. At some point, though, the two normal universes merged, and as a result, you learned both C++ and Java.

In the version rollback, you already know that for each commit, Git strings them into a timeline, which can be understood as a branch. So far, in Git, this branch is called the main branch, which is masterthe branch.

Let's understand HEAD again. Strictly speaking, HEAD does not point to the submission, but points master,masterto the submission. Therefore, HEAD points to the current branch.

Every time you submit, masterthe branch will move forward once, so that as you continue to submit, masterthe line of the branch will become longer and longer, and HEAD mastercan point to the current branch as long as it keeps pointing to the branch.

We can use git log to verify:

[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/master
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
7804665c14faf8e894e023f04576ba6b17632f85
[Lxy@aliyun gitcode]$ git log
commit 7804665c14faf8e894e023f04576ba6b17632f85
Author: Lxy <2357246060@qq.com>
Date:   Mon Jun 26 13:48:27 2023 +0800

    delete file1

create branch

Git supports us to view or create other branches. Here we create our first branch dev. The corresponding command is:

View all current local branches

git branch

* indicates that HEADthe branch currently pointed to is mastera branch.

[Lxy@aliyun gitcode]$ git branch
* master

create new branch

git branch dev # 新建分支dev

[Lxy@aliyun gitcode]$ git branch dev
[Lxy@aliyun gitcode]$ git branch
  dev
* master

When we create a new branch, Git creates a new pointer called dev, after the creation is complete, we use it git branchto view the current branch.

Alternatively, new branches can be seen through the directory structure:

[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
├── dev
└── master

0 directories, 2 files
[Lxy@aliyun gitcode]$ ls .git/refs/heads/
dev  master
[Lxy@aliyun gitc

Discovery now dev和masterpoints to the same modification. And you can also verify that HEAD is currently pointing to master.

switch branch

Now that a new branch has been successfully created dev, how to switch to devthe branch for development? Switching can be done with git checkoutthe command:

[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ git branch
* dev
  master
[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/dev

At this point, HEADit has been pointed to dev, which means that we have successfully switched to devup! Next, devmodify ReadMethe file on the branch, add a line of content, and perform a commit operation.

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "modify ReadMe"
[dev 2690f7f] modify ReadMe
 1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ git status
# On branch dev
nothing to commit, working directory clean

Now that devthe branch's work is done, we can switch back to masterthe branch:

[Lxy@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

After switching back to masterthe branch, I found that ReadMethe new content in the file was gone! ! let's cut devback

[Lxy@aliyun gitcode]$ git checkout dev
Switched to branch 'dev'
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

On devthe branch, the content is still there, why does this phenomenon occur? Let's take a look at devthe branch and masterbranch pointing again, and find that the commits pointed to by the two are different:

[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
7804665c14faf8e894e023f04576ba6b17632f85

[Lxy@aliyun gitcode]$ git cat-file -p 2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
tree 68c0c174cb2cbb0258f1979bfa92ff0fe06ec5d6
parent 7804665c14faf8e894e023f04576ba6b17632f85
author Lxy <2357246060@qq.com> 1689396001 +0800
committer Lxy <2357246060@qq.com> 1689396001 +0800

modify ReadMe

Seeing this, we can understand, because we devsubmitted on the branch, and the submission point of the master branch has not changed at this moment, the state at this time is shown in the figure:

When you switch to masterthe branch, HEAD points to it master, and of course you can't see the commit.

merge branch

In order to mastersee new commits on the master branch, devthe branch needs to be merged into masterthe branch, as shown in the following example:

[Lxy@aliyun gitcode]$ git checkout master #切换到master上进行合并
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev # 合并dev分支
Updating 7804665..2690f7f
Fast-forward
 ReadMe | 2 ++
 1 file changed, 2 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe # 发现已经成功了
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

git mergeThe command is used to merge the specified branch into the current branch. After merging, masteryou can see devthe content of the branch commit.

[Lxy@aliyun gitcode]$ cat .git/refs/heads/master 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/refs/heads/dev 
2690f7fcf1ccc686ffd88d2780140d4cc1cd493f
[Lxy@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/master

The state diagram at this time is as follows:

Fast-forwardIt stands for "fast-forward mode", that is, it directly points masterto the current commit of dev, so the merge speed is very fast. Of course, not every merge can be done Fast-forward.

delete branch

After the merge is completed, devthe branch is useless for us, so devthe branch can be deleted. Note that if you are currently under a certain branch, you cannot delete the current branch , such as:

[Lxy@aliyun gitcode]$ git branch -d dev
Deleted branch dev (was 2690f7f).
[Lxy@aliyun gitcode]$ tree .git/refs/heads/
.git/refs/heads/
└── master

0 directories, 1 file

The state at this time is shown in the figure below:

Because creating, merging, and deleting branches is very fast, Git encourages us to use branches to complete a certain task, and then delete the branch after merging. This is the same as masterworking directly on the branch, but the process is safer.

merge conflict

However, in the actual branch merging, it is not possible to merge successfully if you want to merge. Sometimes we may encounter code conflicts. To demonstrate this problem, we create a new branch dev1, and switch to the target branch, we can use git checkout -b dev1one step to complete the action of creating and switching.

[Lxy@aliyun gitcode]$ git checkout -b dev1
Switched to a new branch 'dev1'
[Lxy@aliyun gitcode]$ git branch 
* dev1
  master

dev1Modify the file under the branch , ReadMechange the content of the file as follows, and make a commit:

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

I am Coding in dev1......   #新增内容
[Lxy@aliyun gitcode]$ git add .  #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe" 
[dev1 50ba571] md ReadMe
 1 file changed, 2 insertions(+)

Switch to masterand observe ReadMethe file content:

[Lxy@aliyun gitcode]$ git checkout master  #切换至master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git branch 	#查看当前所有分支
  dev1
* master
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

We found that after switching back, the content of the file became the old version again, which was in line with our expectation, and we can understand it now. At this time, on masterthe branch, we ReadMemake another modification to the file and submit it, as follows:

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!


i am Coding in master ......
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master a8d6985] md ReadMe
 1 file changed, 3 insertions(+)

Now, masterboth the branch and dev1the branch have their own new commits that look like this:

In this case, Git can only try to merge the respective changes, but such a merge may have conflicts, as shown below:

[Lxy@aliyun gitcode]$ git merge dev1 #合并dev1到master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun gitcode]$ git status  #查看当前状态
# On branch master
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#	both modified:      ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")

After finding ReadMea file conflict, you can directly view the file content. What I want to say is that Git will use <<<<<<<,=============,>>>>>>>>>>> >>> to mark the conflicting content of different branches, as shown in the following figure:

[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

<<<<<<< HEAD

i am Coding in master ......
=======
I am Coding in dev1......
>>>>>>> dev1

At this time, we have to manually adjust the conflicting code, and need to submit the modified result again (it is very important to submit again, don't forget)

[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[master 832d4a2] md ReadMe

The conflict is resolved here, and the state at this time becomes

You can also see the branch merge process with git log with parameters

[Lxy@aliyun gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   832d4a2 md ReadMe
|\  
| * 50ba571 md ReadMe
* | a8d6985 md ReadMe
|/  
* 2690f7f modify ReadMe
* 7804665 delete file1
* 2f86525 第三次修改ReadMe
* 02716a9 修改ReadMe
* 0c3e2b8 add file2
* cfd11ac add file
* 3b64204 add first file

Finally, don't forget that dev1the branch can be deleted after use:

[Lxy@aliyun gitcode]$ git branch
  dev1
* master
[Lxy@aliyun gitcode]$ git branch -d dev1
Deleted branch dev1 (was 50ba571).
[Lxy@aliyun gitcode]$ git branch
* master

branch management strategy

Usually when merging branches, Git takes Fast forwardthe pattern if possible. In this Fast forwardmode, after deleting the branch, when viewing the branch history, the branch information will be lost, and it is impossible to see whether the latest submission came mergein or was submitted normally.

But in the merge conflict part, we also see that by resolving the conflict problem, a new submission will be made, and the final status obtained is:

Then this is not Fast forwarda pattern. The advantage of this is that branch information can be seen from the branch history. For example, we have now deleted dev1the branch created in the merge conflict part, but we can still see masterthat it was actually merged by other branches:

[Lxy@aliyun gitcode]$ git branch #查看当前分支
* master
[Lxy@aliyun gitcode]$ git branch dev1 #创建dev1分支
[Lxy@aliyun gitcode]$ git checkout dev1 #切换到dev1分支
Switched to branch 'dev1'
[Lxy@aliyun gitcode]$ git branch 
* dev1
  master
[Lxy@aliyun gitcode]$ vim ReadMe  #修改ReadMe文件
[Lxy@aliyun gitcode]$ git add .   #提交修改
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev1 f41d236] md ReadMe
 1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ git checkout master #切换到master分支
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge dev1" dev1 #将dev1分支使用no-ff方式合并到master分支
Merge made by the 'recursive' strategy.
 ReadMe | 3 +++
 1 file changed, 3 insertions(+)
[Lxy@aliyun gitcode]$ cat ReadMe #查看ReadMe文件内容
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....


I am Coding in dev1..................
[Lxy@aliyun gitcode]$ git log --graph --abbrev-commit #查看日志信息
*   commit 9c17f2d
|\  Merge: 832d4a2 f41d236
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sun Jul 16 18:21:49 2023 +0800
| | 
| |     merge dev1 #这里能够看到合并的信息
| |   
| * commit f41d236
|/  Author: Lxy <2357246060@qq.com>
|   Date:   Sun Jul 16 18:20:46 2023 +0800
|   
|       md ReadMe
|    
*   commit 832d4a2
|\  Merge: a8d6985 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sat Jul 15 13:10:06 2023 +0800
| | 
| |     md ReadMe
| |   
| * commit 50ba571
| | Author: Lxy <2357246060@qq.com>
| | Date:   Sat Jul 15 12:59:18 2023 +0800
| | 
| |     md ReadMe
| |   
* | commit a8d6985
|/  Author: Lxy <2357246060@qq.com>
|   Date:   Sat Jul 15 13:05:11 2023 +0800
|   
|       md ReadMe
|  
* commit 2690f7f
| Author: Lxy <2357246060@qq.com>
| Date:   Sat Jul 15 12:40:01 2023 +0800

Git supports us to force the disabled Fast forwordmode, then mergea new one will be generated at the time commit, so that the branch information can be seen from the branch history.

Explain:

--no--ffThe parameter indicates the disabled Fast forwardmode. Fast forwardAfter the disabled mode will be merged and a new one will be created commit, so add -mthe parameter and write the description. After merging, you can view the historical branch:

git log --graph --pretty=oneline --abbrev-commit

Without using Fast forwarda pattern, mergethe post looks like this:

Therefore, when merging branches, --no-ffyou can use the normal mode to merge by adding parameters. The merged history has branches. It can be seen that the merge has been done, but the fast forwardmerge cannot be seen that the merge has been done.

branch strategy

In actual development, we should follow several basic principles for branch management:

First of all, masterthe branch should be very stable, that is, it is only used to release new versions, and we cannot usually work on it: therefore, we usually develop on the devbranch, that is to say, devthe branch is unstable, and at some point , For example, when version 1.0 is released, the devbranch is merged into masterthe above, and masterversion 1.0 is released on the branch.

Therefore, everyone has their own branch, and it is enough to merge to the dev branch from time to time. So the teamwork branch looks like this:

bug branch

If we are developing on a branch now dev2, halfway through the development, we suddenly find that masterthere is a bug on the branch that needs to be resolved. In Git, each bugcan be fixed by creating a new temporary branch, after the fix, the branch is merged, and the temporary branch is then deleted. But the current dev2code is generally developed in the workspace and cannot be submitted. Git provides git stashcommands to store the current workspace information, and the stored content can be restored at a certain time in the future.

[Lxy@aliyun gitcode]$ git branch dev2 #创建dev2分支
[Lxy@aliyun gitcode]$ git checkout dev2 #切换至dev2分支
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ vim ReadMe  #修改ReadMe文件
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadMe文件
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git checkout master  #切换至master
M	ReadMe
Switched to branch 'master'
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadMe文件
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git status  #查看状态
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
[Lxy@aliyun gitcode]$ git checkout dev2
M	ReadMe
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git stash #储存文件
Saved working directory and index state WIP on dev2: 9c17f2d merge dev1
HEAD is now at 9c17f2d merge dev1
[Lxy@aliyun gitcode]$ git status #再查看状态
# On branch dev2
nothing to commit, working directory clean
[Lxy@aliyun gitcode]$ cat ReadMe  #再次查看master的ReadMe文件内容发现恢复到之前
hello git
hello world
hello ReadMe

git --version

I am Coding in dev!

i am Coding in master ......
I am Coding in dev1.....


I am Coding in dev1..................

With git statusa view workspace, it is clean (unless owned - no files managed by Git), so branches can be confidently created to fix bugs.

After storing the dev2 workspace, since we are masterbranch-based, create a temporary branch to fix bugs.

[Lxy@aliyun gitcode]$ git checkout master #切回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git checkout -b fix_bug #新建并切换到fix_bug分支
Switched to a new branch 'fix_bug'
[Lxy@aliyun gitcode]$ vim ReadMe 
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am fixing bug .........             #修复bug
[Lxy@aliyun gitcode]$ git add .       #重新add commit
[Lxy@aliyun gitcode]$ git commit -m "fix bug"
[fix_bug 76fef0d] fix bug
 1 file changed, 1 insertion(+), 7 deletions(-)

After the repair is complete, switch to masterthe branch, complete the merge, and finally delete fix_bugthe branch:

[Lxy@aliyun gitcode]$ git merge --no-ff -m "merge fix_bug" fix_bug
Merge made by the 'recursive' strategy.
 ReadMe | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

git --version

I am fixing bug .........

So far, the bug fixing work has been done, we will continue to go back to dev2the branch for development, switch back to dev2the branch:

[Lxy@aliyun gitcode]$ git checkout dev2
Switched to branch 'dev2'
[Lxy@aliyun gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean

Workspace is clean? ? ? Where did our work site go just now? You can use git stash listthe command to view

[Lxy@aliyun gitcode]$ git stash list
stash@{
    
    0}: WIP on dev2: 9c17f2d merge dev1

The work site is still there. Git has stored stashthe content somewhere, but it needs to be restored. How to restore the site? We can use git stash popthe command to restore and stashdelete it at the same time:

[Lxy@aliyun gitcode]$ git stash pop
# On branch dev2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{
    
    0} (c6b7e92f49a38afc1461bcedbaa558aa7ecd0500)
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2............

When checking again, we have found that there is no scene to restore

[Lxy@aliyun gitcode]$ git stash list
[Lxy@aliyun gitcode]$ 

In addition, recovery can also be used on the recovery site git stash apply , but after recovery, stashthe content is not deleted, you need git stash dropto use it to delete. You can stash multiple times. When restoring, first use ``git stash list 查看，然后恢复指定的stash ，用命令git stash apply stash@{0}` to restore the code and then we can continue to complete the development. After the development is completed, we can submit it. For example:

[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2............
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 477994a] md ReadMe
 1 file changed, 1 insertion(+), 9 deletions(-)

But we have noticed that the contents of bug fixes are not dev2displayed on the website. The state diagram at this time is:

masterThe current latest commit of the branch is ahead of the commit of the branch dev2on which it was created. masterSo of course we dev2can't see the relevant code to fix the bug in . Our ultimate goal is to mastermerge dev2branches, so under normal circumstances we mastercan switch back to branches and merge directly, but this actually has certain risks. It is because there may be conflicts when merging branches, and code conflicts need to be resolved manually (on masterthe Internet). We cannot guarantee that conflicts can be resolved correctly at one time, because in practice projects, code conflicts are more than just one or two lines. Simple, there may be tens of hundreds of lines, or even more, and it is inevitable that mistakes will be made during the solution process, resulting in the wrong code being merged into the masterabove. The status at this time is:

A good suggestion to solve this problem is that it is best to merge the master on your own branch now, and then let the master merge dev. The purpose of this is that conflicts can be resolved and tested on the local branch without affecting the master.

The status at this time is:

The corresponding actual operation is displayed as: (It should be noted that the merge operation demonstrated below is not used --no-ff, but the above illustration is Fast forwardobtained after the mode is disabled, mainly for the convenience of explaining the problem.)

[Lxy@aliyun gitcode]$ git branch #查看当前分支
  dev1
* dev2
  fix_bug
  master
[Lxy@aliyun gitcode]$ git merge master  #合并master分支到dev2
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
[Lxy@aliyun gitcode]$ cat ReadMe  #查看代码
hello git
hello world
hello ReadMe

<<<<<<< HEAD
I am Codeing in dev2............
=======
git --version

I am fixing bug .........
>>>>>>> master
[Lxy@aliyun gitcode]$ vim ReadMe #修改代码
[Lxy@aliyun gitcode]$ cat ReadMe #再次查看
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........
[Lxy@aliyun gitcode]$ git add . #add 并且 commit
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev2 8bdc3c9] md ReadMe

So far dev2the above code does not need conflict resolution, we dev2can switch back to master and merge

[Lxy@aliyun gitcode]$ git checkout master  #切换回master
Switched to branch 'master'
[Lxy@aliyun gitcode]$ git merge dev2  #合并dev2
Updating ac63583..8bdc3c9
Fast-forward
 ReadMe | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
[Lxy@aliyun gitcode]$ cat ReadMe  #查看ReadME代码
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........
[Lxy@aliyun gitcode]$ git branch -d dev2 #删除dev2
Deleted branch dev2 (was 8bdc3c9).
[Lxy@aliyun gitcode]$ git branch -d fix_bug  #删除fix_bug
Deleted branch fix_bug (was 76fef0d).
[Lxy@aliyun gitcode]$ git branch -d dev1  #删除dev1
Deleted branch dev1 (was f41d236).
[Lxy@aliyun gitcode]$ git branch 
* master

delete temporary branch

In software development, there are always endless new functions to be added continuously. When adding a new feature, you definitely don't want to mess up the main branch because of some experimental code, so every time you add a new feature, it's best to create a new branch, which we can call As feature a branch, develop on it, after completion, merge, and finally, delete the featurebranch. However, if we are featurehalfway developing on a certain branch today, the product manager suddenly stops, saying that we want to stop the development of new functions. Although it is dry, this featurebranch must be destroyed on the spot, leaving it useless. git branch -dAt this time , it is not feasible to use the traditional command to delete the branch. The demonstration is as follows:

#新建并且切换到dev3分支
[Lxy@aliyun gitcode]$ git checkout -b dev3 
M	ReadMe
Switched to a new branch 'dev3'
#开始开发新功能并提交
[Lxy@aliyun gitcode]$ vim ReadMe  
[Lxy@aliyun gitcode]$ cat ReadMe 
hello git
hello world
hello ReadMe

I am Codeing in dev2.........
git --version 
bug is fixed .........

hello dev3
[Lxy@aliyun gitcode]$ git add .
[Lxy@aliyun gitcode]$ git commit -m "md ReadMe"
[dev3 00a37ca] md ReadMe
 1 file changed, 2 insertions(+)
 
 #此时新功能叫停
 #切回master准备删除dev3
[Lxy@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
#常规删除dev3分支时失败
[Lxy@aliyun gitcode]$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.

It is not possible to directly use the traditional method of deleting branches. According to the prompt, there is the following method:

[Lxy@aliyun gitcode]$ git branch -D dev3
Deleted branch dev3 (was 00a37ca).
[Lxy@aliyun gitcode]$ git branch
* master

Summarize

What is the use of branching in practice? Suppose you are going to develop a new function, but it takes two weeks to complete. You wrote 50% of the code in the first week. If you submit it immediately, because the code has not been written yet, the incomplete code base will prevent others from working on it. alive. If you wait until all the code is written and submit again, there is a huge risk of losing your daily progress.

Now that there are branches, there is no need to be afraid. You create a branch that belongs to you, others cannot see it, and continue to work normally on the original branch, while you work on your own branch, submit it as you want, until the development After completion, merge it to the original branch again, so that it is safe and does not affect other people's work.

And no matter Git creates, switches and deletes branches, Git can complete it within 1 second! It doesn't matter whether your version library is 1 file or 10,000 files.

(End of this article)