git版本控制

回憶上次內(nèi)容

• 上次我們了解了 try 的完全體

• 無論是否發(fā)現(xiàn)異常最終都要運行的代碼塊

• 沒有發(fā)現(xiàn)異常時運行的代碼塊

• 發(fā)現(xiàn)異常時運行的代碼塊

• 嘗試運行

• try

• except

• else

• finally

• 發(fā)現(xiàn)導(dǎo)入部分

• 可以再分為兩個子模塊

• 一個輸入 a

• 一個輸入 b

• 可以再拆分么？??

觀察結(jié)構(gòu)

• 這是test目錄目前的結(jié)構(gòu)

• 想把get_fruits.py再拆成兩個

• get_apples.py

  ?- 輸入apple數(shù)量

• get_bananas.py

  ?- 輸入banana數(shù)量

嘗試保存版本

• 再繼續(xù)之前

• 先把 目前的test目錄 備份起來

• 使用 git 進行版本控制

# 先進入testcd test# 觀察位置pwd# 初始化git init#把目前apple文件夾下所有的都備份git add .# 備份git commit

• commit 遇到問題

• 你是誰的問題

問題

• 提示需要用戶名和郵箱

• 因為工程可能是個多人合作的

• 需要知道提交是誰做的

• 如何設(shè)置用戶名和郵箱呢？

第一次提交

• 按提示錄入郵箱和用戶名

• 不一定是注冊過的

• 這郵箱和用戶名

• 只是一個標(biāo)記

• 然后git commit

• 第一次 提交

第一次提交的注釋

• 終端會自動打開vim

• 要求對提交做注釋

• 沒有具體的要求

• 寫點什么提示之類的就行

• 完成后:wq

• 退出

• 這就把 代碼目前的這個狀態(tài)

• 備份下來了

• 這是 第一次提交

查看版本

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

• 目前有一個提交 commit

開始修改

• 在test目錄下

• 新建get_apples.py

• :r get_fruits.py

• 讀取get_fruits.py

• 到當(dāng)前文件緩存

最終效果

• 把輸入模塊再拆分

• 輸入 apple數(shù)量 、get_apples.py

• 輸入 banana數(shù)量 、get_bananas.py

• 調(diào)整輸入函數(shù)

• 這樣可以運行么？

嘗試運行

• 試驗成功！

• 可以正確執(zhí)行

• 但是這么寫是有問題的！

• 為什么？

• 因為它不符合禪意

• 啊？??

zen 禪

• Flat is better than nested.

• 扁平勝于嵌套

• 現(xiàn)在的控制結(jié)構(gòu):

• 中控 main

• 輸入 a

• 輸入 b

• get_apples

• get_bananas

• 輸入 get_fruits

• 處理 process

• 輸出 outprint

• 結(jié)構(gòu)太多出現(xiàn)了三層

• 好的程序是

• 低耦合

• 而串起來的并不深

• 并排很多的

• 高內(nèi)聚

過度抽象

• 沒有必要嵌套成三層

• 我們應(yīng)該更多使用扁平

• 兩層能輕松解決的

• 別弄到三層

• tcp/ip 四層就能搞定的事

• osi 非要搞到七層，一定不好做

• 層與層之間的接口是很容易固化的

• 這不是教條

• 而是實際開發(fā)中的經(jīng)驗

• 你見過那種層層傳遞過程中的繁瑣和損耗么？

• 想回滾到初始狀態(tài)(init)

• 還好做了版本控制

第二次提交

• 先把當(dāng)前的這個修改提交了

git add . git commit git log

• 提交新Commit

• 系統(tǒng)還是會自動開vim來記錄本版本的注釋

• :wq就可以保存注釋

• 完成第二次提交

查看兩次提交

• git log

• 我們可以看到有兩次提交

• 黃框以內(nèi)

• 提交信息為 add two python files

• 特征碼為 1f6de17...

• 紅框以內(nèi)

• 提交信息為 init

• 特征碼為 3153a6e...

• 第一次

• 第二次

回滾

#查看commit提交的簡寫形式git log --pretty=format:"%h - %an, %ar : %s"#簽出原來的提交git checkout 第一次提交的特征碼...

• 然后再簽出老的那個

• 3153a6e

前后對比

• 硬盤回到初始狀態(tài)了

• 新保留的分支 就不要了

• git 就是這樣的 版本控制軟件

• 任何 commit 過的時間點

• 甚至是

• 任何人 在任何時間點 commit 過的版本

• 可以恢復(fù)到

• 仿佛一個時光機

• 在不同時間和不同人提交的版本間穿梭

• 這次 為什么要 回到過去？

• 扁平勝于嵌套

• 這次回去的 原因 是

復(fù)雜

• 多余的層級

• 是 繁瑣的

• 奢華繁復(fù)

• 是 墮落的開始

• 追求 美之為美

• 孔雀為了美

• 尾大不掉

• 進化到了什么樣子

• 這種美并不符合

• 客觀規(guī)律

• 繁文冗節(jié)只會造成辭藻的堆砌

• 陷入到文字割裂的離散世界中去

• 可世界本是連續(xù)的

• 真善美中

• 真 排第一

美之為美

• 凡爾賽和圓明園

• 都不是 勵精圖治的審美

• 金玉其外

• 敗絮其中

• 金玉滿堂

• 莫之能守

• 什么是能夠自強的審美呢

簡單

• 斷舍離

• 枯山水

• 說的都是化緣

• 為道日損，損之又損，以至于無為

• 無為而無不為

• 致虛極守靜篤

• 為的是蓄勢待發(fā)

• 靜觀其變

• 要留白 才能作畫

• 代碼的演化 本身就是一種涅槃

• 消珥過去的自己

• 在迭代中獲得新的生命

無為

• 為無為

• 才能 全面觀察和蓄力

• 味無味

• 才能 有敏感的味覺

• 事無事

• 才能 有機敏的反應(yīng)

• 靜下來 品味

• 禪茶一味

• 感覺是一致的

一致

• Explicit is better than implicit.

• 明了勝于晦澀（優(yōu)美的代碼應(yīng)當(dāng)是明了的，命名規(guī)范，風(fēng)格相似）

• Simple is better than complex.

• 簡潔勝于復(fù)雜（優(yōu)美的代碼應(yīng)當(dāng)是簡潔的，不要有復(fù)雜的內(nèi)部實現(xiàn)）

• Complex is better than complicated.

• 復(fù)雜勝于凌亂（如果復(fù)雜不可避免，那代碼間也不能有難懂的關(guān)系，要保持接口簡潔）

• Flat is better than nested.

• 扁平勝于嵌套（優(yōu)美的代碼應(yīng)當(dāng)是扁平的，不能有太多的嵌套）

• 以上說的都是一回事：

• 簡單而且明確！

• 形成了上面的觀念就會發(fā)現(xiàn)代碼的美與丑

• 代碼的審美來自于以上的判斷

• Beautiful is better than ugly.

• 優(yōu)美勝于丑陋（Python 以編寫優(yōu)美的代碼為目標(biāo)）

• 審美僵化是 可怕的

• 保持 簡單 且 明確

• 就可以保持 天真的狀態(tài)

總結(jié)

• 使用了版本控制 git

• 制作備份

• 進行回滾

• 嘗試了 嵌套的控制結(jié)構(gòu)

• 層層 控制

• 不過 非到不得以

• 盡量不要 太多層次的嵌套

• 雖然這樣 從頂?shù)降?/p>

• 含義 明確

• 扁平 難道就不能

• 含義明確么？

• 還可以 做點什么？

• 讓程序更加明確呢？??

• 我們下次再說！??

• 藍(lán)橋->https://www.lanqiao.cn/courses/3584

• github->https://github.com/overmind1980/oeasy-python-tutorial

• gitee->https://gitee.com/overmind1980/oeasypython