Git 入门系列(三)- 分支(上)创建与切换 / 合并 / 查看 / 删除

1,580 阅读5分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第26天,点击查看活动详情

系列传送门


本篇,我们说说分支,分支可是个好东西

小王正在开发 功能1,然后开发 功能 6,开发了一部分,然后测试反馈 功能 1 有问题啊,小王要 fix 功能1,可 feature6 还没完呢,完了运行不起来……

先把代码注释掉?注释后,再修改,影响到了本来的功能怎么办?一点都不智能,在 Git 版本管理中,分支(branch)就可以完美解决这个困扰。

分支是什么? 其实每次提交,Git 都会把它们串成一条时间线,到目前为止,只有一条时间线,在 Git 里这条线就是主分支,也就是 master 分支。

image.png

用分支来处理上述情境会是怎样呢

  • Step 1:在开发新功能之前先创建一个分支,比如就叫 feat_6,用来开发 功能 6
  • Step 2:在 feat_6 分支开发 新功能
  • Step 3:测试说 功能 1 有个 bug,那么可以先把开发的功能提交到 feat_6 上
  • Setp 4:切换分支到 主分支(有 功能 1 的分支),修复 bug 并提交
  • Step 5:提交完成后,可以回到 feat_6 继续开发新功能

分支的创建与切换

新建并切换, 使用git checkout -b <new_branch>

Step 1: 假设当前 master 指向 C2 (最新一次 commit ),现在在 C2 这个节点创建一个新分支 feat_6 并切换,那么新的分支也会指向 C2

image.png

创建 feat_6 分支并切换 git checkout -b feat_6

image.png

可以看到当前的分支已经从 master 切换到了 feat_6 (工作区间地址后面蓝色字标识的就是当前分支) 此时 master 和 feat_6 两个分支的内容完全一样的

image.png

扩展理解

在前面我们提到过 HEAD 比如 git reset HEAD^这个 HEAD,可以理解成 HEAD 指向当前分支,而 Git 用分支指向最新提交 当前 master 和 feat_6 都指向最新提交 C2,在 feat_6 分支上,HEAD 就指向 feat_6

image.png

Step 2~3: 继续在新分支上开发功能,在该分支功能提交后(C3),这个分支的指针也会向最新内容推进

image.png

在 feat_6 分支上新建一个 feat_6.txt, 并提交,此时 HEAD 也会指向 feat_6 分支,而 feat_6 指向最新提交。(在初始使用过程中,可以先忽略 HEAD 的概念)

image.png

为什么要先提交? 如果没有提交,修改的文件会留在工作区或者暂存区里,那么这些还没有提交的修改,会和你在即将检出(checkout)的分支产生冲突而阻止 Git 为你切换分支,所以切换分支之前最好保证当前的分支干净(工作区或暂存区里没有修改的文件)

  • 在实际操作过程中,你会发现有时工作区和暂存区存在文件,也可以成功切换,而且这些文件会一起保留到当前分支
  • 假设 在建立 feat_6 之后,在 master 分支有人修改了 test 文件,feat_6 也修改了 test 文件,此时 feat_6 没有提交,在切换分支时,就会有类似如下提示

image.png 提示先 commit 或者 stash, commit 就是提交,stash 是 绕过 commit 方法来处理,后续学习

Step 4~5: 切换到 master 分支,来修复 功能1 的 bug,使用git checkout <branch>, 切换到 master 分支就是git checkout master(这里要和上一篇的 checkout 用法区别开)

image.png

那么此时的工作目录中你的内容就是 C2(在实例中,master 分支没有 feat_6.txt),和创建分支之前的内容是一样的,可以进行 fix,提交后,再回到 feat_6 继续开发

实际场景的推荐处理方式:

如果在实际工作中,真的遇到了 bug 需要 fix,问题严重的建议再创建一个分支来修复,待修复完成后,再合并到主分支中,以免影响到其他功能的验收

比如,创建这个分支名为 hotfix,并提交了修复的文件(C4),那分支走向如下图

image.png

创建 hotfix 分支,提交就不做逐步演示了,可以动手操作下

image.png

合并分支

不管是在 hotfix 修复问题,还是在 feat_6 开发功能,最后测试后都要合并到主分支里,项目算完整。 先回到主分支,再使用git merge命令来进行合并

git merge <branch> 合并指定分支到当前分支

git checkout master
git merge hotfix

image.png 可以看到 master 分支有了刚刚 fix 的内容(fix_feat_1.txt)

注意到上面的 Fast-forward 信息,Git 告诉我们,这次合并是“快进模式”,也就是直接把 master 指向 hotfix 的当前提交,不存在任何需要解决的分歧。

image.png

合并之后 master 分支和 hotfix 分支指向同一位置。

查看分支

随着分支的增多,可以通过 git branch查看本地分支,星号指向绿色分支是当前分支 git branch -a添加 -a 参数可以查看远程分支,远程分支会用红色表示出来

image.png

删除分支

在 完成 bug 修复之后 并且 master 也合并了 hotfix,hotfix 就可以删掉了。 使用git branch -d <branch> 执行删除操作 git branch -d hotfix (这个操作是在非 hotfix 操作的,示例中是在 master 分支,自己不能删除自己),再查看一下,hotfix 已经不在分支列表中了

image.png

本篇先到这里,后面继续介绍分支,来处理 feat_6 分支的内容,和遇到的问题。 最后回顾下知识点

  • git branch -b <new_branch>创建并切换分支
  • git branch <branch>切换分支
  • git merge <branch> 合并分支到当前分支
  • git branch 查看本地分支
  • git branch -a 查看本地和远程分支
  • git branch -d <branch> 删除分支