Git分支管理
目次1.明白分支
2.创建分支
3.切换分支
4.归并分支
5.删除分支
6.归并冲突
7.分支管理计谋
8.分支计谋
9.bug分支
10.删除临时分⽀
11.小结
1.明白分支
本章开始介绍Git的杀⼿级功能之⼀（留意是之⼀，也就是后⾯还有之⼆，之三……）：分⽀。分⽀就 是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习C++的时间，另⼀个你正在另⼀个平⾏宇宙⾥ 努⼒学习JAVA。
假如两个平⾏宇宙互不⼲扰，那对如今的你也没啥影响。不过，在某个时间点，两个平⾏宇宙归并 了，效果，你既学会了C++⼜学会了JAVA！
https://i-blog.csdnimg.cn/direct/174302fecbc5428c98a5bce7c1c65fcb.png
在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以明白为是⼀ 个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即master分⽀。
再来明白⼀下HEAD，HEAD严格来说不是指向提交，⽽是指向master，master才是指向提交的，所 以，HEAD指向的就是当前分⽀。
https://i-blog.csdnimg.cn/direct/f5947b9766f2466697b2ea2cd752c2c8.png
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽ HEAD只要⼀直指向master分⽀即可指向当前分⽀。
通过查察当前的版本库，我们也能清晰的理出思路:
https://i-blog.csdnimg.cn/direct/6a0064c2163c4a1bba063268b3da46a8.png
2.创建分支
Git ⽀持我们查察或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：
[*]列出分支根本命令：
git branch没有参数时，git branch 会列出你在本地的分支。
https://i-blog.csdnimg.cn/direct/c5da8373805344dab9cf7f48447ed1fc.png
此例的意思就是，我们有一个叫做 master 的分支，并且该分支是当前分支。
接下来我们新建一个分支
https://i-blog.csdnimg.cn/direct/f8ae851bafe449ab9a90d2ae9f201a7a.png
当我们创建新的分⽀后，Git新建了⼀个指针叫dev，* 表⽰当前 HEAD 指向的分⽀是 dev 分⽀ ⽀。别的，可以通过⽬录结构发现，新的分⽀ dev和master指向同⼀个修改。
https://i-blog.csdnimg.cn/direct/79e8f84410d34d50b1c6d65bb53cef73.png
并且也可以验证下HEAD⽬前是指向master 的。
https://i-blog.csdnimg.cn/direct/420906a4613d436d8074f4c483f4deaa.png
⼀张图总结：
https://i-blog.csdnimg.cn/direct/a46239c6e9774fd888cb654e4a8576a6.png
3.切换分支
那如何切换到dev分⽀下进⾏开发呢？使⽤ git checkout 命令即可完成切换，⽰例如下：
https://i-blog.csdnimg.cn/direct/d7f64842bc0e42f6a63bfa6e3a7a1c76.png
https://i-blog.csdnimg.cn/direct/2107da52f43e438696593f6aabd866e6.png
我们发现HEAD已经指向了dev，就表⽰我们已经乐成的切换到了dev上！
接下来，在 dev 分⽀下修改ReadMe⽂件，新增⼀⾏内容，并进⾏⼀次提交操作：
https://i-blog.csdnimg.cn/direct/670385d3cec14198ae1ad875fb676121.png
如今，dev分⽀的⼯作完成，我们就可以切换回master分⽀：
https://i-blog.csdnimg.cn/direct/b3ee71fd0b414018b6702709d1fd0afe.png
切换回master分⽀后，发现ReadMe⽂件中新增的内容不⻅了！！！赶紧再切回dev看看:
https://i-blog.csdnimg.cn/direct/9d7b671ffed6411aab6556b0ea17ac9d.png
在dev分⽀上，内容还在。为什么会出现这个现象呢？我们来看看dev分⽀和master分⽀指向，发 现两者指向的提交是不⼀样的：
https://i-blog.csdnimg.cn/direct/f315e5ff2b464145b6a396a611ecf524.png
看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时 的状态如图如下所⽰。
https://i-blog.csdnimg.cn/direct/c2697cce7e2f45ca96a0ec8704af19f1.png
当切换到master分⽀之时，HEAD就指向了master，固然看不到提交了！
4.归并分支
git merge命令用来归并分支。
为了在master主分⽀上能看到新的提交，就需要将 dev 分⽀归并到master 分⽀，⽰例如下：
首先我们需要切换回master分支
https://i-blog.csdnimg.cn/direct/adfc0595c863434e8e41b20fa2140609.png
接下来我们就归并dev分支
https://i-blog.csdnimg.cn/direct/c3950ee07f8e4dac9a1bf0b0f23400de.png
git merge 命令⽤于归并指定分⽀到当前分⽀。
归并后，master就能看到dev分⽀提交的内容 了。此时的状态如图如下所⽰。
https://i-blog.csdnimg.cn/direct/4f662a6c35344650816c50ddbc0ab714.png
Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以归并速度⾮常快。 固然，也不是每次归并都能Fast-forward，我们后⾯会讲其他⽅式的归并。
5.删除分支
归并完成后,dev分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉，留意假如当前正处于某 分⽀下，就不能删除当前分⽀，如：
https://i-blog.csdnimg.cn/direct/cab2ca1edbf3425f93e04d62a4496602.png
⽽可以在其他分⽀下删除当前分⽀，如：
https://i-blog.csdnimg.cn/direct/a7e513b56b0445e5914437da52c9ab55.png
此时的状态如图如下所⽰。
https://i-blog.csdnimg.cn/direct/3ac15b107c804785be9ff79492caf6c4.png
因为创建、归并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，归并后再删掉分⽀，这和 直接在master分⽀上⼯作效果是⼀样的，但过程更安全。
6.归并冲突
但是，在实际分⽀归并的时间，并不是想归并就能归并乐成的，偶尔间可能会碰到代码冲突的问题。
为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤git checkout -b dev1 ⼀步完成创建并切换的动作，⽰例如下：
https://i-blog.csdnimg.cn/direct/0eba1b087b47407c8967fea2fd93f06f.png
在 dev1 分⽀下修改 ReadMe ⽂件，更改⽂件内容如下，并进⾏⼀次提交，如：
https://i-blog.csdnimg.cn/direct/34efae77713d4f2ab856ef628c7e2a42.png
切换⾄ master 分⽀，观察 ReadMe ⽂件内容:
https://i-blog.csdnimg.cn/direct/105d0e655d0048fd803425b8f21e09e0.png 我们发现，切回来之后，⽂件内容由变成了⽼的版本，这种现象很正常，我们如今也完全能明白。
此时在master分⽀上，我们对ReadMe⽂件再进⾏⼀次修改，并进⾏提交，如下：
https://i-blog.csdnimg.cn/direct/76a505e27ed84f90989023a497c95ff2.png
如今， master 分⽀和 dev1 分⽀各⾃都分别有新的提交，变成了这样：
https://i-blog.csdnimg.cn/direct/ff50848490e34707b0adc9baaa0e3737.png
这种情况下，Git只能试图把各⾃的修改归并起来，但这种归并就可能会有冲突，如下所⽰：
https://i-blog.csdnimg.cn/direct/c9efd4b413484d6182e0887856aa4d3f.png
发现ReadMe⽂件有冲突后，可以直接查察⽂件内容，要说的是Git会⽤>>>>>> ，=======，>>>>>>>来标志出差别分⽀的冲突内容，如下所⽰：
https://i-blog.csdnimg.cn/direct/b0a253cc5a4047ac82c4d3a193cf42e9.png
此时我们必须要⼿动调解冲突代码，并需要再次提交修正后的效果！！（再次提交很重要，切勿忘 记）
https://i-blog.csdnimg.cn/direct/9e7aedb484c2433aa0c9c4c054d9fa34.png
到这⾥冲突就办理完成，此时的状态变成了
https://i-blog.csdnimg.cn/direct/bc6eb2f4320e4ea9a038a0f63feda303.png
⽤带参数的git log也可以看到分⽀的归并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法:
在使用 Git 提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史，我们可以使用 git log 命令查察。
[*]git log 命令用于查察 Git 仓库中提交历史记录。
[*]git log 显示了从最新提交到最早提交的所有提交信息，包括提交的哈希值、作者、提交日期和提交消息等。
git log 命令的根本语法：
git log [选项] [分支名/commit id]常用的选项包括：
[*]-p：显示提交的补丁（具体更改内容）。
[*]--oneline：以简洁的一行格式显示提交信息。
[*]--graph：以图形化方式显示分支和归并历史。
[*]--decorate：显示分支和标签指向的提交。
[*]--author=<作者>：只显示特定作者的提交。
[*]--since=<时间>：只显示指定时间之后的提交。
[*]--until=<时间>：只显示指定时间之前的提交。
[*]--grep=<模式>：只显示包罗指定模式的提交消息。
[*]--no-merges：不显示归并提交。
[*]--stat：显示简略统计信息，包括修改的文件和行数。
[*]--abbrev-commit：使用短提交哈希值。
[*]--pretty=<格式>：使用自界说的提交信息显示格式。
https://i-blog.csdnimg.cn/direct/034f9ede90874f8c8c4b1fb07b899453.png
我们可以切换两个分支看看什么情况
https://i-blog.csdnimg.cn/direct/04d7e2365c0b426eb267bc05cf3f787a.png
https://i-blog.csdnimg.cn/direct/7cabfef218034707ae8a9f54ffb62df4.png
最后，不要忘记dev1分⽀使⽤完毕后就可以删除了：
https://i-blog.csdnimg.cn/direct/428e98693dfb42c683b8af5b4865954e.png
7.分支管理计谋
通常归并分⽀时，假如可能，Git会采⽤ Fast forward 模式。还记得假如我们采⽤ Fast forward 模式之后，形成的归并效果是什么呢？回顾⼀下
https://i-blog.csdnimg.cn/direct/fbbd4bf33b74459ebd2204cbc5642f2d.png
在这种 Fast forward 模式下，删除分⽀后，查察分⽀历史时，会丢掉分⽀信息，看不出来最新提 交到底是merge进来的还是正常提交的。
但在归并冲突部门，我们也看到通过办理冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：
https://i-blog.csdnimg.cn/direct/f9b8786f9c8a4d6aa44fc0d7bc1f63ef.png
那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。
例如我 们如今已经删除了在归并冲突部门创建的 dev1 分⽀，但依旧能看到master其实是由其他分⽀归并 得到：
https://i-blog.csdnimg.cn/direct/034f9ede90874f8c8c4b1fb07b899453.png
Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在merge时⽣成⼀个新的commit id ，这样，从分⽀历史上就可以看出分⽀信息。
Git 支持我们强制禁用从分支历史上看出分支信息。
在 Fast forward 模式 下，Git 会在归并时直接将分支指针向前移动，而不会天生一个新的归并提交。假如你盼望在归并时强制天生一个新的归并提交，可以使用 --no-ff 选项。
下⾯我们实战⼀下--no-ff ⽅式的 git merge 。⾸先，创建新的分⽀dev2，并切换到新的分支
https://i-blog.csdnimg.cn/direct/3ba4e75771ad4bebae55e4495845cc35.png
修改 ReadMe ⽂件，并提交⼀个新的 commit :
https://i-blog.csdnimg.cn/direct/ab57444762634c699964d507bbd56dff.png
切回 master 分⽀，开始归并:
https://i-blog.csdnimg.cn/direct/6c3c309c39bc4cc590f11b92898f998d.png
https://i-blog.csdnimg.cn/direct/74ee5712199c4b2694c41216cb27e718.png
请留意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤Fast forward 模式后归并会创建⼀个新的 commit ，所以加上-m 参数，把形貌写进去。
归并之后，查察分支历史
https://i-blog.csdnimg.cn/direct/b45ddf94187248b6bc7c63afd3181683.png
可以看到，不使⽤ Fast forward 模式，merge后就像这样：
https://i-blog.csdnimg.cn/direct/034ccfa0bfa74b61b11e30bee29ef236.png 所以在归并分⽀时，加上--no-ff 参数就可以⽤平凡模式归并，归并后的历史有分⽀，能看出来曾 经做过归并，⽽ fast forward 归并就看不出来曾经做过归并。
8.分支计谋
在实际开发中，我们应该按照⼏个根本原则进⾏分⽀管理： ⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平常不能在上⾯⼲活；
那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时间，⽐如1.0版本发布 时，再把dev分⽀归并到master上，在master分⽀发布1.0版本；
你和你的⼩同伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上归并就 可以了。
所以，团队合作的分⽀看起来就像这样：
https://i-blog.csdnimg.cn/direct/404c965a1ae9450ab153a92e7012996f.png
9.bug分支
假如我们如今正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有bug，需要 办理。
在Git中，每个bug都可以通过⼀个新的临时分⽀来修复，修复后，归并分⽀，然后将临时分⽀ 删除。 可如今 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？
例如，我们先看看Readme文件
https://i-blog.csdnimg.cn/direct/a918c3dfab474f55b65015095478926f.png
https://i-blog.csdnimg.cn/direct/f74b98924bf94a9fb873f4a72cffb61d.png
https://i-blog.csdnimg.cn/direct/87ee4b73b72f47d5af8b3590076b0705.png
就在这个时间，我发现我们在master分支里面少加了一句话。这怎么办？
别着急，我们先来认识一个命令 git stash
git stash（git蕴藏）可用于以下情形：
[*]发现有一个类是多余的，想删掉它又担心以后需要查察它的代码，想保存它但又不想增长一个脏的提交。这时就可以思量git stash。
[*]使用git的时间，我们往往使用分支（branch）办理任务切换问题，例如，我们往往会建一个自己的分支去修改和调试代码, 假如别人或者自己发现原有的分支上有个不得不修改的bug，我们往往会把完成一半的代码commit提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。这样的话往往log上会有大量不须要的记录。其实假如我们不想提交完成一半或者不美满的代码，但是却不得不去修改一个紧急Bug，那么使用git stash就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时间你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修Bug，比及修完Bug，提交到服务器上后，再使用git stash apply将从前一半的工作应用回来。
[*]经常有这样的事情发生，当你正在进行项目中某一部门的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。办理这个问题的办法就是git stash命令。蕴藏(stash)可以获取你工作目次的中间状态——也就是你修改过的被追踪的文件和暂存的变动——并将它保存到一个未完结变动的堆栈中，随时可以重新应用。
git stash会把所有未提交的修改（包括暂存的和非暂存的）都保存起来，用于后续恢复当前工作目次。
好比下面的中间状态，通过git stash命令推送一个新的蕴藏，当前的工作目次就干净了。
https://i-blog.csdnimg.cn/direct/930ad528b8a746c6b9ae7b329ad8c65b.png
⽤ git status 查察⼯作区，就是⼲净的（除⾮有没有被Git管理的⽂件），因此可以放⼼地创建分 ⽀来修复bug。
蕴藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复bug，所以需要切回 master 分⽀，再新 建临时分⽀来修复bug，⽰例如下：
https://i-blog.csdnimg.cn/direct/8bed0c4451434963baa067c08563d036.png
接下来我们就创建新分支，修复我们的bug
https://i-blog.csdnimg.cn/direct/29c1380482c34bb681af55fad6577792.png
我们重新提交一下
https://i-blog.csdnimg.cn/direct/88c2f7c4c8cd4b2f82488008916a1b43.png
修复完成后，切换到master 分⽀，并完成归并，最后删除 fix_bug 分⽀：
https://i-blog.csdnimg.cn/direct/39e023133e21472cbbfa31df60c6490a.png
⾄此，bug的修复⼯作已经做完了，我们还要继续回到dev2 分⽀进⾏开发。切换回 dev2 分⽀：
https://i-blog.csdnimg.cn/direct/7d3b8497f5a74b079ad71f199738503e.png
⼯作区是⼲净的，刚才的⼯作现场存到哪去了？
查察现有stash，可以使用git stash list命令
在使用git stash apply命令时可以通过名字指定使用哪个stash，默认使用最近的stash（即stash@{0}）
https://i-blog.csdnimg.cn/direct/e655e6872fad42b9af20e37b606ac143.png
⼯作现场还在，Git把stash内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使 ⽤ git stash pop 命令，恢复的同时会把stash也删了，⽰例如下：
可以通过git stash pop命令恢复之前缓存的工作目次，这个指令将缓存堆栈中的第一个stash删除，并将对应修改应用到当前的工作目次下
https://i-blog.csdnimg.cn/direct/3e8cd1812fcb4da988844538305a58f8.png
再次查察的时间，我们已经发现已经没有现场可以恢复了
https://i-blog.csdnimg.cn/direct/6fd7cecd2d9a44efb5b65804e32f4c4c.png
别的，恢复现场也可以采⽤ ⽤git stash apply 恢复，但是恢复后，stash内容并不删除，你需要 git stash drop 来删除；
你可以多次stash，恢复的时间，先⽤ git stash list 查察，然后恢复指定的stash，⽤命令 git stash apply stash@{0} ,这部门请同学们⾃⾏使⽤。
恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交，例如：
https://i-blog.csdnimg.cn/direct/40bcc1e9b00d4a54bbf97b5fccf429de.png
但我们留意到了，修复bug的内容，并没有在 dev2 上显⽰。此时的状态图为：
https://i-blog.csdnimg.cn/direct/fc917fa69ff54d32a4770a9a61b35e3a.png
Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的master 分⽀的提交的，所以我们 在 dev2 中固然看不⻅修复bug的相关代码。
我们的最终⽬的是要让master 归并 dev2 分⽀的，那么正常情况下我们切回 master分支归并即可，但这样其实是有⼀定⻛险的。
是因为在归并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动办理（在 master 分⽀直接合 master 上办理）。我们⽆法 包管对于冲突问题可以精确地⼀次性办理掉，因为在实际的项⽬中，代码冲突不但⼀两⾏那么简朴， 有可能⼏⼗上百⾏，甚⾄更多，办理的过程中不免⼿误出错，导致错误的代码被归并到 master 上。
此时的状态为：
https://i-blog.csdnimg.cn/direct/9d618eb450884563bdc28be82236d75f.png
办理这个问题的⼀个好的发起就是：最幸亏⾃⼰的分⽀上归并下 master ，再让 master 去归并 dev ，这样做的⽬的是有冲突可以在本地分⽀办理并进⾏测试，⽽不影响 master 。此时的状态 为：
https://i-blog.csdnimg.cn/direct/b0a1ce9ae36d4b7fb9c4d943c1777a17.png
https://i-blog.csdnimg.cn/direct/31cf9cd411ce4b0f85fc84303899b79c.png 对应的实操演⽰如下，要说明的是，以下演⽰的merge操作，没有使⽤--no-ff ，但上述的图⽰是 禁⽤ Fast forward 了模式后得出的，主要是为了⽅便解释问题。
dev 归并 master
https://i-blog.csdnimg.cn/direct/e8f558e53828491dbb9b07d7d9877d28.png
发⽣冲突
https://i-blog.csdnimg.cn/direct/348ce2dbbf5e499e9a65f20935889a22.png
办理冲突并重新提交
https://i-blog.csdnimg.cn/direct/45576ddd8f8b4886957d14746b09676e.png
切回 master
https://i-blog.csdnimg.cn/direct/67be1831a8514d02a4cb3578905b2dcc.png
master 归并 dev2-- ⽆需办理冲突！！
https://i-blog.csdnimg.cn/direct/308cde369075457aa31734ec79ca70b3.png
删除dev2 分⽀
https://i-blog.csdnimg.cn/direct/78d63e18e8fe4e99b62d0b8057b21a91.png
10.删除临时分⽀
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时，你肯定不盼望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新 功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，归并，最后，删除该 feature 分⽀。
但是，假如我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功 能的开发。虽然⽩⼲了，但是这个 的 feature 分⽀还是必须当场销毁，留着⽆⽤了。这时使⽤传统 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：
https://i-blog.csdnimg.cn/direct/c3ceb0d51f3f4ef5a12a726c960f1800.png
此 时新功能叫停，我们就切回master分支预备删除dev3分支
https://i-blog.csdnimg.cn/direct/5e1289b790274740a3e4d27f825ca8de.png
我们发现删除不了，那我们只能使用git branch -D命令
https://i-blog.csdnimg.cn/direct/d4895aa09ee94966a67cf45ba15c47f3.png
11.小结
分⽀在实际中有什么⽤呢？假设你预备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，假如⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。假如等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
如今有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上 正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性归并到原来的分⽀ 上，这样，既安全，⼜不影响别⼈⼯作。 并且Git⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]