Git笔记（2） 入门认知
1. 近乎所有操作都是本地执行
在 Git 中的绝大多数操作都 只需要访问本地文件和资源
一般不需要来自网络上其它计算机的信息
在本地磁盘上就有项目的完整历史
所以大部分操作看起来瞬间完成
这也意味着离线或者没有 VPN 时，几乎可以进行任何操作
如在无网络或网络差的地方想做些工作，依然能愉快地提交，直到有网络连接时再上传
2. 保证完整性
Git 中 所有数据在存储前都计算校验和，然后以校验和来引用
这意味着 不可能在 Git 不知情时更改 任何文件内容或目录内容
这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分
若在传送过程中丢失信息或损坏文件，Git 就能发现
Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）
这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串
24b9da6552252987aa493b52f8696cd6d3b00373
基于 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 工作流程如下：
- 在 工作目录 中修改文件
- 暂存文件，即将文件的快照放入 暂存区域
- 提交更新，找到暂存区域的文件，将快照永存到 Git 仓库 目录
如果 Git 目录中保存着特定版本的文件，就属于 已提交 状态
如果 作了修改并已放入暂存区域，就属于 已暂存 状态
如果 自上次取出后，作了修改但还没有放到暂存区域，就是 已修改 状态
6. 命令行
Git 有多种使用方式
- 原生的命令行模式
- GUI 模式
这里将使用命令行模式
首先因为只有在命令行模式下才能执行 Git 的 所有命令
而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度
如果学会了在命令行下如何操作
那么在操作 GUI 软件时应该也不会遇到什么困难
但是，反之则不成立
参考： git
以上内容，均根据git官网介绍删减和修改组成
相关推荐：
谢谢
