[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