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

news2024/11/25 4:27:52

git版本控制

回忆上次内容

上次我们了解了 try 的完全体
- try
  - 尝试运行
- except
  - 发现异常时运行的代码块
- else
  - 没有发现异常时运行的代码块
- finally
  - 无论是否发现异常最终都要运行的代码块

图片描述

发现导入部分
- 可以再分为两个子模块
- 一个输入 a
- 一个输入 b
可以再拆分么？🤔

观察结构

图片描述

想把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 遇到问题
- 你是谁的问题

问题

图片描述

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

第一次提交

按提示录入邮箱和用户名
- 这邮箱和用户名
  - 不一定是注册过的
- 只是一个标记

图片描述

然后git commit
- 第一次提交

第一次提交的注释

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

图片描述

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

查看版本

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

目前有一个提交 commit

图片描述

开始修改

在test目录下
- 新建get_apples.py

图片描述

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

最终效果

图片描述

把输入模块再拆分
- 输入 apple数量、get_apples.py
- 输入 banana数量、get_bananas.py
调整输入函数
这样可以运行么？

尝试运行

图片描述

试验成功！
- 可以正确执行
但是这么写是有问题的！
为什么？
- 因为它不符合禅意
啊？😲

zen 禅

Flat is better than nested.
- 扁平胜于嵌套
现在的控制结构:
中控 main
- 输入 get_fruits
  - 输入 a
    - get_apples
  - 输入 b
    - get_bananas
- 处理 process
- 输出 outprint
结构太多出现了三层

图片描述

好的程序是
- 并排很多的
  - 而串起来的并不深
- 高内聚
  - 低耦合

过度抽象

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

第二次提交

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

git add .
git commit
git log

提交新Commit

图片描述

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

图片描述

完成第二次提交

查看两次提交

git log

图片描述

我们可以看到有两次提交
- 第一次
  - 红框以内
  - 提交信息为 init
  - 特征码为 3153a6e…
- 第二次
  - 黄框以内
  - 提交信息为 add two python files
  - 特征码为 1f6de17…

回滚

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

图片描述

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

前后对比

图片描述

硬盘回到初始状态了
- 新保留的分支就不要了
git 就是这样的版本控制软件
- 可以恢复到
  - 任何 commit 过的时间点
  - 甚至是
    - 任何人在任何时间点 commit 过的版本
- 仿佛一个时光机
在不同时间和不同人提交的版本间穿梭
这次为什么要回到过去？
- 这次回去的原因是
  - 扁平胜于嵌套