文章目录
- 一、理解分支
- 二、创建、切换、合并分支
- 三、删除分支
- 四、合并冲突
- 五、合并模式
- 六、分支策略
- 七、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 [分支名]
,但是注意:不能在当前分支上删除当前分支,必须要进行分支的切换!!!