版权声明：本文为 小异常 原创文章，非商用自由转载-保持署名-注明出处，谢谢！
本文网址：https://blog.csdn.net/sun8112133/article/details/103890936
文章目录
分支管理 是 Git 中非常强大的功能之一，分支管理 意味着我们可以从开发主线上分离开来，然后在不影响主线的同时继续工作。你可以创建一个属于你自己的分支，别人看不到，可以继续工作并且不会影响他人，待开发完毕后，再将自己的分支合并到原来的分支上，这样既安全，又不会影响别人的工作。
一、创建与合并分支
我们之前接触过 master分支（主分支），这条分支是默认存在的，不需要我们来手动创建它。
其实分支就是一条线，它还有一个指针，会指向当前线上的一个版本点（如下图
master）；HEAD只是一个指针，用来指向当前分支，随着你不断的提交，分支线也越来越长，分支上的指针也会向前移动。
若我们在主分支上创建了新的分支
dev，再让HEAD指针指向它，那么就表示dev是当前分支，它不会影响工作区的文件（如下图）。
我们现在提交和修改都会在
dev分支上进行，而master分支上的内容不会进行改变（如下图）。
如果我们在
dev分支上的工作完成了，就可以把dev合并到master上，其实只是将master的指针指向dev所指的版本点即可，就完成了合并，所以说 Git 合并分支是很快的，就改改指针，工作区的内容也不会改变。
合并完成后，再删除
dev分支。
1、创建分支
-
命令
git branch 分支名 -
案例
创建一个名叫
dev的分支。
2、切换分支
-
命令（切换分支）
git switch 分支名 -
命令（创建并切换分支）
git switch -c 分支名 -
案例
切换到分支
dev。
注意：我们还可以使用命令
git switch -c dev创建并切换到dev分支。
3、查看分支
会列出所有分支，当前分支前面会标一个
*号。
1）查看分支列表
-
命令
git branch -
案例
2）查看分支记录
-
命令
--graph：分支会以*的图形方式进行显示。--pretty=oneline：记录会以漂亮的格式显示。--abbrev-commit：会将版本号精简显示。git log --graph --pretty=oneline --abbrev-commit -
案例
4、合并分支
合并分支 需要切换到父分支上。
-
命令
--no-ff：强制禁用Fast forward模式（快速模式），Git 会在merge时生成一个新的commit，这样从历史记录上就能看到分支信息；-m：合并分支时的注释信息。若不加
--no-ff参数时，Git 会默认使用Fast forward模式（快速模式）合并，这种模式会丢掉分支信息。git merge 分支名 [--no-ff -m "注释内容"] -
案例
5、删除分支
删除分支 先要切换到它的父分支上，并且只有在合并成功或刚创建后才可以删除分支，如果该分支修改了内容且没有合并则删除会失败，这时只有强制删除才能删除成功。
-
命令（普通删除）
git branch -d 分支名 -
命令（强制删除）
git branch -D 分支名 -
案例
-
普通删除
-
强制删除
-
二、解决冲突
有这么一种情况，比如在
master分支上修改了一个文件并提交，在dev分支上也对这个文件进行修改并提交，这时候在master分支上合并dev分支时，Git 这时候就无法执行 “快速合并” 了，只能试图把各自的修改合并起来，但这种合并就可能会产生冲突 。解决冲突 的办法就是将 Git 合并失败的文件手动修改成我们希望的内容，再次提交。
当有冲突的时候，进行合并就会提示自动合并失败，在
readme.txt这个文件中有冲突，需要手动解决冲突，再提交（如下图）。
Git 在冲突文件中会用
<<<<<<<、=======、>>>>>>>标记着不同分支的内容。如，
readme.txt文件内容：
当我们手动修改好冲突文件，再次提交。
三、分支管理策略
1、基本原则
在实际开发中，我们应该按照几个 基本原则 进行分支管理：
master分支是仅用来发布新版本的，不建议在此分支上开发；- 一般开发都在
dev分支上，dev分支是开发分支，到了该发布版本的时候，再把dev分支合并到master分支上；- 如果是多人合作，都要在
dev分支上开发，每个人都应该有自己的分支，时不时地往dev分支上合并就可以了；- 每添加一个新的功能，建议新建一个
feature分支，在上面开发，完成后再合并，最后删除这个临时分支（命名建议：feature-代号）；- 当某分支出现 Bug 时，要在该分支上创建一个临时分支，解决 Bug 后，与该分支合并，然后将该分支下的所有子分支复制解决 Bug 的这个版本点，最后删除这个临时分支（命名建议：
分支名-bug代号）。团队合作的分支如下：
2、Bug 分支
在软件开发中，Bug 是经常存在的，遇到 Bug 时，我们一般都会新建一个临时的分支来修复，修复成功后合并到出现该 Bug 的分支上，然后将临时分支删除即可。
1）复制提交
假设我们现在的分支结构有：
master、dev、michael（如下图），若dev分支上出现一个 Bug（代号101），我们需要创建一个dev-101的临时分支来修复它，修复完成后将此分支合并到dev分支上，并删除这条dev-101临时分支。可是因为michael分支是dev分支的子分支，所以 Bug 也存在于michael分支上，所以我们需要将刚才修复成功提交的版本号记录下来，将此提交通过命令git cherry-pick 版本号复制到michael分支上。
2）保存临时内容
若我们还没完成手头工作（也就是还没有提交），需要我们已经去解决该项目中的其他问题，而手头工作没有完成不能进行提交，这个时候我们可以进行临时 “保存现场” ，解决了其他问题后，再进行 “恢复现场”。
a. 保存现场（stash）
Git 会将还没有提交的内容藏到某个位置，将工作区重置成库中的内容。
注意： 没有在 Git 版本库中的文件，是不能被
stash存起来的。
git stash save "注释信息"
b. 查看现场（stash list）
git stash list
c. 恢复现场（stash apply）
git stash apply [现场号]
d. 删除现场（stash drop）
git stash drop [现场号]
e. 恢复并删除现场（stash pop）
git stash pop [现场号]
3、多人协作
1）拉取分支
a. 拉取内容
当我们进行多人协作时，首先是要从远程库上克隆一份到本地，并创建与远程库对应的分支且设置跟踪信息。当第一次克隆时，会自动拉取远程库的内容到本地，如果有其他小伙伴已经对远程库的内容进行了修改推送，那么我们 在推送前必须先拉取最新的内容，再提交。（拉取命令：
git pull）
b. 创建分支并连接远程分支
当克隆远程库后，默认只能看到
master分支，若也想看到dev分支或其他分支，则使用命令：git branch dev origin/dev创建本地dev分支，并连接origin远程端的dev分支。
c. 设置本地某分支跟踪远程某分支
如果没有设置本地某分支跟踪远程某分支时，直接从远程库上拉取内容到本地某分支中，拉取会失败，我们只需要使用 命令：
git branch --set-upstream-to=origin/dev dev来设置跟踪信息即可。
2）推送分支
推送分支，就是把该分支上的所有本地库的提交推送到远程库上。推送时，要指定本地某分支及远程库，这样，Git 就会把该分支推送到远程库对应的远程分支上。
命令：
git push 远程端 分支名
注意： 并不是所有的本地分支都需要推送到远程库上，一般情况
master分支（主分支）和dev分支（开发分支）要与远程库同步，其他分支是否推送看自己的需要而定。
3）工作模式
- 先用
git pull拉取分支，试图与本地内容合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 再用
git push 远程端 分支名推送自己的修改； - 如果推送失败，则可能远程分支比本地分支更新，需要拉取后重新推送
注意： 如果 git pull 的时候，提示 no tracking information ，则说明本地分支没有跟踪远程分支，使用跟踪命令：git branch --set-upstream-to 远程端/远程分支名 本地分支名 。
四、Rebase（变基）
Git 中有种特殊的操作叫做 Rebase（变基），其实这种操作不会对我们的内容做任何的改变，它只是在我们查看历史提交的变化时更容易查看，我们在项目中会大量合并各种分支，导致我们使用
git log查看历史记录时，有很多分叉，不利于我们查看。我们可以将一些历史合并的分叉通过 Rebase 整理成直线，方便我们以后查看历史记录。变基命令：
git rebase
由上图看，有很多合并的分叉。其中
(HEAD -> master)表示当前本地主分支的位置，(origin/dev, dev)表示 origin远程库 中 dev远程分支 和 本地dev分支 的位置，(origin/master, origin/HEAD)表示 origin远程库主分支 的位置。如果项目中有大量这类型的分叉，查看历史记录时很不利于查看，这时可以使用git rebase命令将这些分叉整理成一条直线：
