Git分支管理_切换分支

---

前言

在本文章中，我们将要详细介绍一下git中有关Git分支管理，包括理解，创建，切换，合并，删除操作相关的内容

理解分支

每次提交，Git都会把它们串成一个时间线，这条时间线就是一个分支。
截止到目前，只有一条时间线，在Git中，这个叫做主分支，及master分支

HEAD并不是指向提交，而是指向master指针,master指针才是指向提交，所以，HEAD就是指向当前分支.

每次提交，master分支就会向前移动一步，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀

创建分支

git branch 查看当前本地所有分支

HEAD也可以指向其他分支，其中*表示当前HEAD指向的分支，被指向的分支就是当前正在工作的分支。

git branch dev 创建dev新分支

查看下面操作

我们发现master和dev指向同一个修改

切换分支

git checkout 分支名 切换分支

切换分支，HEAD指向发生改变，dev为工作分支

在 dev 分⽀下修改ReadMe⽂件，新增⼀⾏内容，并进⾏⼀次提交操作：

dev分⽀的⼯作完成，我们就可以切换回master分⽀

切换回master分⽀后，发现ReadMe⽂件中新增的内容不⻅了！！！
但是在dev分支下却存在

查看dev分⽀和master分⽀指向


切换到master分⽀之时，HEAD就指向了master，当然看不到提交了

合并分支

为了在master主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀

git merge dev 用于合并指定分支到当前分支。

此时的状态如图所示

Fast-forward代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快

删除分支

合并完成后,dev分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉

删除分支采用下面命令

git brabch -d

注意：如果当前正处于某分⽀下，就不能删除当前分⽀

因为创建、合并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全

合并冲突

对同一个文件在不同分支下进行修改，并合并提交，系统不知道提交哪个，代码冲突。

首先介绍一个命令

git branch -b
创建分支并且切换到该分支下

在dev分支下进行修改并且进行提交

切换到master分支进行修改并提交

进行合并就会发生冲突

打开文件内容进行观看

Git会⽤<<<<<<<，=======，>>>>>>>来标记出不同分⽀的冲突内容

这是需要我们对不要的文件内容进行手动删除在进行提交

此时冲突就解决了

同时可用下面命令查看分支合并情况

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

最后对dev分支进行删除

分支管理策略

我们再进行分支合并时，常用的就是fast forward模式，，但是我们删除分支之后，再查看分支信息，就看不出最新提交是merge进来的还是正常提交的。

合并冲突时候，我们明显看得出是合并进来的，这就不是fast forward模式了，我们就可以从分支历史上看出分支信息了。

fast forward模式是直接把master分支指向dev的当前提交，所以合并速度非常快。

我们也可以不用fast forward模式，那么在merge时就会生成一个新的commit ,这样，我们就可以从分支历史看出分支信息。

git merge - -no-ff -m “描述信息” 合并分支

我们查看一下分支合并情况。

此时状况如图所示

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

分支策略

在实际开发中，我们应该按照下面原则进行分支管理

1.master分支应该是稳定的，也就是用来发布新版本的，平时不能在上面干活。
2.我们干活应该在dev分支上，也就是说dev分支是不稳定的。
比如：1.0版本发布时，把dev分支合并到master分支上，在master分支上发布1.0版本。

每个人都有自己的分支，时不时往dev分支合并就可以。
团队合作的分支就像这样

bug分支

假如我们正在dev上进行开发，开发到一半，突然发现master上有bug，需要解决。我们不通过dev进行修复bug，dev是开发新需求的，而不是用来修复bug的。
我们需要通过一个新的临时分支修复，修复后，合并分支，然后将临时分支删除。

但是我们现在dev2的代码在工作区开发了一半，还无法提交，怎末办呢？？

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

进行git status查看工作区，就是干净的，因此可以放心的创建新分支修复bug。
新建分支修复，修复后，合并分支，然后将临时分支删除。

bug修复完毕之后，我们还需要继续回到dev分支上进行开发。
我们需要将刚才工作区的存储进行恢复

git stash list查看存了那些
git stash pop 进行恢复，恢复同时stash也会被删除

我们也可以用git stash apply恢复，但是恢复后，stash内容并不会删除，需要手动git stash drop删除
你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0}

恢复之后，继续开发，开发完毕就可以进行提交了。
我们可以发现，修复bug的内容，并不会在dev上显示，此时的状态图：

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

我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。
此时的状态为：

解决：
在自己的分支上合并一下master，再让master去合并dev。我们这样做目的有冲突可以在本地分支接解决并进行测试，而不影响master.

删除临时分支

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

可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。（没有进行合并）

我们需要用

git branch -D dev强制删除

总结

以上就是我们对Git分支管理（理解，创建，切换，合并，删除）的相关内容的详细介绍，希望对大家的学习有所帮助，仅供参考 如有错误请大佬指点我会尽快去改正 欢迎大家来评论~~~