064-188731-版本控制_git_备份还原.sy.md

show	version	enable_checker
step	1.0	true

git版本控制

回忆上次内容

• 上次规范化了变量名

  • 语义化 明确含义
  • 加类型前缀 明确数据类型

• 发现导入部分

  • 可以再分为两个子模块
  • 一个输入 a
  • 一个输入 b

• 可以再拆分么？🤔

观察结构

• 这是test目录目前的结构
  • 注意我们 所有操作都应该在 test中完成

• 想把get_fruits.py再拆成两个
  • get_apples.py
    • 输入apple数量
  • get_bananas.py
    • 输入banana数量

尝试保存版本

• 在继续之前
  • 先把 目前的test目录 备份起来
  • 做一个版本的备份
  • 以后反悔了
  • 还可以回到当前的状态
• 使用 git 进行版本控制

# 观察位置
pwd
# 初始化当前文件夹作为仓库的根目录
git init
#把目前fruits文件夹下所有的都备份
git add .
# 提交备份文件到版本
git commit

• commit 遇到问题
  • 你是谁的问题

• 提示需要用户名和邮箱
  • 因为工程可能是个多人合作的
  • 需要知道提交是谁做的
• 如何设置用户名和邮箱呢？

设置用户名和邮箱

git config --global user.email "[email protected]"
git config --global user.name "oeasy"

• 按提示录入邮箱和用户名
  • 这样就知道版本中每个文件是
    • 谁修改的
    • 谁提交的

• 然后git commit
  • 尝试提交

第一次提交的注释

• 终端会自动打开vim
  • 要求对当前提交做注释
    • 主要是说明本次提交修改了什么之类的
  • 按下i进入插入模式
    • 写上 init the test project
    • 初始化了test项目
  • 完成后:wq
  • 退出

• 这就把 代码目前的这个状态
  • 备份下来了
• 这是 第一次提交

查看版本

#查看提交版本的日志
git log

• 目前仓库
  • 只有一个提交 commit

开始修改仓库

vi get_apples.py get_bananas.py get_fruits.py

• 在test目录下
  • 新建get_apples.py

• :r get_fruits.py
  • 读取get_fruits.py
  • 到当前文件缓存

• 保存当前文件

编辑get_bananas.py

• :b2
  • 切换到get_bananas.py

• 读取文件

• 修改get_fruits.py

修改

• :b3
  • 切换到 get_fruits.py

• 修改process.py

最后运行main.py

• 运行成功！！！
  • 可以正确执行

• 但是这么写是有问题的！
• 为什么？
  • 因为它不符合禅意
• 啊？😲

zen 禅

• Flat is better than nested.

  • 扁平胜于嵌套

• 现在的控制结构:

• 中控 main

  • 输入 get_fruits
    • 输入 a
      • get_apples
    • 输入 b
      • get_bananas
  • 处理 process
  • 输出 outprint

• 结构太多出现了三层

• 好的程序是
  • 高内聚
    • 低耦合
  • 并排很多的
    • 而串起来的并不深
• 目前这个输入模块
  • 串起来三层
    • 太深了
• 所以我们刚才做的是
  • 不美的

过度抽象

• 没有必要嵌套成三层
  • 我们应该更多使用扁平
• 两层能轻松解决的
  • 别弄到三层
• tcp/ip 四层就能搞定的事
  • osi 非要搞到七层，一定不好做
• 层与层之间的接口是很容易固化的
  • 这不是教条
  • 而是实际开发中的经验
• 你见过那种层层传递过程中的繁琐和损耗么？
  • 想回滚到初始状态(init)
• 还好做了版本控制
  • 回到初始化工程的位置

第二次提交

• 先把当前的这个修改状态
  • 提交(commit) 成一个新版本

git add .
git commit
git log

• 提交新Commit

• 系统还是会自动开vim来记录本版本的注释
• :wq就可以保存注释

• 完成第二次提交

查看两次提交

• git log

• 我们可以看到有两次提交

  • 第一次
    • 提交信息为 init the fruits project
    • 特征码为 d85ab2...
  • 第二次
    • 提交信息为 new
    • 特征码为 a0de2b...

• 我们目前处于第二次提交

  • 需要回滚到第一次提交

• 怎么回滚回第一次呢？

回滚

• 观察第一次提交的特征码

#查看commit提交的简写形式
git log --pretty=format:"%h - %an, %ar : %s"
#签出原来的提交
git checkout 第一次提交的特征码...

• 找到第一次提交的特征码

• 老的那个
  • d85ab2

前后对比

• 然后再签出 (checkout)

• 硬盘回到初始状态了
  • 新保留的分支 就不要了

• 真的回到初始状态了

时光机

• git 就是这样的 版本控制软件
  • 可以恢复到
    • 任何 commit 过的时间点
    • 甚至是
      • 任何人 在任何时间点 commit 过的版本
  • 仿佛一个时光机

• 在不同时间和不同人提交的版本间穿梭
• 这次 为什么要 回到过去？
  • 这次回去的 原因 是
    • 扁平胜于嵌套

复杂

• 多余的层级
  • 是 繁琐的
• 奢华繁复
  • 是 堕落的开始

• 追求 美之为美

• 孔雀为了美

  • 进化到了什么样子
    • 尾大不掉

• 这种美并不符合

  • 客观规律

• 繁文冗节只会造成辞藻的堆砌

  • 陷入到文字割裂的离散世界中去
  • 可世界本是连续的

• 真善美中

  • 真 排第一

美之为美

• 凡尔赛和圆明园
  • 都不是 励精图治的审美

• 金玉其外
• 败絮其中
• 金玉满堂
• 莫之能守
• 什么是能够自强的审美呢

简单

• 断舍离
  • 枯山水
  • 说的都是化缘
• 为道日损，损之又损，以至于无为
  • 无为而无不为

• 致虚极守静笃
  • 为的是蓄势待发

• 静观其变
  • 要留白 才能作画
• 代码的演化 本身就是一种涅槃
  • 消珥过去的自己
  • 在迭代中获得新的生命

无为

• 为无为
  • 才能 全面观察和蓄力
• 味无味
  • 才能 有敏感的味觉
• 事无事
  • 才能 有机敏的反应

• 静下来 品味
  • 禅茶一味
  • 感觉是一致的

一致

• Explicit is better than implicit.
  • 明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
• Simple is better than complex.
  • 简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
• Complex is better than complicated.
  • 复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
• Flat is better than nested.
  • 扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
• 以上说的都是一回事：
  • 简单而且明确！
  • 形成了上面的观念就会发现代码的美与丑
  • 代码的审美来自于以上的判断

• Beautiful is better than ugly.
  • 优美胜于丑陋（Python 以编写优美的代码为目标）
• 审美僵化是 可怕的
  • 保持 简单 且 明确
  • 就可以保持 天真的状态

总结

• 尝试了 嵌套的控制结构
  • 层层 控制
• 不过
  • 除非 到不得以
  • 尽量不要 太多层次的嵌套
• 使用了版本控制 git
  • 制作备份
  • 进行回滚
• 这样
  • 从顶到底
  • 含义 明确
  • 而且 还扁平
• 扁平 也能
  • 含义明确
• 还可以 做点什么？
  • 让程序含义 更加明确呢？🤔
• 我们下次再说！👋