当前位置：首页 > news >正文

认证空间官方网站/成都网站建设团队

news 文章来源：https://blog.csdn.net/weixin_54150521/article/details/132288178 2025/2/22 2:55:50

认证空间官方网站,成都网站建设团队,做网站多久能盈利,网站做301重定向怎么做文章目录一、理解分支二、创建、切换、合并分支三、删除分支四、合并冲突五、合并模式六、分支策略七、bug分支八、强制删除分支努力经营当下直至未来明朗！ 一、理解分支 HEAD指向的是master分支，master中指向的是最新一次的提交，也就是m…

文章目录

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