I am participating in the recruitment of the creator signing program of the Nuggets Technology Community, click the link to register and submit .
Git's killer feature is that it brings lightweight branches. If you use svn branches, you will be shocked by how fast Git can create and switch branches.
Operating branches are very frequent in Git. Learning branch operations is the foundation of learning Git. However, in actual work, I found that many students are not familiar with Git branch operations. The Git branching model behind the command.
master branch
After creating a new project in Git, there is a branch by default, that is, the main branch. The main branch generally represents the stable version of the project. The main branch should contain stable and bug-free code and maintain a state that can be released at any time. For small projects, only one main branch is enough. Every time we submit, a commit will be created. node.
$ git commit -m "c1"
$ git commit -m "c2"
$ git commit -m "c3"
The above command will create three commit nodes. At this time, the master branch is shown in the following figure:
The main branch should only be packaged, merged and submitted, and all iterations should be carried out on the branch. If it is a simple change, it is also possible to modify it directly on the main branch. If the function is complex and requires multiple submissions, it is not recommended to use the main branch. Modify directly.
feature branch
When there is a new feature to be developed, a new feature branch should be created, and the command is as follows:
$ git checkout -b feature/a
Next create two commits on the branch with the following commands:
$ git commit -m "c4"
$ git commit -m "c5"
At this point the commit tree looks like this:
When the development of the feature branch is completed, it needs to be merged back to the main branch. There are two options for merging back to the main branch, fast merge and non-quick merge. The difference between the two is whether to create a commit node. The command is as follows:
$ git merge feature/a # 快速合并
$ git merge --no-ff feature/a # 非快速合并
The result of the quick merge will directly point the master to feature/a, as shown in the following figure:
The result of a non-fast merge will create a merge commit node on the master, as shown in the following figure:
Both merging methods are available. If you choose to merge quickly, you need to ensure that each commit is independent and complete. If it does not meet the requirements, Git supports modifying the commit history, which needs to be modified and merged again.
You can use the rebase command to modify the history. The following commands can modify the last three commits, change the pick of the second commit to squash, merge the first and second commits, and change the pick of the third commit to edit, The commit information for the third commit can be modified.
$ git rebase -i HEAD~3
pick d24b753 feat: update ci
squash f56ef2f feat: up ci
edit 6c91961 feat: up
# Rebase 50ece5c..6c91961 onto 50ece5c (3 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
After the current branch is created, the master branch may have new commits, as shown in the following figure:
在合并之前，建议先将主分支新的提交合并到当前分支，有两种策略可以选择，合并和变基，合并操作更简单，变基操作提交树更清晰，建议使用变基的方式。
先来看下合并操作的过程，命令如下：
$ git merge master
$ git checkout master
$ git merge feature/a
合并操作后的提交树如下图所示：
变基会修改feature/a的历史，就像 feature/a 是在 master 之后开发的一样，变基命令如下：
$ git rebase master
$ git checkout master
$ git merge feature/a
变基操作后的提交树如下图所示，虚线的提交是feature/a变基之前的状态，在变基后，虚线的提交不再有分支指向，但并不会删除，而是变成Git中的游离节点，在Git执行GC（垃圾清理）操作后，节点才会彻底删除。
故障分支
如果发现存在 Bug，要尽快修复，此时可以基于主分支新建故障分支，命令如下：
$ git checkout -b bugfix/b
当验证没问题后，故障分支需要合并回主分支，并在主分支上发布新的补丁版本，命令如下：
$ git checkout master
$ git merge --no-ff bugfix/b
# 测试 构建 打标签 发布到npm
主分支更新后，下游的公共分支要及时同步变更，建议使用变基进行同步，命令如下：
$ git checkout feature/a
$ git rebase master
故障分支模型如下图所示，bugfix/b 分支合并到 master 后，feature/a 分支进行了变基操作。
标签与历史
每次发布新版本时都要打标签，版本号需要符合第四章介绍的语义化版本规范，一般功能分支发布次版本号，故障分支发布修订版本号，使用Git添加tag的命令如下所示：
# 假设当前版本是 1.1.0
$ git tag 1.1.1 # 修改次版本号
$ git tag 1.2.0 # 修改主版本
Git 的版本号，还可以添加 v 前缀，两种风格都可以，建议在一个项目里面保持统一，添加v前缀的版本示例如下：
# 假设当前版本是 v1.1.0
$ git tag v1.1.1 *# 修改次版本号
$ git tag v1.2.0 *# 修改主版本号
添加标签后，提交树示例如下图所示。
现在假设最新版本是 v1.2.0 了，突然用户反馈了 v1.0.0 版本存在 bug，如果是比较小的问题，一般我们会建议用户升级到最新版本 ，但如果用户不能升级怎么办，比如 1.x 到 2.x 存在大版本变化。
出于各种原因，存在需要维护历史版本的需求，对于还有用户使用需求的历史版本，需要提供 bug 修复的支持。
此时创建的标签就起作用了，可以基于标签新建一个版本分支，并在版本分支上修复 bug，且发布新的版本，历史版本分支，不需要再次合并回主干分支，创建标签分支的示例如下：
$ git checkout -b v1.0.x v1.0.0
此时历史分支的示例如下图所示。
总结
This article introduces the common branch commands and branch models of Git, hoping to help you better grasp the principles of Git. If you think this article is helpful to you, please like and follow the author. If you have any questions about this article, welcome to Exchange in the comments.
In addition, the author maintains a lot of good open source projects on GitHub, welcome to watch: github.com/yanhaijing