【Git 小妙招】走进 Git 的分支管理(万字图文讲解)

文章目录

  • 前言
  • 1. 理解分支
  • 2. 创建分支
  • 3. 切换分支
  • 4. 合并分支
  • 5. 删除分支
  • 6. 合并冲突
  • 7. 分支管理策略
    • 7.1 一个简单的分支策略(仅参考)
  • 8. bug 分支
  • 9. 删除临时分支
  • 总结


前言

本文开始介绍 Git 的杀手级功能之⼀:分⽀。本文涉及分⽀创建,切换,合并,删除的整个⽣命周期,灵活进⾏各种场景下的分⽀管理,学习常见分⽀管理策略。

分⽀在实际中有什么⽤呢?假设你准备开发⼀个新功能,但是需要两周才能完成,第⼀周你写了50%的代码,如果⽴刻提交,由于代码还没写完,不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交,⼜存在丢失每天进度的巨⼤⻛险。

现在有了分⽀,就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀,别⼈看不到,还继续在原来的分⽀上正常⼯作,⽽你在⾃⼰的分⽀上⼲活,想提交就提交,直到开发完毕后,再⼀次性合并到原来的分⽀上,这样,既安全,⼜不影响别⼈⼯作。

并且 Git ⽆论创建、切换和删除分⽀,Git 在1秒钟之内就能完成!⽆论你的版本库是1个⽂件还是1万个⽂件。

关注收藏, 开始学习吧🧐


1. 理解分支

分⽀就像是科幻电影里面的平行宇宙,当你正在电脑前努⼒学习 C++ 的时候,另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。

如果两个平⾏宇宙互不⼲扰,那对现在的你也没啥影响。不过,在某个时间点,两个平⾏宇宙合并了,结果,你既学会了 C++ ⼜学会了 JAVA!

在这里插入图片描述
在版本回退⾥,你已经知道,每次提交,Git 都把它们串成⼀条时间线,这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前,只有⼀条时间线,在 Git ⾥,这个分⽀叫主分⽀,即 master 分⽀。

再来理解⼀下 HEAD,HEAD 严格来说不是指向提交,⽽是指向 master,master 才是指向提交的,所以,HEAD 指向的就是当前分⽀。

在这里插入图片描述
每次提交,master 分⽀都会向前移动⼀步,这样,随着你不断提交,master 分⽀的线也越来越⻓,⽽ HEAD 只要⼀直指向 master 分⽀即可指向当前分⽀。

通过查看当前的版本库,我们也能清晰的理出思路:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/HEAD
ref: refs/heads/master
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/refs/heads/master
3c163abc60fe42216426b883671725e1d4c8c8b3

在这里插入图片描述

2. 创建分支

Git ⽀持我们查看或创建其他分⽀,在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ,对应的命令为:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branch
* master
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branch dev
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branchdev
* master

在这里插入图片描述
当我们创建新的分⽀后,Git 新建了⼀个指针叫 dev,* 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外,可以通过⽬录结构发现,新的 dev 分⽀:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# ls .git/refs/heads/
dev  master
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/refs/heads/*
3c163abc60fe42216426b883671725e1d4c8c8b3
3c163abc60fe42216426b883671725e1d4c8c8b3

在这里插入图片描述

发现⽬前 dev 和 master 指向同⼀个修改。并且也可以验证下 HEAD ⽬前是指向 master 的。

在这里插入图片描述

⼀张图总结:

在这里插入图片描述

3. 切换分支

那如何切换到 dev 分⽀下进⾏开发呢?使⽤ git checkout 命令即可完成切换,⽰例如下:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout dev
Switched to branch 'dev'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branch
* devmaster
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/HEAD
ref: refs/heads/dev

在这里插入图片描述
在这里插入图片描述
我们发现 HEAD 已经指向了 dev,就表⽰我们已经成功的切换到了 dev 上!

接下来,在 dev 分⽀下修改 ReadMe ⽂件,新增⼀⾏内容,并进⾏⼀次提交操作:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add .
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "modify ReadMe"
[dev a3aa828] modify ReadMe1 file changed, 1 insertion(+)
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

在这里插入图片描述

现在,dev 分⽀的⼯作完成,我们就可以切换回 master 分⽀:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout master
Switched to branch 'master'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3

切换回 master 分⽀后,发现ReadMe⽂件中新增的内容不⻅了!!!赶紧再切回 dev 看看:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout dev
Switched to branch 'dev'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

可以看出,在 dev 分⽀上,内容还在。为什么会出现这个现象呢?我们来看看 dev 分⽀和 master 分⽀指向,发现两者指向的提交是不⼀样的:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/refs/heads/dev 
a3aa828d6180a7ac269314f29eb5650a70b0c28c
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat .git/refs/heads/master 
3c163abc60fe42216426b883671725e1d4c8c8b3

看到这⾥就能明⽩了,因为我们是在 dev 分⽀上提交的,⽽ master 分⽀此刻的提交点并没有变,此时的状态如图如下所⽰:

在这里插入图片描述

当切换到 master 分⽀之时,HEAD 就指向了 master,当然看不到分支 dev 提交的了!

4. 合并分支

为了在 master 主分⽀上能看到新的提交,就需要将 dev 分⽀合并到 master 分⽀,使用 git merge 操作,⽰例如下:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branch
* devmaster# 切换到 master 上进行
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout master 
Switched to branch 'master'# 合并 dev 分支
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git merge dev
Updating 3c163ab..a3aa828
Fast-forwardReadMe | 1 +1 file changed, 1 insertion(+)
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

在这里插入图片描述
git merge 命令⽤于合并指定分⽀到当前分⽀。合并后,master 就能看到 dev 分⽀提交的内容了。此时的状态如图如下所⽰:

在这里插入图片描述

在这里插入图片描述

Fast-forward 代表“快进模式”,也就是直接把 master 指向 dev 的当前提交,所以合并速度⾮常快。

当然,也不是每次合并都能 Fast-forward,我们后⾯会讲其他⽅式的合并。

5. 删除分支

合并完成后, dev 分⽀对于我们来说就没⽤了, 那么 dev 分⽀就可以被删除掉,使用 git branch -d 命令,注意如果当前正处于某分⽀下,就不能删除当前分⽀,如:

在这里插入图片描述

⽽可以在其他分⽀下删除当前分⽀,如:

在这里插入图片描述

此时的状态如图如下所⽰:

在这里插入图片描述

因为创建、合并和删除分⽀⾮常快,所以 Git ⿎励你使⽤分⽀完成某个任务,合并后再删掉分⽀,这和直接在 master 分⽀上⼯作效果是⼀样的,但过程更安全。

6. 合并冲突

可是,在实际分⽀合并的时候,并不是想合并就能合并成功的,有时候可能会遇到代码冲突的问题。

为了演⽰这问题,创建⼀个新的分⽀ dev1 ,并切换⾄⽬标分⽀,我们可以使⽤ git checkout -b dev1 ⼀步完成创建并切换的动作,⽰例如下:

在这里插入图片描述

dev1 分⽀下修改 ReadMe ⽂件,更改⽂件内容如下,并进⾏⼀次提交,如:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch            # 将 aaa 改为 bbb
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add .
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "modify ReadMe"
[dev1 4d019b2] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)

在这里插入图片描述

切换⾄ master 分⽀,观察 ReadMe ⽂件内容:

在这里插入图片描述

我们发现,切回来之后,⽂件内容由变成了⽼的版本,这种现象很正常,我们现在也完全能理解。

此时在 master 分⽀上,我们对 ReadMe ⽂件再进⾏⼀次修改,并进⾏提交,如下:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branchdev1
* master
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch    # 将 bbb 修改为 ccc
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add .
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "modify ReadMe"
[master f7a9673] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)

在这里插入图片描述
现在, master 分⽀和 dev1 分⽀各⾃都分别有新的提交,变成了这样:

在这里插入图片描述

这种情况下,Git 只能试图把各⾃的修改合并起来,但这种合并就可能会有冲突,如下所⽰:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git status
On branch master
You have unmerged paths.(fix conflicts and run "git commit")(use "git merge --abort" to abort the merge)Unmerged paths:(use "git add <file>..." to mark resolution)both modified:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")

在这里插入图片描述

发现 ReadMe ⽂件有冲突后,可以直接查看⽂件内容,要说的是 Git 会⽤ <<<<<<<,=======,>>>>>>> 来标记出不同分⽀的冲突内容,如下所⽰:

在这里插入图片描述

此时我们必须要⼿动调整冲突代码,并需要再次提交修正后的结果!!(再次提交很重要,切勿忘记)

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add .
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "merge ReadMe"
[master 14d93a6] merge ReadMe

到这⾥冲突就解决完成,此时的状态变成了:

在这里插入图片描述

⽤带参数的 git log 也可以看到分⽀的合并情况,具体⼤家可以⾃⾏搜索 git log 的⽤法:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git log --graph --pretty=oneline --abbrev-commit
*   14d93a6 (HEAD -> master) merge ReadMe
|\  
| * 4d019b2 (dev1) modify ReadMe
* | f7a9673 modify ReadMe
|/  
* a3aa828 modify ReadMe
* 3c163ab deleted file5
* cda844e add version3
* 494c4f1 add version2
* 637f0c6 add version1
* 7c99a33 add modify ReadMe file
* 7e71984 add file5
* 4272545 add file
* 1659312 add 3 files
* aee9eed commit my first file

在这里插入图片描述

最后,不要忘记 dev1 分⽀使⽤完毕后就可以删除了:

在这里插入图片描述

7. 分支管理策略

通常合并分⽀时,如果可能,Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后,形成的合并结果是什么呢?回顾⼀下:

在这里插入图片描述
在这种 Fast forward 模式下,删除分⽀后,查看分⽀历史时,会丢掉分⽀信息,看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分,我们也看到通过解决冲突问题,会再进⾏⼀次新的提交,得到的最终状态为:

在这里插入图片描述

那么这就不是 Fast forward 模式了,这样的好处是,从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀,但依旧能看到 master 其实是由其他分⽀合并得到:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git log --graph --pretty=oneline --abbrev-commit
*   14d93a6 (HEAD -> master) merge ReadMe
|\  
| * 4d019b2 (dev1) modify ReadMe
* | f7a9673 modify ReadMe
|/  
...

Git ⽀持我们强制禁⽤ Fast forward 模式,那么就会在 merge 时⽣成⼀个新的 commit ,这样,从分⽀历史上就可以看出分⽀信息。

下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先,创建新的分⽀ dev2 ,并切换⾄新的分⽀:

在这里插入图片描述

修改 ReadMe ⽂件,并提交⼀个新的 commit :

在这里插入图片描述

切回 master 分⽀,开始合并:

在这里插入图片描述

请注意 --no-ff 参数,表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ,所以加上 -m 参数,把描述写进去。

合并后,查看分⽀历史:

在这里插入图片描述
可以看到,不使⽤ Fast forward 模式,merge 后就像这样:

在这里插入图片描述

所以在合并分⽀时,加上 --no-ff 参数就可以⽤普通模式合并,合并后的历史可以看到分⽀,能看出来曾经做过合并,⽽ fast forward 合并就看不出来曾经做过合并。

7.1 一个简单的分支策略(仅参考)

在实际开发中,我们应该按照⼏个基本原则进⾏分⽀管理:

⾸先,master 分⽀应该是⾮常稳定的,也就是仅⽤来发布新版本,平时不能在上⾯⼲活;

那在哪⼲活呢?⼲活都在 dev 分⽀上,也就是说,dev 分⽀是不稳定的,到某个时候,⽐如1.0版本发布时,再把 dev 分⽀合并到master上,在 master 分⽀发布1.0版本;

你和你的⼩伙伴们每个⼈都在 dev 分⽀上⼲活,每个⼈都有⾃⼰的分⽀,时不时地往 dev 分⽀上合并就可以了。

所以,团队合作的分⽀看起来就像这样:

在这里插入图片描述

8. bug 分支

假如我们现在正在 dev2 分⽀上进⾏开发,开发到⼀半,突然发现 master 分⽀上⾯有 bug,需要解决。在Git中,每个 bug 都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀,然后将临时分⽀删除。

可现在 dev2 的代码在⼯作区中开发了⼀半,还⽆法提交,怎么办?例如:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branchdev2
* master
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout dev2
Switched to branch 'dev2'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version
write bbb for new branch
a,b,c,d
i am coding...
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git status
On branch dev2
Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")

在这里插入图片描述

Git 提供了 git stash 命令,可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。

在这里插入图片描述
再⽤ git status 查看⼯作区,就是⼲净的(除⾮有没有被 Git 管理的⽂件),因此可以放⼼地创建分⽀来修复 bug。

储藏 dev2 ⼯作区之后,由于我们要基于 master 分⽀修复 bug,所以需要切回 master 分⽀,再新建临时分⽀来修复 bug,⽰例如下:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout master
Switched to branch 'master'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout -b fix_bug
Switched to a new branch 'fix_bug'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version
write bbb for new branch
a,b,c,d,e
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "fix bug"
[fix_bug 3c8ad5a] fix bug1 file changed, 1 insertion(+), 1 deletion(-)

在这里插入图片描述

修复完成后,切换到 master 分⽀,并完成合并,最后删除 fix_bug 分⽀:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git checkout master
Switched to branch 'master'
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git merge --no-ff -m "merge fix_bug branch" fix_bug
Merge made by the 'ort' strategy.ReadMe | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version
write bbb for new branch
a,b,c,d,e
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git branch -d fix_bug
Deleted branch fix_bug (was 3c8ad5a).

⾄此,bug 的修复⼯作已经做完了,我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀:

在这里插入图片描述

看到⼯作区是⼲净的,刚才的⼯作现场存到哪去了?⽤ git stash list 命令看看:

在这里插入图片描述

⼯作现场还在,Git 把 stash 内容存在某个地⽅了,但是需要恢复⼀下,如何恢复现场呢?我们可以使⽤ git stash pop 命令,恢复的同时会把 stash 也删了,⽰例如下:

在这里插入图片描述

再次查看的时候,我们已经发现已经没有现场可以恢复了.

在这里插入图片描述
另外,恢复现场也可以采⽤ git stash apply 恢复,但是恢复后,stash内容并不删除,你需要⽤ git stash drop 来删除;

你也可以进行多次 stash,恢复的时候,先⽤ git stash list 查看,然后恢复指定的 stash,⽤命令 git stash apply stash@{0} , 这部分请读者⾃⾏查看使⽤。

恢复完代码之后我们便可以继续完成开发,开发完成后便可以进⾏提交,例如:

root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# vim ReadMe
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# cat ReadMe
hello git
hello git
hello world
hello version1
hello version2
hello version
write bbb for new branch
a,b,c,d
i am coding...Done!
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git add .
root@iZ0jlic9afdpgvpfnm8g32Z:~/gitcode# git commit -m "modify ReadMe"
[dev2 6ed3cb6] modify ReadMe1 file changed, 1 insertion(+)

但我们注意到了,修复 bug 的内容,并没有在 dev2 上显⽰。此时的状态图为:

在这里插入图片描述
master 分⽀⽬前最新的提交,是要领先于新建 dev2 时基于的 master 分⽀的提交的,所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。

我们的最终⽬的是要让 master 合并 dev2 分⽀的,那么正常情况下我们切回 master 分⽀直接合并即可,但这样其实是有⼀定⻛险的。

是因为在合并分⽀时可能会有冲突,⽽代码冲突需要我们⼿动解决(在 master 上解决)。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉,因为在实际的项⽬中,代码冲突不只⼀两⾏那么简单,有可能⼏⼗上百⾏,甚⾄更多,解决的过程中难免⼿误出错,导致错误的代码被合并到 master 上。

此时的状态为:

在这里插入图片描述

解决这个问题的⼀个好的建议就是:最好在⾃⼰的分⽀上合并下 master ,再让 master 去合并 dev ,这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试,⽽不影响 master 。此时的状态为:

在这里插入图片描述
在这里插入图片描述

对应的实操演⽰如下,要说明的是,以下演⽰的 merge 操作,没有使⽤ --no-ff ,但上述的图⽰是禁⽤ Fast forward 了模式后得出的,主要是为了⽅便解释问题。

1. dev 合并 master

在这里插入图片描述

2. 发生冲突

在这里插入图片描述

3. 解决冲突并重新提交

在这里插入图片描述

4. 切回 master

在这里插入图片描述

5. master 合并 dev2 (无需解决冲突)

在这里插入图片描述

6. 删除 dev2 分支

在这里插入图片描述

9. 删除临时分支

软件开发中,总有⽆穷⽆尽的新的功能要不断添加进来。

添加⼀个新功能时,你肯定不希望因为⼀些实验性质的代码,把主分⽀搞乱了,所以,每添加⼀个新功能,最好新建⼀个分⽀,我们可以将其称之为 feature 分⽀,在上⾯开发,完成后,合并,最后,删除该 feature 分⽀。

可是,如果我们今天正在某个 feature 分⽀上开发了⼀半,被产品经理突然叫停,说是要停⽌新功能的开发。虽然⽩⼲了,但是这个 feature 分⽀还是必须就地销毁,留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下:

1. 新增并切换到 dev3 分支

在这里插入图片描述

2. 开始开发新功能并提交

在这里插入图片描述

3. 此时新功能叫停

4. 切回 master 准备删除 dev3

在这里插入图片描述

5. 常规删除 dev3 分支时失败

在这里插入图片描述

直接使⽤传统的删除分⽀的⽅法不⾏,按照提⽰,有了如下⽅式:

在这里插入图片描述

删除成功!


总结

✨ 本文介绍了 Git 的一个杀手级功能 — 分⽀。涉及到分⽀创建,切换,合并,删除的整个⽣命周期,灵活进⾏各种场景下的分⽀管理,学习常见分⽀管理策略,读者可收藏后进行反复阅读,建议跟着文章一起实践操作一下。
✨ 想了解更多知识, 请持续关注博主, 本人会不断更新学习记录, 跟随我一起不断学习 -> 跳转Git专栏.
✨ 感谢你们的耐心阅读, 博主本人也是一名学生, 也还有需要很多学习的东西. 写这篇文章是以本人所学内容为基础, 日后也会不断更新自己的学习记录, 我们一起努力进步, 变得优秀, 小小菜鸟, 也能有大大梦想, 关注我, 一起学习.

再次感谢你们的阅读, 你们的鼓励是我创作的最大动力!!!!!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/218394.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

16:00的面试,16:07就出来了,问的问题过于变态了。。。

从小厂出来&#xff0c;没想到在另一家公司又寄了。 到这家公司开始上班&#xff0c;加班是每天必不可少的&#xff0c;看在钱给的比较多的份上&#xff0c;就不太计较了。没想到六月一纸通知&#xff0c;所有人不准加班&#xff0c;加班费不仅没有了&#xff0c;薪资还要降40…

园区网络虚拟化应该这样建

下午好&#xff0c;我的网工朋友。 今天和你聊聊怎么建立园区网络虚拟化。 区别于传统园区关注独立的单台设备&#xff0c;虚拟化网络关注全网的整体业务体验&#xff0c;通过iMaster NCE-Campus和VXLAN技术&#xff0c;实现网络资源能够任意灵活调度。 通过虚拟化技术&…

【Redis】深入理解 Redis 常用数据类型源码及底层实现(1.结构与源码概述)

在文章【Redis】不卡壳的 Redis 学习之路&#xff1a;从十大数据类型开始入手中我们介绍了Redis常用的10大数据类型&#xff0c;这10大数据类型可并不是直接在底层通过代码实现的&#xff0c;而是通过不同的底层数据结构组合起来的&#xff0c;这篇我们介绍下Redis常用数据类型…

CSAPP——linux下的 status 函数及进程退出/进程回收详解

status函数是一个系统调用&#xff0c;用于获取子进程的退出状态。它通常在父进程中使用&#xff0c;以便检查子进程是否正常退出或出现错误。 status函数的原型如下&#xff1a; int waitpid(pid_t pid, int *status, int options); pid参数指定要等待的子进程的进程ID stat…

网络安全这条路,如何打怪升级干掉大Boss?

企业对网络安全的重视是挂在嘴上还是落实在行动中&#xff1f;网络安全人员岗位设置是否合理而有效&#xff1f;网络安全从业者最需要什么样的技能培训&#xff1f;网络安全从业者的职业发展路径应该如何规划&#xff1f;一份“网络安全从业人员现状调查”报告&#xff0c;解你…

与OA完美契合的开放式低代码平台

随着企业数字化转型的加速&#xff0c;越来越多的企业开始寻求能够快速适应业务需求变化、降低IT成本、提高运营效率的信息系统解决方案。OA作为面向企业日常办公需求的信息系统&#xff0c;在提高企业内部协作效率、优化业务流程、降低运营成本方面具有重要的作用。 它涵盖了…

山西电力市场日前价格预测【2023-12-13】

日前价格预测 预测说明&#xff1a; 如上图所示&#xff0c;预测明日&#xff08;2023-12-13&#xff09;山西电力市场全天平均日前电价为331.79元/MWh。其中&#xff0c;最高日前电价为371.77元/MWh&#xff0c;预计出现在11:15。最低日前电价为280.66元/MWh&#xff0c;预计…

OpenHarmony 如何去除系统锁屏应用

前言 OpenHarmony源码版本&#xff1a;4.0release / 3.2 release 开发板&#xff1a;DAYU / rk3568 一、3.2版本去除锁屏应用 在源码根目录下&#xff1a;productdefine/common/inherit/rich.json 中删除screenlock_mgr组件的编译配置&#xff0c;在rich.json文件中搜索th…

Vue中使用echarts@4.x中国地图及AMap相关API的使用

一、此 demo 实现的基本功能 1.中国地图的显示 2.地图点击下钻的功能 3.地图相关组件的使用&#xff0c;例 tooltip… 二、实现思路 初始使用下载本地的中国 geo 格式的 json 数据来绘制地图&#xff0c;点击某一区划&#xff08;例&#xff1a;山东省&#xff09;时&#xff0…

【计算机设计大赛】冬残奥会可视化系统_附源码—信息可视化赛道获奖项目深入剖析【可视化项目案例-19】

🎉🎊🎉 你的技术旅程将在这里启航! 记得看本专栏里顶置的可视化宝典导航贴哦! 🚀🚀 本专栏为可视化专栏,包含现有的所有可视化技术。订阅专栏用户在文章底部可下载对应案例完整源码以供大家深入的学习研究。 🎓 每一个案例都会提供完整代码和详细的讲解,不论你…

linux(6):linux用户和权限

在linux基础命令第五弹中http://t.csdnimg.cn/Fu5cJ我们学到了关于如何查看命令选项的帮助手册&#xff0c;到此&#xff0c;基础命令的学习先告一段落&#xff0c;我们来学习linux有关用户和权限的问题&#xff0c;这是很有必要的&#xff0c;如果任何人都可以修改我们的文件内…

数据结构 | 查漏补缺之顺式存储和链式存储、如何评价哈希函数的好坏、链地址法、树的遍历、关键路径、完全图、连通图、迪杰斯特拉、b树

目录 顺式存储和链式存储 优缺点比较 顺序存储 ​编辑 链式存储 如何评价哈希函数的好坏 简述哈希查找中链地址法解决冲突的方法 树的遍历 关键路径 完全图 连通图 迪杰斯特拉 b树 特点&#xff1a; 插入&#xff08;索引不能大于&#xff1a;最大为 M-1 个&#…

拼接不同文件夹中同名图片的方法

有时候为了方便对比不同文件夹中同名图片&#xff0c;需要拼接在一起&#xff0c;这里提供一个拼接方法&#xff0c;当然不同命文件也可以实现拼接&#xff0c;稍微改改就能实现 如下图&#xff0c;在文件夹中有五个文件夹中的图片需要拼接&#xff0c;拼接后的图片存放在img_…

Spark RDD的转换

按颜色区分转换&#xff1a; 绿色是单 RDD 窄依赖转换黑色是多 RDD 窄依赖转换紫色是 KV 洗牌型转换黄色是重分区转换蓝色是特例的转换 单 RDD 窄依赖转换 MapPartitionRDD 这个 RDD 在第一次分析中已经分析过。简单复述一下&#xff1a; 依赖列表&#xff1a;一个窄依赖&…

日历管理:应对金融服务行业数据调度的复杂挑战

在当今快速发展的金融服务行业中&#xff0c;数据管理和调度的复杂性日益增加。在金融服务公司面临着多元化的挑战&#xff0c;这些挑战不仅涉及技术层面&#xff0c;还包括安全、运维和业务流程的优化。 日历管理在工作流调度中看似是一个较小的功能&#xff0c;但对于许多企业…

cmake的下载及安装

文章目录 下载安装 下载 cmake官网下载 进入 v3.22版本目录下。或者直接点击https://cmake.org/files/v3.22/进入&#xff0c;省略上面的步骤 浏览器上下载太慢&#xff0c;这里选择在Linux上通过wget方式下&#xff0c;不过下载速度也不是它快。主要是软件所在的服务器在国…

数据质量管理软件行业分析:2023年复合增长率达到31.9%

数据质量管理软件按照一般的功能模块划分可以划分为产品信息管理、存货管理、销售管理、采购管理、生产管理、设备管理、实验室管理、品质管理、售后管理等模块&#xff0c;质量管理绝非仅仅检验&#xff0c;或者常说的批检、巡检、首检、自检等&#xff0c;质量管理是对只要影…

串行计时芯片D1380/D1381,2.0V~5.5V 工作电流: 2V时 与TTL 兼容,采用DIP8、SOP8封装

D1380/D1381是一个带秒、分、时、日、日期、月、年的串行时钟保持芯片,每个月多少天以及闰年能自动调节, D1380/D1381低功耗工作方式, D1380/D1381用若干寄存器存储对应信息&#xff0c;一个32.768kHz 的晶振校准时钟&#xff0c;为了使用最小弓|脚&#xff0c;D1380/D1381使用…

论文润色会被认为是代写吗知乎 神码ai

大家好&#xff0c;今天来聊聊论文润色会被认为是代写吗知乎&#xff0c;希望能给大家提供一点参考。 以下是针对论文重复率高的情况&#xff0c;提供一些修改建议和技巧&#xff1a; 标题&#xff1a;论文润色会被认为是代写吗――探讨论文润色与代写的关系 一、引言 在学术研…

bugku -- 网站被黑--本地管理员

dirsearch 或者御剑扫目录 扫出来有个登录页面 然后bp抓包爆破密码 扫出来密码是heck登录就行了 构造x-forwarded-for:127.0.0.1 本地登录&#xff1a; 爆破账号 密码是text123 下面的base64解码可以知道