实用指南：本文章讲述了Git分支管理，以及分支策略。

Git分支

• 分支
• • 分支的本质
  • 分支创建、删除、合并
  • 分支的合并与冲突
  • git stash
• 分支管理策略
• • 主分支
  • 辅助分支

分支

在 Git 中，分支（Branch）是一种轻量级的指针，它的核心作用是帮助开发者在不干扰主线代码的前提下，独立记录和管理代码的修改历史。

为什么得分支？
想象一个场景：正在研发一个项目，主线的代码已经能稳定运行，此时应该制作一个新功能或需要修复一个紧急 bug。如果直接在主线修改，可能会导致主线代码暂时不稳定，甚至影响其他开发者的工作，而分支的出现处理了这个难题，可以从主线分出一个新分支，在这个分支上专注开发，直到能力完成且测试通过后，再将修改合并回主线。这样既保证了主线的稳定性，又实现了并行开发。

分支的本质

Git 分支的本质是一个指向特定提交（commit）的轻量级指针。

Git 初始化仓库时（git init）会默认创建一个主分支，该分支通常命名为 master。这个默认分支与其他分支在本质上没有区别，它们都是指向提交的指针，唯一的特殊性仅在于默认创建这一初始化行为。默认分支最初指向仓库的第一个提交（初始提交），当在该分支上进行提交时，分支指针会自动随新提交向前移动，最终指向该分支的最新提交（即提交链的末端）。

此外，Git 中存在一个特殊的 HEAD 指针，它始终指向当前正在工作的分支。例如，当你在 master 分支上时，HEAD 指向 master 分支，而 master 分支指向其最新提交，形成 “HEAD -> 分支 -> 提交” 的指向关系；若切换到其他分支，HEAD 会转而指向该分支，后续在该分支上的新提交会让分支指针自动前移，始终指向最新的提交。

第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev

进入.git文件夹查看HEAD的内容，所处分支不同，内部的资料指向就不同

若是dev发生修改提交，dev的版本就会向后移动

在master分支上如果进行合并分支就会出现如下图

分支创建、删除、合并

通过 git branch 来查看和创建分支，创建标签记在HEAD指针所指向的提交点创建分支
git branch dev

分支切换到dev分支 git checkout dev

创建分支与切换分支同时完成 git checkout -b dev2

切换到最近一次上一次的分支 git checkout -

在dev2分支创建一个材料A.txt，文件进入工作区，在其他分支上均可看到A.txt文件，且该材料状态均为工作区状态。在dev2分支将记录A.txt添加到暂存区后，在其他分支上也均可看到A.txt文件，且该文件状态均为暂存区状态。

在dev2分支提交A.txt文件至版本库，仅在dev2分支可以看到此记录，当切换到其他分支时则均无法看到此文件。

可以删除一个合并后的或者没有发生变化的分支 git branch -d dev

不能删除自己所在的分支

如果一个分支发生了变化，没有合并不能删除，如果要强制删除可以使用 git branch -D dev2

分支的合并与冲突

切换到master上做dev2 的合并，git merge dev2
发现master分支上也添加了A.txt这个文件

如果修改的是同一个文件也可以做分支合并，通过合并发现master分支上也合并了dev2修改的内容，合并之后dev2的删除就被允许了

此时我们在 dev2 分支里修改 A.txt 资料添加一行 dev2 00001 后提交，在 master 分支里面修改 A.txt 资料同时添加一行 master 00002 后提交

合并的时候发现出现分支冲突

<<<<<<< HEAD 当前指向的分支所修改的内容
======= 分隔线，上下分别是两个分支的冲突内容
>>>>>>> dev2 dev2分支所修改的内容

需要手工合并，根据实际需求，决定保留哪部分内容或整合两者

修改完后，在dev2分支下的A.txt文件内容也跟着更新了

可以通过图形来查看冲突的提交日志 git log --graph

git stash

git stash 是 Git 中用于临时保存工作区和暂存区修改的命令。在当前分支做了一些未完成的修改（不想立即提交），但需要临时切换到其他分支时，可通过 git stash 将这些修改暂存起来，让工作区恢复到干净状态（与最近一次提交一致），方便进行其他操作。

最新的暂存就是在dev分支修改 A.txt、新增 b.txt，git stash 将内容保存至堆栈中，再新增 c.txt，将其添加至暂存区，再将内容保存至堆栈中，栈顶
git stash list 列出堆栈区保存的所有未完毕的任务
git stash pop 出栈，恢复并删除暂存

可以在任意分支上取出并继续完成任务，需要注意的是出栈一个任务并提交后才能够出栈另一个任务

在 master 分支上出栈

分支管理策略

从上图可以看到关键包含下面几个分支：

• master：git默认主分支（这里不作运行）
• stable：稳定分支，替代master，主要用来版本发布
• develop：日常开发分支，该分支正常保存了开发的最新代码
• feature：具体的功能开发分支，只与 develop 分支交互
• release：release 分支可能认为是 stable分支的未测试版
• bugfix：线上 bug 修复分支

在 Git 分支管理中，主分支（Main Branches） 和辅助分支（Supporting Branches） 是两类效果互补的分支，共同支撑项目的研发、测试、发布和维护流程。

主分支

因为master分支大家不作管理，存放可部署到生产环境的稳定代码，针对stable和develop这两个主分支来讲解。
stable分支：用来发布，管理着多个稳定的版本
develop分支：开发阶段的主分支，整合所有已完成的效果研发，是测试环境的代码源
启用这两个分支就具有了最方便的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

辅助分支

从主分支（或其他辅助分支）派生的临时分支，用于隔离特定任务（如开发新功能、修复 bug、准备发布等），任务做完后需合并回目标分支并删除，避免长期存在导致代码混乱。就是辅助分支

Feature分支
feature 分支用来开发具体的功能，一般基于develop分支，最后做完功能后再合并到develop分支。
比如，目前我们针对develop分支来做功能编写，在开发的过程中会有紧急需求需要构建，且在本次版本发布时间之前要能测试完成。我们允许基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。

release分支
release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。
为什么我从develop分支fork出来，还要合并到develop分支中呢？因为大家在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。

bugfix分支
bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。