[oeasy]python0145_版本控制_git_备份还原

git版本控制 回忆上次内容

• 上次我们了解了 try 的完全体
• try
• 尝试运行

• except
• 发现异常时运行的代码块

• else
• 没有发现异常时运行的代码块

• finally
• 无论是否发现异常最终都要运行的代码块

添加图片注释，不超过 140 字（可选）

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

• 可以再拆分么？

观察结构

• 这是test目录目前的结构

添加图片注释，不超过 140 字（可选）

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

尝试保存版本

• 再继续之前
• 先把 目前的test目录 备份起来

• 使用 git 进行版本控制

# 先进入test cd test # 观察位置 pwd # 初始化 git init #把目前apple文件夹下所有的都备份 git add . # 备份 git commit

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

问题

添加图片注释，不超过 140 字（可选）

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

• 如何设置用户名和邮箱呢？

第一次提交

• 按提示录入邮箱和用户名
• 这邮箱和用户名
• 不一定是注册过的

• 只是一个标记

添加图片注释，不超过 140 字（可选）

• 然后git commit
• 第一次 提交

第一次提交的注释

• 终端会自动打开vim
• 要求对提交做注释
• 没有具体的要求
• 写点什么提示之类的就行
• 完成后:wq
• 退出

添加图片注释，不超过 140 字（可选）

• 这就把 代码目前的这个状态
• 备份下来了

• 这是 第一次提交

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

• 目前有一个提交 commit

添加图片注释，不超过 140 字（可选）

开始修改

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

添加图片注释，不超过 140 字（可选）

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

最终效果

添加图片注释，不超过 140 字（可选）

• 把输入模块再拆分
• 输入 apple数量 、get_apples.py
• 输入 banana数量 、get_bananas.py

• 调整输入函数
• 这样可以运行么？

尝试运行

添加图片注释，不超过 140 字（可选）

• 试验成功！
• 可以正确执行

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

• 啊？

zen 禅

• Flat is better than nested.
• 扁平胜于嵌套

• 现在的控制结构:
• 中控 main
• 输入 get_fruits
• 输入 a
• get_apples

• 输入 b
• get_bananas

• 处理 process
• 输出 outprint

• 结构太多出现了三层

添加图片注释，不超过 140 字（可选）

• 好的程序是
• 并排很多的
• 而串起来的并不深

• 高内聚
• 低耦合

过度抽象

• 没有必要嵌套成三层
• 我们应该更多使用扁平

• 两层能轻松解决的
• 别弄到三层

• tcp/ip 四层就能搞定的事
• osi 非要搞到七层，一定不好做

• 层与层之间的接口是很容易固化的
• 这不是教条
• 而是实际开发中的经验

• 你见过那种层层传递过程中的繁琐和损耗么？
• 想回滚到初始状态(init)

• 还好做了版本控制

第二次提交

• 先把当前的这个修改提交了

git add . git commit git log

• 提交新Commit

添加图片注释，不超过 140 字（可选）

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

添加图片注释，不超过 140 字（可选）

• 完成第二次提交

查看两次提交

• git log

添加图片注释，不超过 140 字（可选）

• 我们可以看到有两次提交
• 第一次
• 红框以内
• 提交信息为 init
• 特征码为 3153a6e...

• 第二次
• 黄框以内
• 提交信息为 add two python files
• 特征码为 1f6de17...

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

添加图片注释，不超过 140 字（可选）

• 然后再签出老的那个
• 3153a6e

前后对比

添加图片注释，不超过 140 字（可选）

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

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

• 仿佛一个时光机

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

复杂

• 多余的层级
• 是 繁琐的

• 奢华繁复
• 是 堕落的开始

添加图片注释，不超过 140 字（可选）

• 追求 美之为美
• 孔雀为了美
• 进化到了什么样子
• 尾大不掉

• 这种美并不符合
• 客观规律

• 繁文冗节只会造成辞藻的堆砌
• 陷入到文字割裂的离散世界中去
• 可世界本是连续的

• 真善美中
• 真 排第一

美之为美

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

添加图片注释，不超过 140 字（可选）

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

简单

• 断舍离
• 枯山水
• 说的都是化缘

• 为道日损，损之又损，以至于无为
• 无为而无不为

添加图片注释，不超过 140 字（可选）

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

添加图片注释，不超过 140 字（可选）

• 静观其变
• 要留白 才能作画

• 代码的演化 本身就是一种涅槃
• 消珥过去的自己
• 在迭代中获得新的生命

无为

• 为无为
• 才能 全面观察和蓄力

• 味无味
• 才能 有敏感的味觉

• 事无事
• 才能 有机敏的反应

添加图片注释，不超过 140 字（可选）

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

一致

• Explicit is better than implicit.
• 明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）

• Simple is better than complex.
• 简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）

• Complex is better than complicated.
• 复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）

• Flat is better than nested.
• 扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）

• 以上说的都是一回事：
• 简单而且明确！
• 形成了上面的观念就会发现代码的美与丑
• 代码的审美来自于以上的判断

添加图片注释，不超过 140 字（可选）

• Beautiful is better than ugly.
• 优美胜于丑陋（Python 以编写优美的代码为目标）

• 审美僵化是 可怕的
• 保持 简单 且 明确
• 就可以保持 天真的状态

总结

• 使用了版本控制 git
• 制作备份
• 进行回滚

• 尝试了 嵌套的控制结构
• 层层 控制
• 不过 非到不得以
• 尽量不要 太多层次的嵌套
• 虽然这样 从顶到底
• 含义 明确

• 扁平 难道就不能
• 含义明确么？

• 还可以 做点什么？
• 让程序更加明确呢？

• 我们下次再说！
• 蓝桥->https://www.lanqiao.cn/courses/3584
• github->https://github.com/overmind1980/oeasy-python-tutorial
• gitee->https://gitee.com/overmind1980/oeasypython