导读

最后一篇 Git 学习笔记。
感觉 Git 分支虽然内容不多,但是比较重要,故放在第三篇中。


1. Git 分支

1.1. Git 分支概述

Git 分支功能本质上是为了解决协同开发中产生的一些痛点:

  1. 某个项目在开发新功能的时候,需要避免污染到主分支。

    比如某 IM 软件需要研发一个撤回信息的功能,但开发一个新功能不是一个版本就能完成的。

  2. 为了避免多个开发团队的代码相互干扰。

    回想下第一篇的第一个例子。

  3. 并行推进多个功能的开发,提高开发效率。

    和第二点连起来看,还是比如 IM 软件,需要同时研发撤回功能、群聊功能等,可以在各自的分支开发,开发完成后再合并到主分支上。

  4. 如果某分支开发失败,不会对其他分支造成任何破坏,重新开发即可。

1.2. 分支命令

  1. 查看当前分支

    • git branch -v
  2. 添加分支

    • git branch [分支名]
  3. 切换分支

    • git checkout [分支名]
  4. 合并分支

    • git merge [分支名]
    • 简单来说,merge 后面的分支将会消失,需要先切换到主分支上再执行该命令。
  • 解决冲突

    1. 文件合并出现冲突的时候,会切换到手动合并的状态
    2. 冲突的文件 Git 会自动用特殊的标记来表示冲突的内容
    3. 需要手动修改文件,删除特殊标记并将文件修改到满意的程度

      • git add [文件名]git commit -m "test"

2. Git 工作流

2.1. 集中式工作流

什么?Git 不是分布式软件吗,为什么又扯到集中式了?

  • 集中式工作流确实是类似于 SVN。集中式工作流会将中央仓库作为项目的单点实体,所有的修改都会在 master 这个分支上。和 SVN 的主要区别是开发人员拥有自己的本地库。
  • 开发者会先将远程库 clone 到本地上,然后在本地进行修改,完成后再并入到远程库中。

    这种集中式工作流会浪费掉 Git 的很多特性。

  • 但是这种方式仍然流行于小团队和个人开发者当中。因为一般情况下小团队或是个人都不会出现太多协同开发的场景,整个 Master 分支情况都在掌握中。

2.2. GitFlow 工作流

  • 伴随着分布式而出现的新工作方式,可以说 GitFlow 为了大型项目而生。
  • GitFlow 会有 masterdevelop 两个贯穿整个开发周期的分支,其中 master 可以理解为稳定版、develop 可以理解为更新较频繁的稳定版。

    master 分支也可以理解为正式版的存档,一般情况下 master 分支不参与到功能迭代中。而真正参与到功能迭代的是 develop 分支。

  • GitFlow 还有两个分支:在 feature 上进行特性开发;在 release 分支上发布。

    feature 分支可以有无限多个,完成后合并到 develop 分支上。

更多的分支介绍在下节中。

2.3. Forking 工作流

  • 更加被我们熟知的工作流。GitHub 上我们几乎都在接触这一工作流。
  • Forking 工作流在 GitFlow 的基础上,有一个公开的仓库,任何人都可以向其 pull request 代码。
  • 最大的优势就在于可以接受不信任贡献者提交的代码。

3. 分支种类

一般来说,一个大型的项目都有可能会出现这些分支:

  1. 主干分支 master

    • 负责管理正在运行的生产环境代码。
    • 用于保持与正在运行的生产环境完全一致。

    人话:比如 exampleOS 这周推送 4.0.4 版本,则推送后 master 分支会更新到 4.0.4。

  2. 开发分支 develop

    • 负责管理正在开发过程中的代码。
    • 真正意义上的副分支,功能分支应当 clone 该分支。
    • 一般情况下存放最新的代码。
  3. 修复分支 hotfix

    • 负责管理生产环境下出现的需要紧急修复的代码。
    • 从 master 分支分出,修复完毕并上线后,合并回 master 分支。
  4. 准生产分支(预发布分支) release

    • 较大版本上线前,从 develop 分支中分出,用来进行最后阶段的集成测试。
    • 该版本上线后,会合并回 master 分支。
  5. 功能分支 feature

    • 一般一个 feature 分支对应一个开发中的功能,在完成后合并回 develop 分支。

4. GitHub

最后一部分了!

  1. 推送操作

    • 将本地仓库的某个分支推送到远程仓库中
    1. 设置推送链接的别名:

      git remote add [别名] [链接]
      git remote add test https://github.com/example/example.git
    2. 推送
      git push [别名] [分支]
  2. 克隆操作

    • 将远程仓库的内容克隆到本地仓库中
      git clone [链接]
    • 效果:

      1. 将远程库完整的下载到本地
      2. 创建 origin 远程地址别名
      3. 初始化本地库
  3. 拉取操作

    • 拉取(pull) 操作本质上是 fetch + merge 操作
    • fetch 会将远程仓库的内容下载到本地,而不会改变本地文件
      git fetch [链接] [远程地址分支名]
    • merge 会将远程仓库的内容合并到本地仓库
      git metge [链接]/[远程地址分支名]
  4. 合并冲突

    • 如果不是基于远程仓库最新版所做的修改,则无法进行 push 操作,需要先 pull 下最新版。
    • pull 下来后如果进入了冲突状态(即 merging状态),则解决冲突即可。
    • 在 merging 模式下,commit 不需要带文件名。
  5. ssh 免密登录

    • ssh -keygen -t rsa -C [邮箱]
    • 会出现一个 .ssh 目录,其中 id_rsa 存储秘钥,id_rsa.pub 存储公钥
    • 在 GitHub 中将公钥添加到 GitHub 的账号设置中。

后记

简单的把当时的笔记转成文章作为记录,也就是重打一边加深印象。同时也发现了当时的笔记还有不少地方不清晰,算是对笔记本身的一种补全。
Git 是个很有趣的东西,当时第一次深入了解 Git 的时候深感其的强大。

至此,本文的全部内容就结束了,感谢你的阅读,欢迎继续阅读本站的其他文章。