Git 学习笔记（三）：分支和 GitHub

发布于 2020-02-24  78 次阅读

导读

最后一篇 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 后面的分支将会消失，需要先切换到主分支上再执行该命令。
  5. 解决冲突
    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 会有 master 和 develop 两个贯穿整个开发周期的分支，其中 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. 推送操作
    • 将本地仓库的某个分支推送到远程仓库中
    • 设置推送链接的别名：
    git remote add [别名] [链接]
git remote add test https://github.com/example/example.git
    1. 推送

    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 的时候深感其的强大。

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


版权声明：本文为原创文章，版权归 夕綺Yuuki 所有。

本文链接：https://kira.cool/note/221-Study-Git-3

本文章采用 CC BY-NC-SA 4.0 International 协议进行许可。这意味着您可以自由的复制、转载和修改，惟须注明文章来源且禁止用于商业目的。

This article is licensed under the CC BY-NC-SA 4.0 International License, which means you are free to copy, distribute, and modify it, but must attribute the source and prohibit commercial use.