Git分支原理、操作及实际开发中如何规范使用分支

😀前言
在这篇博文中，我将与大家分享关于Git分支管理的内容。Git作为一个分布式版本控制系统，在协同开发和版本控制中扮演着至关重要的角色。通过这篇文章，您将深入了解Git分支的原理、操作以及在实际开发中如何规范使用分支。希望这篇文章能对您的工作有所帮助，同时也非常期待您的宝贵意见，以帮助我不断改进。您的支持是我前进的动力，感谢大家的关注和阅读！

🏠个人主页：晨犀主页
🧑个人简介：大家好，我是晨犀，希望我的文章可以帮助到大家，您的满意是我的动力😉😉
💕欢迎大家：这里是CSDN，我总结知识的地方，欢迎来到我的博客，感谢大家的观看🥰
如果文章有什么需要改进的地方还请大佬不吝赐教 先在此感谢啦😊

Git分支管理

Git分支的原理

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

在我们每次的提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

分支规范

许多公司的开发团队都采用Git来做代码版本控制。如何有效地协同开发人员之间，以及开发、测试、上线各环节的工作，可能都有各自的流程与规范。

创建项目时，会针对不同环境创建三个常设分支：

1. develop：开发环境的稳定分支，公共开发环境基于该分支构建。
2. pre-release：测试环境的稳定分支，测试环境基于该分支构建。
3. master：生产环境的稳定分支，生产环境基于该分支构建。仅用来发布新版本，除了从pre-release或生产环境Bug修复分支进行merge，不接受任何其它修改

平时开发工作中，会根据需要由开发人员创建两类临时分支：

1. 功能（feature）分支：为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature-*的形式命名(*为任务单号)
2. Bug修复（fixbug）分支：为了修复某个bug，从常设分支上面分出来的。修复完成后，再merge到对应的分支。Bug修复分支的命名，可以采用fixbug-*的形式命名（*为bug单号）

流程规范

正常开发流程

1. 从develop分支切出一个新分支，根据是功能还是bug，命名为feature-* 或 fixbug-*。
2. 开发者完成开发，提交分支到远程仓库。
3. 开发者发起merge请求（可在gitlab页面“New merge request”），将新分支请求merge到develop分支，并提醒code reviewer进行review
4. code reviewer对代码review之后，若无问题，则接受merge请求，新分支merge到develop分支，同时可删除新建分支；若有问题，则不能进行merge，可close该请求，同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程。
5. 转测时，直接从当前develop分支merge到pre-release分支，重新构建测试环境完成转测。
6. 测试完成后，从pre-release分支merge到master分支，基于master分支构建生产环境完成上线。并对master分支打tag，tag名可为v1.0.0_2019032115（即版本号_上线时间）

流程示意图如下所示

生产环境Bug修复流程

1. 生产环境的Bug分两种情况：

   1. 紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为。
   2. 非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复。

   非紧急Bug修复参考“正常开发流程”。

   紧急Bug修复，需要从master分支切出一个bug修复分支，完成之后需要同时merge到master分支与develop分支（如果需要测试介入验证，则可先merge到pre-release分支，验证通过后再merge到master分支上线）。merge时参考“正常开发流程”。流程示意图如下

1、创建分支

2、切换/检出分支

3、提交文件至分支

4、合并分支

5、推送分支文件到master

文章到这里就结束了，如果有什么疑问的地方请指出，诸大佬们一起来评论区一起讨论😁
希望能和诸大佬们一起努力，今后我们一起观看感谢您的阅读🍻
如果帮助到您不妨3连支持一下，创造不易您们的支持是我的动力🤞