哈希

所有文件本质上都是0和1，所以所有文件都可以加密。

哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下几个共同点：

  • 不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定
  • 哈希算法确定，输入数据确定，输出数据能够保证不变
  • 哈希算法确定，输入数据有变化，输出数据一定有变化，而且通常变化很大
  • 哈希算法不可逆

常见的哈希算法有MD5、SHA、CRC等。
哈希算法可以被用来验证文件。原理如下图所示：

Git就是靠这种机制来从根本上保证数据完整性的。


Git保存版本的机制

集中式版本控制工具的文件管理机制

以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

Git的文件管理机制

Git把数据看作是小型文件系统的一组快照。每次提交更新时Git都会对当前的全部文件制作一个快照并保存这个快照的索引。
为了高效，如果文件没有修改， Git不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以Git的工作方式可以称之为快照流。

Git文件管理机制细节

Git的“提交对象”

提交对象及其父对象形成的链条


Git分支管理机制

分支的创建


98ca9是根提交

分支的切换

主干master和分支testing都可视作指向某一版本指针，HEAD视作指向分支的指针，用来切换分支。
所以切换分支本质就是移动指针，切换起来简单高效。




Github

大名鼎鼎的 同性 程序员交友网站。
账号注册、在github创建远程库就不介绍了。

本地库和远程库交互方式复习



用Github Desktop很容易实现本地库与远程库的交互，但我们要学习其本质的东西，所以下面介绍用git指令实现交互。

创建本地库和远程库

先新建个本地库，初始化，并添加个文件：

然后git add、git commit：

然后创建远程库，和本地库名字不一定非得一样，但最好还是同名，方便识别。
现在就做个练习，没必要用私有库。

远程库的地址和起别名

这个是远程库的地址（SSH的也行）：

这个地址很长，每次都粘贴进去很不方便，所以要创建别名。
命令：

  • git remote -v：查看当前所有远程库别名
  • git remote add <别名> <远程地址>：给远程库起别名

push

命令：git push <别名> <分支名>
回车之后会弹出Github的登录框，登陆就行了。

现在的GitHub主分支改名为了main，下次注意一下。


可以看到远程库更新成功。

clone

命令：git clone <远程库地址>

团队成员邀请

pull

pull = fetch + merge
fetch只是把远程库分支的内容下载到本地，并没有合并到当前分支。

  • git fetch [远程库地址别名] [远程分支名]
  • git merge [远程库地址别名/远程分支名]
  • git pull [远程库地址别名]

如果pull过来的库比较简单，直接pull就行，而如果比较复杂，为了保险慎重可以把pull分开为fetch和merge两步手动操作。

解决冲突

要点

  • 如果不是基于GitHub远程库的最新版所做的修改，不能推送，必须先拉取。
  • 拉取下来后如果进入冲突状态，则按照“分支冲突解决”操作解决即可。

跨团队协作

这个比较麻烦，至少要两个账号，就不演示了。


SSH免密登录

用HTTPS与远程库进行交互经常需要GitHub的用户名密码，比较麻烦。
而SSH就不需要GitHub用户名密码，不过只能一个用户使用，事实上开发的时候大多时间都是自己一个人在本地开发的，所以用SSH也够了。

我的电脑之前已经连接过SSH，这个连接SSH的过程就就不截图了。

  • 进入当前电脑用户的家目录 cd ~
  • 运行命令生成.ssh密钥目录 ssh-keygen -t rsa -C <你的Github邮箱地址>
    注意C是大写的。
  • 进入 .ssh 目录 cd .ssh
  • 查看 id_rsa.pub 文件内容 cat id_rsa.pub
  • 复制 id_rsa.pub 文件内容
  • 登录 GitHub，点击用户头像 → Settings → SSH and GPG keys → New SSH Key
  • 输入复制的密钥信息
  • 测试 ssh -T git@github.com

这样就是成功了。


Git 工作流

工作流就是在项目开发过程中使用Git的方式。
分类

  • 集中式工作流
  • GitFlow 工作流（用的最多）
  • Forking 工作流

集中式工作流
简单说就是不分支，每个人有各自的本地库。就像 SVN 一样，集中式工作流以中央仓库作为项目所有修改的单点实体。所有修改都提交到 Master 这个分支上。 这种方式与 SVN 的主要区别就是开发人员有本地库。Git 很多特性并没有用到。

GitFlow 工作流
充分利用了分支的特点，通过为功能开发、发布准备和维护设立了独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

Forking工作流
在 GitFlow 基础上，充分利用了 Git 的 Fork 和 pull request 的 功能以达到代码审核的目的。更适合安全可靠地管理大团队的开发者，而且能接受不信任贡献者的提交。


GitFlow工作流详解

分支种类

  • 主干分支 master
    主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境 完全一致。

  • 开发分支 develop
    主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。

  • bug修理分支 hotfix
    主要负责管理生产环境下出现的紧急修复的代码。 从主干分支分出，修理完毕并测试上线后，并回主干分支。并回后，视情况可以删除该分支。

  • 准生产分支（预发布分支） release
    较大的版本上线前，会从开发分支中分出准生产分支，进行最后阶段的集成测试。该版本上线后，会合并到主干分支。生产环境运行一段阶段较稳定后 可以视情况删除。

  • 功能分支 feature
    为了不影响较短周期的开发工作，一般把中长期开发模块，会从开发分支中独立出来。开发完成后会合并到开发分支。


Gitlab

Gitlab一般搭建在Linux上的，用来创建私有仓库。也可以用来创建局域网内的团队仓库，这样哪怕一个团队访问不了外网，也能做起项目来。
目前来看，对于我个人来说，Gitee就够用了，所以Gitlab等以后有需要再学。
Gitlab官网