文章目录
- 一、理解分支
- 二、创建、切换、合并分支
- 三、删除分支
- 四、合并冲突
- 五、合并模式
- 六、分支策略
- 七、bug分支
- 八、强制删除分支
努力经营当下 直至未来明朗！
一、理解分支
-
HEAD指向的是master分支，master中指向的是最新一次的提交，也就是master中存储得到最新一次提价的commit_id。
-
在gitcode仓库底下，
cat .git/refs/heads/master就可以打印出master中的内容，即最新一次提交的commit_id。
git cat-file -p [commit_id]就可以打印出该commit_id的相关信息
-
master主分支：其实就相当于是每次提交的结果锁串成的线。
二、创建、切换、合并分支
- 查看当前本地仓库有哪些分支：
git branch - HEAD其实是可以指向其他分支的，被指向的分支就是当前正在工作的分支。
- master就说明当前工作的分支就是master
-
创建本地分支：
git branch [分支名]
-
新建的分支是指向创建该分支的时候所站的版本上的，即该版本的commit_id
-
切换分支，重新设置当前的工作分支，即HEAD指向新的分支
git checkout [分支名]
-
在dev分支上提交的内容在master分支上找不到，因为master和dev分支都是指向在各自分支上的最新提交。
-
合并分支：首先看目前在哪个分支上
git branch-> 切换到想要合并到的分支上git checkout [分支名]-> 合并分支git merge [被合并的分支]-> 此时该分支就指向了被合并分支的最新一次提交
（fast-forward是快速模式）
三、删除分支
-
在合并了分支之后，被合并的分支就可以被删除了
git branch -d [要删除的分支]
-
注意：只能在其他分支上删除该分支，本分支上不能删除本分支。
-
因为创建、合并和删除分支非常快，所以Git鼓励使用分支完成某个任务，合并后再删除分支，这和直接在master分支上工作的效果是一样的，但是过程更安全。
四、合并冲突
-
在merge合并分支的时候是可能出现冲突的。
-
如果相对分支A上的某个文件file中的内容进行升级，此时就需要重新创建一个分支B对文件file中的内容进行修改，而与此同时分支A也对文件file中的内容进行了修改；而分支B最后是要合并到分支A上的，此时就会出现合并冲突问题。
-
创建一个分支并将当前分支切换到新分支上
git checkout -b [新分支] -
git add .将当前目录下的所有修改提交到暂存区 -
不同分支对同一个文件修改之后进行分支的合并，此时就会出现合并冲突
-
vim [文件名] 可以进入文件查看冲突内容，其中 <<< >>>中的内容即是冲突内容。
-
想要保留的是什么内容是由开发人员决定的，所以开发人员就要进行手动修改文件内容并进行保存，然后重新进行add和commit，此时保存的就是解冲突之后的结果。
-
解完冲突并合并分支，master存储的是最新一次的提交，即接完冲突之后的提交
-
git log搭配参数的使用
git log --graph --abbrev-commit将提交commit进行图视化
五、合并模式
-
fast forward模式（ff模式）进行合并分支，使用该种模式合并分支的时候，master会指向最新合并的分支指向的commit_id，也就分不清该次提交是merge还是正常commit来的。
-
no-ff模式：可以更加方便地追溯到此次的提交的是merge进来的还是正常commit，方便追溯到对应的人。（推荐使用）
git merge --no-ff -m "描述信息" [被合并的分支名]
六、分支策略
master分支是稳定的，一般用于存储线上环境的代码。
七、bug分支
- 当线上环境（即master主分支）上出现bug的时候，不要直接在master主分支上进行修改，而是在本地专门创建一个修复master分支上bug的分支，然后测试团队测试之后再将该代码分支合并到master主分支上。
- 不能在master主分支上直接进行bug修复的原因：可能改出更大的bug，对线上环境影响较大。
- 模拟环境：开发在dev2分支上开发了部分代码，但是还未提交，此时master主分支上出现了bug。此时需要新建一个专门的修复bug的分支来修复bug，则首先切到master分支上来新建一个修复bug的分支。
1）dev2分支上修改的代码在master分支的工作区中出现，即影响了master分支。
2）不想影响master分支，此时将当前分支切换到dev2分支上，并将工作区中的内容进行储存操作git stash-> 可以使用tree .git/进行查看，发现多了refs/stash来存储工作区中的内容 -> 此时工作区中就是干净的
3）stash中存储的是已经被git追踪管理的内容。因为file3并没有提交到git中被git追踪管理，所以是不能在stash中进行存储的，即git stash命令不可用。
4）此时就切换到master分支上新建一个修复bug的分支 -> 并对有bug的文件进行修改，修改完成之后提交到该分支上 -> 切换到master主分支上并将修复分支上的代码合并到master主分支上
5）dev2分支还没有开发完成，此时就需要切换回dev2分支继续进行开发，但是cat 该文件之后发现该文件中之前开发了部分的代码不见了，这些内容已经被放到了stash中进行存储 -> 此时就需要将stash中的内容恢复到该dev2分支的该文件中进行继续开发
① git stash list 可以查看当前stash中存储的内容
② git stash pop 可以将stash中存储的内容恢复到该分支的文件中
6）此时就可以继续对dev2分支进行开发，开发完成之后就可以对代码进行提交，但是此时的状态如下，直接将dev2分支合并到master分支上可能会存在冲突
7）为了避免将dev2分支合并到master主分支之后影响master住分支，就将master主分支合并到dev2分支上，这样合并后即使有问题也可以在本地分支dev2上进行多次修改测试，不会影响master主分支中的代码 -> 将问题在dev2分支上解决完之后再将代码合并到master主分支上
8）修复并合并完分支之后就可以将该修复分支进行删除了
git branch -d [分支名]
八、强制删除分支
- 在分支A已经被merge了之后想要删除分支A：
git branch -d [分支A] - 若分支B还没有被merge过，此时直接该分支B是受保护的，不能直接使用
git branch -d [分支B]进行删除。 - 如果想要删除还没有被合并的分支每次是就需要强心进行删除，即
git branch -D [分支名]，但是注意：不能在当前分支上删除当前分支，必须要进行分支的切换！！！
