Git分支管理

目录1. 分支管理1.1 理解分支1.2 创建分支1.3 切换分支1.4 合并分支1.5 删除分支1.6 合并冲突1.7 分支管理策略1.8 分支策略1.9 bug 分支1.10 删除临时分支小结正文开始1. 分支管理1.1 理解分支分支就是科幻电影里面的平行宇宙当你正在电脑前努力学习 C 的时候另⼀个你正在另⼀个平行宇宙里努力学习 JAVA。如果两个平行宇宙互不干扰那对现在的你也没啥影响。不过在某个时间点两个平行宇宙合并了结果你既学会了 C 又学会了 JAVA在版本回退里你已经知道每次提交Git都把它们串成⼀条时间线这条时间线就可以理解为是⼀个分支。截止到目前只有⼀条时间线在Git⾥这个分支叫主分支即 master 分支。再来理解⼀下HEADHEAD 严格来说不是指向提交而是指向mastermaster才是指向提交的所以HEAD 指向的就是当前分支。每次提交master分支都会向前移动⼀步这样随着你不断提交master分支的线也越来越长,而HEAD只要⼀直指向master分支即可指向当前分支。通过查看当前的版本库我们也能清晰的理出思路:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/HEAD ref: refs/heads/master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/refs/heads/master 5476bdeb12510f7cd72ac4766db7988925ebd3021.2 创建分支Git 支持我们查看或创建其他分支在这里我们来创建第⼀个自己的分支 dev 对应的命令为ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch #查看当前本地所有分⽀ * master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch dev #新建分⽀dev ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch dev * master当我们创建新的分支后Git 新建了⼀个指针叫 dev * 表示当前 HEAD 指向的分支是 master 分支。另外可以通过目录结构发现新的 dev 分支ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ ls .git/refs/heads/ dev master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/refs/heads/* 5476bdeb12510f7cd72ac4766db7988925ebd302 5476bdeb12510f7cd72ac4766db7988925ebd302发现目前 dev 和 master 指向同⼀个修改。并且也可以验证下 HEAD 目前是指向 master 的。ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/HEAD ref: refs/heads/master⼀张图总结1.3 切换分支那如何切换到 dev 分支下进行开发呢使用git checkout命令即可完成切换示例如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout dev Switched to branch dev ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/HEAD ref: refs/heads/dev我们发现 HEAD 已经指向了 dev就表示我们已经成功的切换到了 dev 上接下来在 dev 分支下修改 ReadMe 文件新增⼀行内容并进行⼀次提交操作ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ vim ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write aaa for new branch ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe [dev 3740dce] modify ReadMe 1 file changed, 1 insertion()现在dev 分支的⼯作完成我们就可以切换回 master 分支ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3切换回 master 分支后发现ReadMe文件中新增的内容不见了赶紧再切回 dev 看看:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout dev Switched to branch dev ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write aaa for new branch在 dev 分支上内容还在。为什么会出现这个现象呢我们来看看 dev 分⽀和 master 分支指向发现两者指向的提交是不⼀样的ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/refs/heads/dev bdaf528ffbb8e05aee34d37685408f0e315e31a4 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat .git/refs/heads/master 5476bdeb12510f7cd72ac4766db7988925ebd302看到这里就能明白了因为我们是在dev分支上提交的而master分⽀此刻的提交点并没有变此时的状态如图如下所示。当切换到 master 分支之时HEAD 就指向了 master当然看不到提交了1.4 合并分支为了在 master 主分支上能看到新的提交就需要将 dev 分支合并到master分支示例如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master # 切换到 master 上进⾏合并 Switched to branch master hyb139-159-150-152:~/gitcode$ git merge dev # 合并 dev 分⽀ Updating 16623e1..3740dce Fast-forward ReadMe | 1 1 file changed, 1 insertion() ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write aaa for new branchgit merge 命令用于合并指定分支到当前分支。合并后master 就能看到 dev 分支提交的内容了。此时的状态如图如下所示Fast-forward 代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度非常快。当然也不是每次合并都能 Fast-forward。1.5 删除分支合并完成后, dev 分支对于我们来说就没用了 那么dev分支就可以被删除掉注意如果当前正处于某分支下就不能删除当前分支如ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d dev error: Cannot delete branch dev checked out at /home/hyb/gitcode而可以在其他分支下删除当前分支如ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d dev Deleted branch dev (was bdaf528). ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * master此时的状态如下图所示因为创建、合并和删除分支非常快所以Git鼓励你使用分支完成某个任务合并后再删掉分支这和直接在master分支上工作效果是一样的但过程更安全。1.6 合并冲突可是在实际分支合并的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题。为了演示这问题创建一个新的分支 dev1 并切换至目标分至我们可以使用git checkout - b dev1一步完成创建并切换的动作示例如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout -b dev1 Switched to a new branch dev1 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev1 master在 dev1 分支下修改ReadMe 文件更改文件内容如下并进行一次提交如ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch # 将 aaa 该为 bbb ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe [dev1 0854245] modify ReadMe 1 file changed, 1 insertion(), 1 deletion(-)切换至 master 分支观察 ReadMe 文件内容ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write aaa for new branch我们发现切回来之后文件内容由变成了老的版本这种现象很正常我们现在也完全能理解。此时在 master 分支上我们对 ReadMe 文件再进行一次修改并进行提交如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch dev1 * master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ vim ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write ccc for new branch ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe [master c10f6d0] modify ReadMe 1 file changed, 1 insertion(), 1 deletion(-)现在 master 分支和dev1 分支各自都分别有新的提交变成了这样这种情况下Git 只能试图把各自的修改合并起来但这种合并就可能会有冲突如下所示ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git merge dev1 Auto-merging ReadMe CONFLICT (content): Merge conflict in ReadMe Automatic merge failed; fix conflicts and then commit the result. ztlhcss-ecs-c91e:~/Linux/linux/26_0410/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: ReadMe no changes added to commit (use git add and/or git commit -a)发现 ReadMe 文件有冲突后可以直接查看文件内容要说的是 Git 会用 来标记出不同分支的冲突内容如下所示ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 HEAD write ccc for new branch write bbb for new branch dev1此时我们必须要手动调整冲突代码并需要再次提交修正后的结果再次提交很重要切勿忘记ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmerge ReadMe [master 2976afc] merge ReadMe到这里冲突就解决完成此时的状态变成了用带参数的 git log也可以看到分支的合并情况具体可以自行搜索 git log 的用法:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git log --graph --prettyoneline --abbrev -commit * 2976afc (HEAD - master) merge ReadMe |\ | * c594fd1 (dev1) modify ReadMe * | c10f6d0 modify ReadMe |/最后不要忘记 dev1 分支使用完毕后就可以删除了ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d dev1 Deleted branch dev1 (was c594fd1).1.7 分支管理策略通常合并分支时如果可能Git 会采用 Fast forward 模式。那如果我们采⽤Fast forward模式之后形成的合并结果是什么呢回忆⼀下在这种 Fast forward 模式下删除分支后查看分支历史时会丢掉分支信息看不出来最新提交到底是 merge 进来的还是正常提交的。但在合并冲突部分我们也看到通过解决冲突问题会再进行一次新的提交得到的最终状态为那么这就不是 Fast forward 模式了这样的好处是从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支但依旧能看到 master 其实是由其他分支合并得到ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git log --graph --prettyoneline --abbrev -commit * 2976afc (HEAD - master) merge ReadMe |\ | * c594fd1 modify ReadMe * | c10f6d0 modify ReadMe |/Git 支持我们强制禁用 Fast forward 模式那么就会在 merge 时生成⼀个新的 commit 这样从分支历史上就可以看出分支信息。下面我们实战一下--no-ff方式的git merge。首先创建新的分支 dev2 并切换至新的分支:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout -b dev2 Switched to a new branch dev2修改 ReadMe 文件并提交⼀个新的commit:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe [dev2 41b082f] modify ReadMe 1 file changed, 1 insertion()切回 master 分支开始合并:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git merge --no-ff -m merge with no-ff dev2 Merge made by the recursive strategy. ReadMe | 1 1 file changed, 1 insertion() ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d请注意--no-ff参数表示禁用Fast forward模式。禁用Fast forward 模式后合并会创建一个新的 commit 所以加上-m参数把描述写进去。合并后查看分支历史ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git log --graph --prettyoneline --abbrev -commit * 5bd16b4 (HEAD - master) merge with no-ff |\ | * 41b082f (dev2) modify ReadMe |/可以看到不使用 Fast forward 模式merge后就像这样所以在合并分支时加上--no-ff参数就可以用普通模式合并合并后的历史有分支能看出来曾经做过合并而 fast forward 合并就看不出来曾经做过合并。1.8 分支策略在实际开发中我们应该按照几个基本原则进行分支管理首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活那在哪干活呢干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到master上在master分支发布1.0版本你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。所以团队合作的分支看起来就像这样1.9 bug 分支假如我们现在正在 dev2分支上进行开发开发到一半突然发现master 分支上面有 bug需要解决。在Git中每个 bug 都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支删除。可现在 dev2 的代码在工作区中开发了一半还无法提交怎么办例如ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev2 master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d i am coding ... ztlhcss-ecs-c91e:~/Linux/linux/26_0410/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: ReadMe no changes added to commit (use git add and/or git commit -a)Git 提供了git stash命令可以将当前的工作区信息进行储藏被储藏的内容可以在将来某个时间恢复出来。ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git stash Saved working directory and index state WIP on dev2: 41b082f modify ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git status On branch dev2 nothing to commit, working tree clean⽤git status查看工作区就是干净的除非有没有被 Git 管理的文件因此可以放心地创建分 支来修复bug。储藏 dev2 工作区之后由于我们要基于master分支修复 bug所以需要切回master 分支再新 建临时分支来修复 bug示例如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master # 切回master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分⽀ Switched to a new branch fix_bug ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ vim ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e # 修复bug--忘记写e ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add ReadMe # 重新addcommit ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mfix bug [fix_bug 4bbc0c4] fix bug 1 file changed, 1 insertion(), 1 deletion(-)修复完成后切换到 master分支并完成合并最后删除fix_bug 分支ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git merge --no-ff -mmerge fix_bug branch fix_bug Merge made by the recursive strategy. ReadMe | 2 - 1 file changed, 1 insertion(), 1 deletion(-) ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d fix_bug Deleted branch fix_bug (was 4bbc0c4).至此bug 的修复工作已经做完了我们还要继续回到 dev2分支进行开发。切换回dev2 分支ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout dev2 Switched to branch dev2 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git status On branch dev2 nothing to commit, working tree clean工作区是干净的刚才的工作现场存到哪去了用git stash list命令看看ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git stash list stash{0}: WIP on dev2: 41b082f modify ReadMe工作现场还在Git 把 stash 内容存在某个地方了但是需要恢复一下如何恢复现场呢我们可以使用git stash pop命令恢复的同时会把 stash 也删了示例如下ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git stash pop 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: ReadMe no changes added to commit (use git add and/or git commit -a) Dropped refs/stash{0} (4f873250b3503687b5efd26196776aee7e3724c2)再次查看的时候我们已经发现已经没有现场可以恢复了ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git stash list ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$另外恢复现场也可以采用git stash apply恢复但是恢复后stash内容并不删除你需要用git stash drop来删除你可以多次stash恢复的时候先用git stash list查看然后恢复指定的stash用命令git stash apply stash{0},这部分请读者自行使用。恢复完代码之后我们便可以继续完成开发开发完成后便可以进行提交例如ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d i am coding ... Done! ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe [dev2 ed0916d] modify ReadMe 1 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 了模式后得出的主要是为了方便解释问题。# dev 合并 master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * dev2 master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git merge master Auto-merging ReadMe CONFLICT (content): Merge conflict in ReadMe Automatic merge failed; fix conflicts and then commit the result. # 发⽣冲突 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch HEAD a,b,c,d i am coding ... Done! a,b,c,d,e master # 解决冲突并重新提交 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ vim ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e i am coding ... Done! ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmerge master [dev2 447d29f] merge master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git status On branch dev2 nothing to commit, working tree clean # 切回master ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master # master 合并 dev2---⽆需解决冲突 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git merge dev2 Updating 193421f..447d29f Fast-forward ReadMe | 1 1 file changed, 1 insertion() ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git status On branch master nothing to commit, working tree clean # 删除 dev2 分⽀ ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d dev2 Deleted branch dev2 (was 447d29f).1.10删除临时分支软件开发中总有无穷无尽的新的功能要不断添加进来。添加一个新功能时你肯定不希望因为一些实验性质的代码把主分支搞乱了所以每添加一个新功能最好新建一个分支我们可以将其称之为 feature 分支在上面开发完成后合并最 后删除该 feature 分支。可是如果我们今天正在某个 feature 分支上开发了一半被产品经理突然叫停说是要停止新功 能的开发。虽然白干了但是这个 feature分支还是必须就地销毁留着无用了。这时使用传统的git branch -d命令删除分⽀的方法是不不的。演示如下# 新增并切换到 dev3 分⽀ ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout -b dev3 Switched to a new branch dev3 # 开始开发新功能并提交 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ vim ReadMe ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ cat ReadMe hello git hello ztl hello world hello version1 hello version2 hello version3 write bbb for new branch a,b,c,d,e i am coding ... Done! i am writing new features ... ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git add . ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git commit -mmodify ReadMe for new features [dev3 cd2f149] modify ReadMe for new features 1 file changed, 1 insertion() # 此时新功能叫停 # 切回master准备删除dev3 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git checkout master Switched to branch master # 常规删除dev3分⽀时失败 ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -d dev3 error: The branch dev3 is not fully merged. If you are sure you want to delete it, run git branch -D dev3.直接使用传统的删除分支的方法不行按照提示有了如下方式:ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch -D dev3 Deleted branch dev3 (was cd2f149). ztlhcss-ecs-c91e:~/Linux/linux/26_0410/gitcode$ git branch * master小结分支在实际中有什么用呢假设你准备开发一个新功能但是需要两周才能完成第一周你写了50% 的代码如果立刻提交由于代码还没写完不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交又存在丢失每天进度的巨大风险。现在有了分支就不用怕了。你创建了⼀个属于你自己的分分别人看不到还继续在原来的分支上正常工作而你在自己的分支上干活想提交就提交直到开发完毕后再一次性合并到原来的分支上这样既安全又不影响别人工作。并且 Git 无论创建、切换和删除分支Git在1秒钟之内就能完成无论你的版本库是1个文件还是1万个文件。