目次
理解分支
创建分支
切换分支
归并分支
删除分支
归并辩论
分支管理计谋
快进归并
正常归并
bug 分支
总结
理解分支
在版本控制系统中，分支是一条独立的开辟线路。它答应开辟者从一个主要的代码基线（例如master分支）分离出来，举行独立的开辟工作，如开辟新功能、修复漏洞等，而不会影响主分支的稳定性。
在版本回退里，我们已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分支。停止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master 分支。 再来理解⼀下HEAD，HEAD 严酷来说不是指向提交，而是指向 master，master才是指向提交的，所以，HEAD 指向的就是当前分支。
创建分支
查看本地堆栈中的所有分支，当前所在的分支会在列表中以 * 符号标记出来。
创建一个新的分支
- 方法一：
- git branch 新分支名
- 方法二：
- git checkout -b 新分支名
- （创建完成分支后会自动切换过去）
方法二：
切换分支
归并分支
将一个或多个分支的修改归并到当前分支
我们来做一个简单的小实验
- 在目次下创建一个文件test ，而且输入一行内容
- 切换到 dev 分支下
- 在 dev 分支下修改 test 文件，新增一行内容，并举行一次提交利用
- 对比master分支 和 dev 分支 ，test 文件内容的区别
我们在目次下创建一个文件test ，而且输入一行内容
我们切换到 dev 分支下
在 dev 分支下修改 test ⽂件，新增一行内容，并举行一次提交利用
对比master分支 和 dev 分支 ，test 文件内容的区别
总结：在 master 分支上，内容没有添加，在 dev 分支上，内容添加了。为什么会出现这个征象呢？我们来看看 dev 分支和 master 分支指向，发现两者指向的提交是不⼀样的
看到这里就能明确了，由于我们是在dev 分支上提交的，而master 分支此刻的提交点并没有变，此时的状态如图如下：
为了在 master 主分支能看到新的提交，就需要将 dev 分支归并到 master 分支
归并后，master 分支就能看到 dev 分支提交的内容了。此时的状态如图如下所示 删除分支
删除本地分支（已经归并过的分支）
欺压删除本地分支（未归并的分支）
有些时候我们开辟一个分支开辟到一半，还没有归并，如果这个时候我们不想要了，我们想要删除分支就得欺压删除本地分支
归并辩论
在实际分支归并的时候，并不是想归并就能归并乐成的，有时候可能会遇到代码辩论的问题。 我们来做一个简单的小实验
- 创建⼀个新的分支 dev ，并切换至dev 分支
- 在 dev 分支 下修改 test ⽂件，更改文件内容，并提交
- 切换到 master 分支 ，观察 test 文件内容，对 test 文件再举行一次修改，并提交
- master 分支 和 dev分支 举行归并
创建⼀个新的分支 dev ，并切换至dev 分支
在 dev 分支下修改 test ⽂件，更改文件内容，并提交
切换到 master 分支，观察 test 文件内容，对 test 文件再举行一次修改，并提交
master 分支 和 dev分支 举行归并，这种情况下，Git 只能试图把各自的修改归并起来，但这种归并就可能会有辩论
发现 test 文件有辩论后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<，=======， >>>>>>> 来标记出不同分支的辩论内容，如下所示：
此时我们必须要手动调整辩论代码，并需要再次提交修正后的效果！！
到这里辩论就办理完成，此时的状态变成了
分支管理计谋
查看提交历史的下令，类图形化查看提交历史
- git log --graph --pretty=oneline --abbrev-commit
- 快进归并（Fast - forward Merge）
- 正常归并（Three - way Merge）
快进归并
适用场景和条件：这种归并适用于源分支是目标分支的直接后继，而且源分支上的所有提交都是在目标分支最新提交的底子上线性举行的情况。例如，从master分支创建new - feature分支后，master分支没有新的修改，而new - feature分支举行了一系列的提交。
在 Fast - forward Merge 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的照旧正常提交的
正常归并
适用场景和条件：当目标分支和源分支有独立的提交历史，即从它们的共同祖先之后有各自的修改时，需要举行正常归并。例如，master分支和feature - branch都有从共同祖先之后的新提交。
在 Three - way Merge模式下， 这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在归并辩论部分创建的 dev 分支 ，但仍旧能看到 master 其实是由其他分支归并得到
我们可以欺压禁用 快进归并 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分支历史上就可以看出分支信息。
- git merge --no-ff -m "提交文件的描述" 合并的分支名
所以在归并分支时，加上 --no-ff 参数就可以用平凡模式归并，归并后的历史有分支，能看出来曾 经做过归并，而 fast forward 归并就看不出来曾经做过归并 在实际开辟中，我们应该按照几个根本原则举行分支管理：
- master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
- 干活都在dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev 分支归并到 master 分支上，在master 分支发布1.0版本
- 我们每个人都在dev 分支上干活，每个人都有自己的分支，时不时地往dev 分支上归并就可以了。
所以，团队互助的分支看起来就像这样：
bug 分支
- 如果我们现在正在 dev2 分支上举行开辟，开辟到⼀半，忽然发现 master 分支之上面有 bug，需要办理
- 每个 bug 都可以通过⼀个新的临时分支来修复，修复后，归并分支，然后将临时分支删除
- 可现在 dev2 的代码在工作区中开辟了⼀半，还无法提交，怎么办？
暂时保存当前工作目次的修改，这些修改可以是未提交的文件修改、新添加的文件或者暂存区（stage area）中的修改。它答应你在不提交当前工作的情况下切换分支或者处理其他告急使命，之后再回来规复这些修改继承工作。
查看所有已保存的stash（暂存）记录的列表。当你使用git stash下令保存工作目次和暂存区的修改时，这些修改会被存储在一个栈结构中，git stash list下令就是用来查看这个栈中所有记录的详细信息的。
用于规复并删除git stash栈顶（最新保存）的修改记录的下令。它联合了git stash apply（应用暂存的修改）和git stash drop（删除暂存的修改）的功能。
- git stash pop // apply + drop
- git stash apply // 恢复工作区的内容
- git stash drop // 删除暂存的修改
- master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码
- 我们的最终目的是要让 master 归并 dev2 分支的，那么正常情况下我们切回 master 分支直接归并即可，但这样其实是有⼀定风险的
- 是由于在归并分支时可能会有辩论，而代码辩论需要我们手动办理（在 master 上办理）。
- 我们无法保证对于辩论问题可以正确地⼀次性办理掉，由于在实际的项目中，代码辩论不只⼀两行那么简单， 有可能几十上百行，甚至更多，办理的过程中难免手误堕落，导致错误的代码被归并到 master 上。
办理这个问题的⼀个好的发起就是：最幸亏自己的分支上归并下 master ，再让 master 去归并dev2 ，这样做的目的是有辩论可以在本地分支办理并举行测试，而不影响 master 。
此时的状态为：
总结
分支在实际中有什么用呢？
- 假设你准备开辟⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交，又存在丢失每天进度的巨大风险。
- 现在有了分支，就不消怕了。你创建了⼀个属于你自己的分支，别人看不到，还继承在原来的分支上正常⼯作，而你在自己的分支上干活，想提交就提交，直到开辟完毕后，再一次性归并到原来的分支上，这样，既安全，又不影响别人工作。
- 而且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件照旧1万个文件。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
