Chinaunix首页 | 论坛 | 博客
  • 博客访问: 209525
  • 博文数量: 247
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 2501
  • 用 户 组: 普通用户
  • 注册时间: 2020-08-10 06:35
文章分类
文章存档

2024年(32)

2023年(86)

2022年(53)

2021年(42)

2020年(34)

我的朋友

分类: Python/Ruby

2023-05-01 18:46:40

git版本控制

回忆上次内容

  • 上次我们了解了 try 的完全体

    • try

      • 尝试运行
    • except

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

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

      • 无论是否发现异常{BANNED}最佳终都要运行的代码块

图片描述

  • 发现导入部分

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

观察结构

  • 这是test目录目前的结构

图片描述

  • 想把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 遇到问题

    • 你是谁的问题

问题

图片描述

  • 提示需要用户名和邮箱

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

{BANNED}中国第一次提交

  • 按提示录入邮箱和用户名

    • 这邮箱和用户名

      • 不一定是注册过的
    • 只是一个标记

图片描述

  • 然后git commit

    • {BANNED}中国第一次 提交

{BANNED}中国第一次提交的注释

  • 终端会自动打开vim

    • 要求对提交做注释
    • 没有具体的要求
    • 写点什么提示之类的就行
    • 完成后:wq
    • 退出

图片描述

  • 这就把 代码目前的这个状态

    • 备份下来了
  • 这是 {BANNED}中国第一次提交

查看版本

#查看提交版本的日志 git log
  • 目前有一个提交 commit

图片描述

开始修改

  • 在test目录下

    • 新建get_apples.py

图片描述

  • :r get_fruits.py

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

{BANNED}最佳终效果

图片描述

  • 把输入模块再拆分

    • 输入 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

图片描述

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

    • {BANNED}中国第一次

      • 红框以内
      • 提交信息为 init
      • 特征码为 3153a6e...
    • 第二次

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

回滚

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

图片描述

  • 然后再签出老的那个

    • 3153a6e

前后对比

图片描述

  • 硬盘回到初始状态了

    • 新保留的分支 就不要了
  • git 就是这样的 版本控制软件

    • 可以恢复到

      • 任何 commit 过的时间点
      • 甚至是

        • 任何人 在任何时间点 commit 过的版本
    • 仿佛一个时光机
  • 在不同时间和不同人提交的版本间穿梭
  • 这次 为什么要 回到过去?

    • 这次回去的 原因 是

      • 扁平胜于嵌套

复杂

  • 多余的层级

    • 是 繁琐的
  • 奢华繁复

    • 是 堕落的开始

图片描述

  • 追求 美之为美
  • 孔雀为了美

    • 进化到了什么样子

      • 尾大不掉
  • 这种美并不符合

    • 客观规律
  • 繁文冗节只会造成辞藻的堆砌

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

    • 真 排{BANNED}中国第一

美之为美

  • 凡尔赛和圆明园

    • 都不是 励精图治的审美

图片描述

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

简单

  • 断舍离

    • 枯山水
    • 说的都是化缘
  • 为道日损,损之又损,以至于无为

    • 无为而无不为

图片描述

  • 致虚极守静笃

    • 为的是蓄势待发

图片描述

  • 静观其变

    • 要留白 才能作画
  • 代码的演化 本身就是一种涅槃

    • 消珥过去的自己
    • 在迭代中获得新的生命

无为

  • 为无为

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

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

    • 才能 有机敏的反应

图片描述

  • 静下来 品味

    • 禅茶一味
    • 感觉是一致的

一致

  • 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

    • 制作备份
    • 进行回滚
  • 尝试了 嵌套的控制结构

    • 层层 控制
    • 不过 非到不得以
    • 尽量不要 太多层次的嵌套
    • 虽然这样 从顶到底
    • 含义 明确
  • 扁平 难道就不能

    • 含义明确么?
  • 还可以 做点什么?

    • 让程序更加明确呢?????
  • 我们下次再说!????
  • 蓝桥->
  • github->
  • gitee->
阅读(292) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~