Git分支管理

​

分支理解

几乎每一种版本控制系统都以某种形式支持分支，一个分支代表一条独立的开发线。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

​​​​

在版本回退⾥可以知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀
个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即master分⽀。再来理解⼀下HEAD，HEAD严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD指向的就是当前分⽀。

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

查看分支

命令：git branch
通过这个命令可以看到当前仓库里面的所以分支

git中的HEAD不仅会指向master分支，也可以指向其他分支，且被HEAD指向的分支才是我们当前的工作分支，上面的 * 在那个分支前面，说明这个分支是当前的工作分支

创建分支

​命令 ：git branch [分支名]

使用tree .git可以看到 .git中的 refs/heads 下多了一个我们所创建的分支

查看里面的commit id，可以发现master和dev中的是一样的，这是因为，我们创建分支的时候是根据最近一次提交的（当前最新版本）来创建的

切换分支

命令：git checkout [分支名]

#创建与切换分支可以只用一条命令
git checkout -b [新的分支名] #  -b代表如果这个分支不存在就创建

在dev分支上修改文件并提交

然后切换回master分支查看test3

可以看见在dev分支上修改的test3,并没有影响到master分支上的test3

合并分支

如果想要分支A去合并分支B，就需要先切换到分支A上去操作
在使用：git merge [被合并的分支名]

可以看到合并分支后master中的commit id和dev中的commit id相同了，说明他们指向了相同的版本

删除分支

合并完成后,dev分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀
命令： git branch -d [分支名]

合并冲突

在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题，比如在master分支中修改了一个文件，在dev分支下对相同文件的相同位置也进行了操作修改,就会导致合并的时候在同一个位置有2个不同的值，就会导致无法确定到底该保留哪一个，产生冲突，就需要我们去解决冲突

现在去合并的话，就会报冲突

这里可以看到说test3这个文件有冲突，需要解决冲突后再去进行一次提交操作
那么我们进入test3这个文件中看


效果图

可以用git log --graph --abbrev-commit命令像类似图表的形式查看日志，可以看到和上面效果图差不多风格的图

分支管理策略

通常合并分⽀时，如果可能，Git会采⽤ Fast forward 模式，就是上面没有冲突的合并模式

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提
交到底是merge进来的还是正常提交的
但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。如下面的图中就能看出分支信息

那没有冲突的情况下如何让我们合并分支的时候也能通过git log看到图示化的合并情况，这就需要在使用 git merge --no-ff -m "提交信息" [分支名]其中的 --no-ff就是不让它使用Fast forward 模式去合并，就可以看到了 ，而-m "提交信息"就代表着合并之后要进行一次提交，就需要带上提交信息

分支策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分⽀应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；
项目中的每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就
可以了。
所以，团队合作的分⽀看起来就像这样：

bug 分⽀

假如我们现在正在 dev 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有bug，需要解决。这种情况下我们是不能直接在master分支上直接修改的，在Git中，每个bug都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除

对于我们要解决master分支中的bug不能让dev分支中工作区内容出现在master中，就需要对正在进行开发的dev分支进行储藏
需要用到该命令：

git stash #可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来 

不过git stash只能储藏已经被git 管理的文件，就是在git stash之前有被add,commit 操作过的文件，如果是立马新建一个文件就stash是不行的

在储藏dev的内容后就不会有相关的未提交提示了

然后就可以在master分支上创建一个修复bug的分支，在该分支上去修复bug，在在master分支上去合并该bug分支

修复完bug后对应正在开发的dev储藏后就需要恢复存储区的内容,就需要用到git stash pop

另外，恢复现场也可以采⽤git stash apply恢复，但是恢复后，stash内容并不删除，你需要⽤ git stash drop 来删除；
你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0}

这里的dev分支恢复后，没有我们对master分支上修复bug后的内容， 因为dev是以master分支修复bug之前的时候创建的

Master 分⽀⽬前最新的提交，是要领先于新建 dev时基于的 master 分⽀的提交的，所以我们在 dev2 中当然看不⻅修复bug的相关代码。我们的最终⽬的是要让 master 合并 dev 分⽀的，那么正常情况下我们切回master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。

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

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并
dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，而不影响 master 。此时的状态
为

删除临时分支

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

但是如果我们今天正在某个feature分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发，这个feature分⽀必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的
因为对于没有merge操作的分支，git是不允许随便删除的使用git branch -d 就会导致报错

想要强行删除，就需要将-d改成 -D

git branch -D [分支名] # -D表示强行删除