【Git学习笔记】Git分支管理策略及其结构原理分析

🔥个人主页：大白的编程日记

🔥专栏：Git学习笔记

---

前言

哈喽，各位小伙伴大家好!今天开始我们就进入新的篇章——Git学习！。今天我们来讲一下Git初始及其结构原理分析。话不多说，我们进入正题！向大厂冲锋

一.合并冲突

可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。

b dev1 -步完成创建并切换的动作，示例如下:
为了演示这问题，创建一个新的分支 dev1，并切换至目标分支，我们可以使用 git checkout

qcj@139 - 159 - 150 - 152:~/ gitcodes git checkout
- b dev1
Switched to a new branch 'dev1'
qcje139 - 159 - 150 - 152 : ~/ gitcodes git branch
* dev1
master

在 dev1分支下修改 ReadMe文件，更改文件内容如下，并进行一次提交，如

qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello versionl
hello version2
hello version3
write bbb for new branch
# 将 aaa 该为 bbb
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add .
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"modify ReadMe"
Idev1 0854245]modify ReadMe
1 file changed, l insertion(+), l deletion(-)

切换至 master分支，观察 ReadMe 文件内容:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch 'master
qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello versionl
hello version2
hello version3
write aaa for new branch

我们发现，切回来之后，文件内容由变成了老的版本，这种现象很正常，我们现在也完全能理解。

此时在 master 分支上，我们对 ReadMe 文件再进行一次修改，并进行提交，如下

qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch
dev1
* master
qcj@139 - 159 - 150 - 152:~/ gitcode$ vim ReadMe
qcj@139 - 159 - 150 - 152:~/ gitcode$
cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch
qcje139 - 159 - 150 - 152:~/ gitcode$ git add
qcje139 - 159 - 150 - 152 : ~/ gitcode$ git commit - m"modify ReadMe"
c10f6d0] modify ReadMe
[master
1 file changed,
l insertion(+), 1 deletion(-)

现在， master 分支和 dev1分支各自都分别有新的提交，变成了这样

这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git merge devl
Auto - merging ReadMe
CONFLICT(content) : Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result
qcj@139 - 159 - 150 - 152:~/ gitcode$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
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")

发现 ReadMe 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<,二二二二二二,>>>>>>>来标记出不同分支的冲突内容，如下所示:

qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<< < HEAD
write ccc for new branch
write bbb for new branch
dev1

此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果!!(再次提交很重要，切勿忘记）

hyb@139-159-150-152:~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello versionl
hello version2
hello version3
write bbb for new branch
hybe139-159-150-152:~/gitcode$ git add
hyb@139-159-150-152:~/gitcode$ git commit -m"merge ReadMe"
master 2976afc]merge ReadMe

到这里冲突就解决完成，此时的状态变成了

用带参数的 gitlog也可以看到分支的合并情况，具体大家可以自行搜索 git log 的用法:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git log --graph --pretty = oneline --abbrev - commit
* 2976afc(HEAD->master) merge ReadMe
| \
| *c594fd1(dev1) modify ReadMe
* | c10f6d0 modify ReadMe
|/

最后，不要忘记 dev1 分支使用完毕后就可以删除了:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch
* master
qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch - d dev1
Deleted branch devl(was c594fd1).

二. 分支管理策略

通常合并分支时，如果可能，Git 会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢?回顾一下

在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为:

那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得到:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git log --graph --pretty = oneline --abbrev - commit
* 2976afc(HEAD->master) merge ReadMe
| \
| *c594fd1 modify ReadMe
* | c10f6d0 modify ReadMe
|/

Git支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit ，这样从分支历史上就可以看出分支信息。

下面我们实战-下 --no-ff方式的 git merge 。首先，创建新的分支 dev2，并切换至新的分支;

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout - b dev2
Switched to a new branch 'dev2'

修改 ReadMe 文件，并提交一个新的commit:

qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add .
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"modify ReadMe"
[dev2 41b082f] modify ReadMe
1 file changed, 1 insertion(+)

切回master分支，开始合并:

hyb@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch'master'
hybe139 - 159 - 150 - 152 : ~/ gitcode$ git merge --no - ff - m "merge with no-ff" dev2
Merge made by the recursive'strategy.
ReadMe1 +
1 file changed, l insertion(+)
hyba139 - 159 - 150 - 152 : ~/ gitcodes cat ReadMe
hello bit
hello git
hello world
hello versionl
hello version2
hello version3
write bbb for new branch
a, b, c, d

请注意 --no-ff 参数，表示禁用 Fast forward 模式。
禁用 Fast forward 模式后合并会创建-个新的 commit，所以加上-m 参数，把描述写进去。

qcj@139 - 159 - 150 - 152:~/ gitcode$ git log --graph --pretty = oneline --abbrev - commit
* 5bd16b4(HEAD->master) merge with no - ff
| \
| *41b082f(dev2) modify ReadMe
|/

可以看到，不使用 Fast forward 模式，merge后就像这样,

所以在合并分支时，加上–no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。

2.1 分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理:

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活;

那在哪干活呢?干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本;

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样!

2.2 bug分支

假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master分支上面有bug，需要解决。在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

可现在 dev2 的代码在工作区中开发了一半，还无法提交，怎么办?例如:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch
* dev2
master
qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d
i am coding ...
qcja139 - 159 - 150 - 152:~/ gitcode$ git status
On branch dev2
Changes not staged for commit :(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified:
ReadMe
no changes added to commit(use "git add" and /or "git commit -a")

Git提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

qcj@139 - 159 - 150 - 152:~/ gitcodes git stash
Saved working directory and index state WIP on dev2 : 41b082f modify ReadMe
qcja139 - 159 - 150 - 152 : ~/ gitcodeS git status
On branch dev2
nothing to commit, working tree clean

因此可以放心地创建分用 git status 查看工作区，就是干净的(除非有没有被 Git 管理的文件)支来修复bug。

储藏 dev2 工作区之后，由于我们要基于master分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug，示例如下

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch 'master'
qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout - b fix bug
Switched to a new branch 'fix_bug'
qcj@139 - 159 - 150 - 152:~/ gitcode$ vim ReadMe
qcj@139 - 159 - 150 - 152:~/ gitcodes cat ReadMe
hello bit
hello git
hello world
hello versionl
hello version2
hello version3
write bbb for new branch
a, b, c, d, e
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add ReadMe
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"fix bug'
[fix bug 4bbcoc4] fix bug
1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master分支，并完成合并，最后删除fix_bug 分支

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch 'master'
qcje139 - 159 - 150 - 152 : ~/ gitcode$ git merge
: --no - ff - m"merge fix_bug branch
fix_bug
Merge made by the 'recursive'strategy.
ReadMe2 + -
1 file changed, l insertion(+), 1 deletion(-)
qcja139 - 159 - 150 - 152 : ~/ gitcodes cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d, e
qcje139 - 159 - 150 - 152:~/ gitcode$ git branch - d fix_bug
Deleted branch fix bug(was 4bbc0c4).

至此，bug的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout dev2
Switched to branch 'dev2
qcj@139 - 159 - 150 - 152:~/ gitcode$ git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了?用 git stash list 命令看看:

qcj@139 - 159 - 150 - 152:~/ gitcodes git stash list
stash@{o}: WIP on dev2 : 41b082f modify ReadM

工作现场还在，Git 把stash 内容存在某个地方了，但是需要恢复一下，如何恢复现场呢?我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git stash pop
On branch dev2
Changes not staged for commit :(use "git add <file>..." to update what will be committed)." to discard changes in working directory)(use "git restore <file>...modified:
ReadMe
no changes added to commit(use "git add" and /or "git commit -a")
Dropped refs / stashe{ 0 }(4f873250b3503687b5efd26196776aee7e3724c2)

再次查看的时候，我们已经发现已经没有现场可以恢复了

hyb@139-159-150-152:~/gitcode$ git stash list
hyb@139-159-150-152:~/gitcode$

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用git stash drop 来删除;

你可以多次stash，恢复的时候，先用git stash list 查看，
然后恢复指定的stash，用命令git stash apply stash@{o},这部分请同学们自行使用。

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如:

qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d
i am coding ...
Done!
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add .
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"modify ReadMe"
[dev2 ed0916d] modify ReadMe
1 file changed, 1 insertion(+)

但我们注意到了，修复 bug的内容，并没有在 dev2上显示。此时的状态图为:

Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。

我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。

是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决(在 master 上解决)。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。此时的状态为:

解决这个问题的·个好的建议就是:最好在自己的分支上合并下master，再让master去合并dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master 。此时的状态为:

对应的实操演示如下，要说明的是，以下演示的merge操作，没有使用–no-ff，但上述的图示是禁用 Fast forward 了模式后得出的，主要是为了方便解释问题。

# dev合并master--no - ff，但上述的图⽰是
qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch
* dev2
master
qcj@139 - 159 - 150 - 152:~/ gitcode$ git merge master
Auto - merging ReadMe
CONFLICT(content) : Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
#发⽣冲突
qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a, b, c, d
i am coding ... Done!
====== =
a, b, c, d, e
>>>>>> > master
qcj@139 - 159 - 150 - 152:~/ gitcode$ vim ReadMe
qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d, e
i am coding ... Done!
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add .
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"merge master"
[dev2 447d29f] merge master
qcj@139 - 159 - 150 - 152:~/ gitcode$ git status
On branch dev2
nothing to commit, working tree clean
qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch 'master'
qcj@139 - 159 - 150 - 152:~/ gitcode$ git merge dev2
Updating 193421f..447d29f
Fast - forward
ReadMe | 1 +
1 file changed, 1 insertion(+)
qcj@139 - 159 - 150 - 152:~/ gitcode$ git status
On branch master
nothing to commit, working tree clean
qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch - d dev2
Deleted branch dev2(was 447d29f).

2.3 删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。

可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。演示如下:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout - b dev3
Switched to a new branch 'dev3'
qcj@139 - 159 - 150 - 152:~/ gitcode$ vim ReadMe
qcj@139 - 159 - 150 - 152:~/ gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a, b, c, d, e
i am coding ... Done!
i am writing new features ...
qcj@139 - 159 - 150 - 152:~/ gitcode$ git add .
qcj@139 - 159 - 150 - 152:~/ gitcode$ git commit - m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features
1 file changed, 1 insertion(+)
qcj@139 - 159 - 150 - 152:~/ gitcode$ git checkout master
Switched to branch 'master'
qcj@139 - 159 - 150 - 152:~/ 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'.

直接使用传统的删除分支的方法不行，按照提示，有了如下方式:

qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch - D dev3
Deleted branch dev3(was cd2f149).
qcj@139 - 159 - 150 - 152:~/ gitcode$ git branch
* master

2.4 小结

• 分支在实际中有什么用呢?假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
• 现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
• 并且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。

后言

这就是Git初始及其结构原理分析。大家自己好好消化！今天就分享到这！感谢各位的耐心垂阅！咱们下期见！拜拜~