持续创造,加快成长!这是我参加「日新计划 10 月更文挑战」的第26天,点击检查活动概况

系列传送门

  • Git 入门系列(一)- Git 概念/装置/根本操作/长途推送更新
  • Git 入门系列(二)- 修正办理 / 撤销操作 / 指令及区间关系
  • Git 入门系列(三)- 分支(上)创立与切换 / 兼并 / 检查 / 删去
  • Git 入门系列(四)- 分支(下)兼并处理抵触 / 长途分支
  • Git 入门系列(五)- stash 贮藏
  • Git 入门系列(六)- 标签 tag
  • Git 入门系列(七)- 可视化 Git 办理工具
  • Git 入门系列(八) – FAQ

本篇,咱们说说分支,分支但是个好东西

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

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

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

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

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

  • 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

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

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

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

能够看到当时的分支已经从 master 切换到了 feat_6 (工作区间地址后面蓝色字标识的便是当时分支) 此刻 master 和 feat_6 两个分支的内容完全相同的

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

扩展了解

在前面咱们提到过 HEAD 比方 git reset HEAD^这个 HEAD,能够了解成 HEAD 指向当时分支,而 Git 用分支指向最新提交 当时 master 和 feat_6 都指向最新提交 C2,在 feat_6 分支上,HEAD 就指向 feat_6

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

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

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

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

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

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

  • 在实际操作过程中,你会发现有时工作区和暂存区存在文件,也能够成功切换,并且这些文件会一同保留到当时分支
  • 假定 在树立 feat_6 之后,在 master 分支有人修正了 test 文件,feat_6 也修正了 test 文件,此刻 feat_6 没有提交,在切换分支时,就会有类似如下提示

Git 入门系列(三)- 分支(上)创建与切换 / 合并 / 查看 / 删除
提示先 commit 或者 stash, commit 便是提交,stash 是 绕过 commit 方法来处理,后续学习

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

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

那么此刻的工作目录中你的内容便是 C2(在实例中,master 分支没有 feat_6.txt),和创立分支之前的内容是相同的,能够进行 fix,提交后,再回到 feat_6 持续开发

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

如果在实际工作中,真的遇到了 bug 需求 fix,问题严重的主张再创立一个分支来修正,待修正完结后,再兼并到主分支中,以免影响到其他功用的检验

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

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

创立 hotfix 分支,提交就不做逐渐演示了,能够动手操作下

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

兼并分支

不管是在 hotfix 修正问题,仍是在 feat_6 开发功用,最终测验后都要兼并到主分支里,项目算完整。 先回到主分支,再运用git merge指令来进行兼并

git merge <branch> 兼并指定分支到当时分支

git checkout master
git merge hotfix

Git 入门系列(三)- 分支(上)创建与切换 / 合并 / 查看 / 删除
能够看到 master 分支有了刚刚 fix 的内容(fix_feat_1.txt)

注意到上面的 Fast-forward 信息,Git 告诉咱们,这次兼并是“快进形式”,也便是直接把 master 指向 hotfix 的当时提交,不存在任何需求处理的不合。

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

兼并之后 master 分支和 hotfix 分支指向同一方位。

检查分支

随着分支的增多,能够通过 git branch检查本地分支,星号指向绿色分支是当时分支 git branch -a增加 -a 参数能够检查长途分支,长途分支会用红色表示出来

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

删去分支

在 完结 bug 修正之后 并且 master 也兼并了 hotfix,hotfix 就能够删掉了。 运用git branch -d <branch> 履行删去操作 git branch -d hotfix (这个操作是在非 hotfix 操作的,示例中是在 master 分支,自己不能删去自己),再检查一下,hotfix 已经不在分支列表中了

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

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

  • git branch -b <new_branch>创立并切换分支
  • git branch <branch>切换分支
  • git merge <branch> 兼并分支到当时分支
  • git branch 检查本地分支
  • git branch -a 检查本地和长途分支
  • git branch -d <branch> 删去分支