git设计思想、git_del(UntrackedFiles)、小程序私密信息的加密

summary_2018/08 git other

1、日常

1.1、git的一些设计思想

1.2、微信小程序：私密信息的加密

2、技术

2.1、git的一些设计思想

2.1.1、精良的数据结构

• Git系统中有四种类型的对象，几乎所有Git操作都是在这四种Git对象上进行的.
  

// “blob”：一个“blob”通常用来存储文件的内容。一个“blob”对象就是一块二进制数据，它没有指向任何东西或有任何其它属性，甚至没有文件名。因为“blob”对象内容全部都是数据，所以如若两个文件在一个目录树或是一个版本仓库中有同样的数据内容，那么它们将会共享同一个“blob”对象。“blob”对象和其所对应的文件所在路径、文件名是否改被更改都完全没有关系。(存储具体份的某个文件)
// “tree”：像一个目录，管理一些“tree”对象或是“blob”对象。它有一串指向“blob”对象或是其它“tree”对象的指针，一般用来表示内容之间的目录层次关系(即目录、层次文件管理)。
// “commit”：“commit”对象指向一个“tree对象”，并且带有相关的描述信息，标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据，如时间戳、最近一次提交的作者、指向上次提交的指针等等。
// “tag”：一个“tag”对象包括一个对象名(SHA1签名)、对象类型、标签名、标签创建人的名字(“tagger”),还有一条可能包含有签名(signature)的消息。（即一个对像的一些信息）

• 参考文档

2.1.2、直接记录快照而并非具体的差异

• Git 和其他版本控制系统的主要差别在于，Git只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容：
  
• git 更像是做一个快照，通过检查对象内容的SHA1值是否发生改变来判断是否发生修改。当SHA1值改变，表明文件发生了更改，产生一个新的记录，若没有发生改变则只对上次保存的快照做一个链接引用。(节约空间)
  
• 参考文档

2.1.3、大多数操作仅添加数据

• 基本上常用的git操作仅仅是把数据添加到数据库而不是删除，因为删除操作是不可逆的，会使回退/重现版本历史值变得很难，而不断的添加实现可以使我们的操作回退变为可能，shi具有高可用性。

2.1.4、时刻保持数据完整性

• 在保存至存储区时，所有数据都要进行内容的SHA1，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git一无所知。这项特性作为Git的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git都能立即察觉。

2.1.5、多数操作仅添加数据

• 常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。这种方式使git具有高可用性。

2.1.6、git的生命周期和文件状态（3种）

• 工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。（已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。）
• 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。
• Tips：其实从这里我们发现，在我们将文件放入暂存区时，我们对文件生成了对应的SHA1值，用于构建下一个版本的快照，即快照是在存储区生成的。
• 参考
  

2.1.7、其它

• 清空工作区时，对未跟踪文件的清除git clean -fd(force/dir)

### 回退操作
git  rest -—hard  xxx //版本回退(覆盖暂存区和工作区的修改)
git checkout -- <file>  // to discard changes in working directory（已跟踪的文件）
git reset HEAD . //将暂存区的文件放回工作区（会覆盖工作区对应的文件）

2.2、微信小程序：私密信息的加密解密

• 先看官方文档说明：
  
• 可以看到它使用了AES-128-CBC作对称加密，RKCS#7填充，但具体是怎样的呐？？做过微信小程序开发的同学也许都知道，对通过wx.getUserInfo()的success回调得到的加密数据( encryptedData )解密需要iv、session_key,但也许都不知到它们代表着什么？？所以接下来我们需要了解它们：
• 先透露一下加密解密的整个流程：

// 微信：加密
1：对敏感用户信息“目标明文”用psck#7号填充得到“填充文”
2：AES-128-CBC（填充文，密钥，初始向量iv）=>目标密文
3：Base64_Encode(目标密文)=>encryptedData
4：Base64_Encode(初始向量)=>iv
5：Base64_Encode(密钥)=session_key
// 我们：解密
1：通过wx.getUserInfo()获得密文crypteddata，iv
2：通过wx.login()得到的js_code和http接口得到session_key（详情请看）
3：Base64_Decode(encryptedData)=>目标密文
4：Base64_Decode(session_key)=>即密钥aeskey
5：Base64_Decode(iv)=>初始向量
6：AES-128-CBC（目标密文，密钥，初始向量）=>填充文
7：用psck#7对填充文去除填充得到敏感的用户信息“目标明文”

• 现在开始解释上面的疑问：

// psck#7填充？？
这是因为对称加密算法采用的AES算法。由于AES是基于数据块的加密方式，也就是说，每次处理的数据是一块（16字节），当数据不是16字节的倍数时填充(而我们的方法就是使用psck#7方法填充)，这就是所谓的分组密码（区别于基于比特位的流密码），16字节是分组长度。
// 为什么需要初始向量iv？？
这是由于采用AES对称加密时，微信小程采用了对称加密中的CBC方式（是一种循环模式，前一个分组的密文和当前分组的明文异或操作后再加密，这样做的目的是增强破解难度(由于第一组没有前一个分组的密文，即和初始向量异或)）

• 参考文献
  
  • 小程序AES加密与Base64编码
  • 分组加密的几种方式
  • AES详解