Git分支实战入门详细图解

Posted velscode

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Git分支实战入门详细图解相关的知识,希望对你有一定的参考价值。

现在我们模拟一个简单的分支和合并案例,其中工作流可供真实项目借鉴。

(1)在master开展工作
(2)为新的需求创建分支
(3)在新的分支上展开工作
这时,你接到一个电话,说项目有一个严重的问题需要紧急修复。你随后会这样做:
(4)切换到你的生产环境分支
(5)创建新的分支来进行此次问题的热修补工作
(6)通过测试后,合并热修补分支并推送到生产环境中
(7)切换回之前的需求分支上继续工作

基本的分支操作

首先,假设你在所工作的项目上已经完成了一些提交

$ git log --oneline --decorate --graph --all
* 5d55df0 (HEAD -> master) 先前的工作2
* 36228f1 先前的工作1

技术图片

这时,你决定在工程中加入功能模块B,所以你创建了一个分支mod-b

$ git checkout -b mod-b
Switched to a new branch ‘mod-b‘

D:\\Git\\t2 (mod-b -> origin)

技术图片

接下来你继续工作,进行了新的提交。这么做会让mod-b分支指针向前移动。

$ git log --oneline --decorate --graph --all
* b52c200 (HEAD -> mod-b) 创建了模块B
* 5d55df0 (master) 先前的工作2
* 36228f1 先前的工作1

技术图片

现在,你接到一个电话,说项目有个问题需要立即被修复。如果没有Git的帮助,你需要先取消所有针对模块B所做的修改,然后部署补丁。如今你要做的就是切换回master分支即可。

$ git checkout master
Switched to branch ‘master‘

D:\\Git\\t2 (master -> origin)

此时项目的状态就和你开始处理模块B之前一模一样了,你可以集中精力制作补丁了。我们接下来创建一个补丁分支fix,并展开一些工作提交。

$ git checkout -b fix
Switched to a new branch ‘fix‘

$ git commit -a -m "修补了线上的问题"
[fix 130f52e] 修补了线上的问题
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fix.txt

现在我们再查看一下分支结构

$ git log --oneline --decorate --graph --all
* 130f52e (HEAD -> fix) 修补了线上的问题
| * b52c200 (mod-b) 创建了模块B
|/
* 5d55df0 (master) 先前的工作2
* 36228f1 先前的工作1

技术图片

现在你确定这个补丁准确无误,将其合并到master分支

$ git checkout master
Switched to branch ‘master‘

$ git merge fix
Updating 5d55df0..130f52e
Fast-forward
 fix.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fix.txt

注意到,合并过程出现了fast-forward提示。由于当前所在master分支所指向的提交是要并入fix分支的直接上游,因而Git会将master分支指针向前移动。换句话说,当你试图合并两个不同的提交,而顺着其中一个的提交的历史可以直接到达另一个提交时,Git就会简化合并操作,直接把分支指针向前移动,因为这种单线历史不存在有分歧的工作,这就叫做fast-forward

现在,我们的分支是这样的

$ git log --oneline --decorate --graph --all
* 130f52e (HEAD -> master, fix) 修补了线上的问题
| * b52c200 (mod-b) 创建了模块B
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1

技术图片

问题修复完毕,你准备回到之前被打断的工作上去,继续优化你的模块B。再此之前,先别急,首先把已经不需要的分支fix删除,该分支和master分支指向的位置相同。使用git branch-d选项来删除这个分支

$ git branch -d fix
Deleted branch fix (was 130f52e).

现在,回到mod-b分支,优化模块B

$ git checkout mod-b
Switched to branch ‘mod-b‘

# 对B模块做了一些优化

$ git commit -a -m "优化了模块B"
[mod-b 65f2937] 优化了模块B
 1 file changed, 1 insertion(+), 1 deletion(-)

看现在的分支

$ git log --oneline --decorate --graph --all
* 65f2937 (HEAD -> mod-b) 优化了模块B
* b52c200 创建了模块B
| * 130f52e (master) 修补了线上的问题
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1

技术图片

值得注意的是,mod-b分支不包含你在fix上做过的工作。如果需要把上述修补工作并入mod-b,就需要执行git merge master使得master分支合并到mod-b分支中,或者把mod-b分支合并入master分支。

基本的合并操作

现在模块B的工作已经完成,可以合并会master分支了。这次合并操作实现起来与之前合并fix分支差不多

$ git checkout master
Switched to branch ‘master‘

$ git merge mod-b
Merge made by the ‘recursive‘ strategy.
 b.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 b.txt

这次合并看起来有点不一样。这次合并中,开发历史从某个早先的时间点开始有了分叉。由于当前master指向的提交并不是mod-b的直接祖先,因而Git必须要做一些额外的工作。本例中,Git执行的是简单的三方合并。三方合并操作会使用两个待合并分支上最新提交的快照,以及这两个分支的共同祖先的提交快照。
技术图片

与之前简单的向前移动分支指针不同,这一次Git会基于三方合并的结果创建新的快照,然后再创建一个提交指向新建的快照。这个提交叫做合并提交合并提交的特殊性在于,它拥有不止一个父提交

$ git log --oneline --decorate --graph --all
*   9a219d6 (HEAD -> master) Merge branch ‘mod-b‘
|| * 65f2937 (mod-b) 优化了模块B
| * b52c200 创建了模块B
* | 130f52e 修补了线上的问题
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1

技术图片

以上是关于Git分支实战入门详细图解的主要内容,如果未能解决你的问题,请参考以下文章

ELK实战,Linux版docker安装ElasticSearchES-headLogstashKiabana入门,无坑详细图解

GitGit 分支管理 ( 克隆远程分支 | 克隆 master 分支 git clone | 查看远程分支 git branch -a | 克隆远程分支 git checkout -b )(代码片段

GitGit 分支管理 ( 克隆远程分支 | 克隆 master 分支 git clone | 查看远程分支 git branch -a | 克隆远程分支 git checkout -b )(代码片段

图解 Git 基本命令 merge 和 rebase

解答了解Git详细介绍 -入门到实战万字篇后续。。

Git详细介绍 -入门到实战万字篇(上)