Git笔记（2） 入门认知

---

1. 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都 只需要访问本地文件和资源
一般不需要来自网络上其它计算机的信息
在本地磁盘上就有项目的完整历史
所以大部分操作看起来瞬间完成

这也意味着离线或者没有 VPN 时，几乎可以进行任何操作
如在无网络或网络差的地方想做些工作，依然能愉快地提交，直到有网络连接时再上传

---

2. 保证完整性

Git 中 所有数据在存储前都计算校验和，然后以校验和来引用
这意味着 不可能在 Git 不知情时更改 任何文件内容或目录内容

这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分
若在传送过程中丢失信息或损坏文件，Git 就能发现

Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）
这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串

24b9da6552252987aa493b52f8696cd6d3b00373
1

基于 Git 中文件的内容或目录结构计算出来

Git 中使用这种哈希值的情况很多，将经常看到这种哈希值
实际上，Git 数据库中保存的信息 都是 以文件内容的哈希值来索引，而不是文件名

---

3. 直接记录快照，而非差异比较

Git 和其它版本控制系统的主要差别在：于 Git 对待数据的方法概念 上来区分

其它大部分系统以文件变更列表的方式存储信息
这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们保存的信息看作是一组基本文件和每个文件 随时间逐步累积的差异

可以看出其它版本控制系统是 存储每个文件与初始版本的差异

Git 更像是把数据看作是对小型文件系统的一组快照（snapshots）
每次 提交更新，或在 Git 中 保存项目 状态时
它主要对当时的全部文件制作一个快照并保存这个快照的索引

为了高效，如果文件没有修改，不再重新存储该文件
而是 只保留一个链接指向之前存储的文件

Git 对待数据更像是一个 快照流（stream of snapshots）

可以看出 Git 是 存储项目随时间改变的快照
这是 Git 与几乎所有其它版本控制系统的 重要区别

---

4. 一般只添加数据

执行的 Git 操作，几乎 只往 Git 数据库中增加数据
很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据

同别的 VCS 一样
未提交更新时有可能丢失或弄乱修改的内容

但是一旦提交快照到 Git 中，就难以再丢失数据
特别是如果定期的推送数据库到其它仓库的话

更深度探讨 Git 如何保存数据及恢复丢失数据的话题
请参考 Git笔记（7） 撤消操作

---

5. 三种状态

这里很关键，很关键，很关键，重要事情说三遍

Git 有三种状态：

• 已提交（committed）：数据已经安全的保存在本地数据库中
• 已修改（modified）：修改了文件，但还没保存到数据库中
• 已暂存（staged）：对已修改文件的当前版本做了标记并包含在下次提交的快照中

由此引入 Git 项目的三个工作区域的概念：

• Git 仓库（working directory）：用来保存项目的元数据和对象数据库的地方
  这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据

• 工作目录（staging area）：对项目的某个版本独立提取出来的内容
  这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供使用或修改

• 暂存区域（.git directory）：保存了下次将提交的文件列表信息
  这是一个文件，一般在 Git 仓库目录中，有时候也被称作 “索引”

基本的 Git 工作流程如下：

1. 在 工作目录 中修改文件
2. 暂存文件，即将文件的快照放入 暂存区域
3. 提交更新，找到暂存区域的文件，将快照永存到 Git 仓库 目录

如果 Git 目录中保存着特定版本的文件，就属于 已提交 状态
如果 作了修改并已放入暂存区域，就属于 已暂存 状态
如果 自上次取出后，作了修改但还没有放到暂存区域，就是 已修改 状态

---

6. 命令行

Git 有多种使用方式

• 原生的命令行模式
• GUI 模式

这里将使用命令行模式
首先因为只有在命令行模式下才能执行 Git 的 所有命令
而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度

如果学会了在命令行下如何操作
那么在操作 GUI 软件时应该也不会遇到什么困难
但是，反之则不成立

---

参考： git

以上内容，均根据git官网介绍删减和修改组成

---

相关推荐：

Git笔记（1） 版本控制

---

谢谢