github帳戶和倉庫的建立

weixin_34391854發表於2017-08-30
Github

  1. sign up is registration and sign in is logging in for "in" is to enter an existing account..
    signing out or signing off mean leaving .

  2. github就跟 虛擬空間, 虛擬主機一樣, 可以在上面放任何東西, 可以是你的日記, 也可以是你的程式碼, 還可以是你的 網站程式碼, 因此, 你就可以把它當作虛擬主機一樣來部署你的 web站點

    " Create your websites for you and projects. Whatever you want."

  3. owa: outlook web access. [2uwa], 是 outlook2010 的網路版電子郵件. 就是 類似於網易郵箱之類的東西. 登入ms的網頁郵箱: https://outlook.live.com/owa, 或者直接就是https://outlook.live.com/

  4. 你在註冊ms account (帳戶的格式是 username@somedomain.com , 格式是 電子郵件的格式! ) 的時候, 這個account是適用於ms的所有服務的, 包括 web office, purchase, payment, 當然也包括這個 email.

  5. hotmail是95年jack smith等建立的web電子郵件, 後來納入ms. 所以 你直接輸入www.hotmail.com 會redirect到 outlook.live.com, 或者說, ms的帳戶站點就是 @live.com, 如: https:// login.live.com , signup.live.com, outlook.live.com 等.

  6. 由於是 owa, 相當於是 outlook的網頁版, 所以 他就具有 outlook pc版的通用功能, 包括使用方法, 如: 包含:　calendar日曆, tasks任務, dates約會, meetings會議等, 和 contacts聯絡人和 address book地址簿.

  7. junk email資料夾是 垃圾郵件. show as an immersive reader: 作為沉浸式閱讀顯示.. 就是通過 頁面顏色和字型增大, 顯示很逼真的樣子.
    reply / reply all: 回覆/回覆所有的意思...

  8. 不管是163還是qq還是 hotmail, outlook等, contact/address book的收件人/發件人: from/to 的人的設定格式都是: username <account@somewhere.com>

  9. 要熟練地使用 hotmail, ms郵箱, 就是要 能夠熟練地使用 outlook,因為 ms郵箱就是建立在 ol基礎上的. 連他的郵箱地址都是ol的: outlook.live.com

  10. 郵件 message 詳情上的 發件人/收件人 細節, 圓形的圖案是 使用者名稱的 "first name last name" 首字母縮寫:
    821299-20170830205658562-2029530570.jpg

821299-20170830205425562-93837718.jpg

due to: 表示 "由於", due in表示 "預計... 到期的, 預訂的..."

建立好 github帳戶後, 還需要驗證你的註冊郵箱地址: Help us secure your Github account by verifying your email address. This lets you access all of Github's features.

  1. inspiration: n. 兩種意思: 鼓舞, 激勵; 另外還有 "靈感" 的意思.

  2. 在github上建立 repository的時候, 要遵循github pages的規範, 使用 : username.github.io做倉庫名稱, 好處是:　 通過https://username.github.io/就可以訪問到你的倉庫/blog/project主頁, 而不需要在 github.io/後面再加上倉庫名.

821299-20170831115534968-365585708.jpg

  1. sync是synchronize的縮寫詞, live可以做adj, 表示 活的; 實況轉播的,實時生效的.

  2. github可以使用/支援 原聲的 git命令 操作 , 也可以支援 github的上傳工具進行 addd/push/edit等操做(就是靠這個工具 自己來跟 github連線並 修改更新的).

  3. 搞清楚兩個概念: 一個是github的倉庫概念, 他的地址是: github.com/username,這個是使用者的帳戶地址, github.com/username/username.github.io則是倉庫的地址.
    另一個是 倉庫程式碼的釋出地址, github還提供了 程式碼的生成頁 github pages功能,就是能夠將 倉庫的程式碼 解析出來, 生成線上網站, 這個網站的地址是:
    http://username.github.io/ 就直接是username-github-io了, 不再加github-com了.

  4. issues are used to track todos, bugs, feature requests and more. As issues are created, they'll appear here in a searchable and filterable list. To get started, you should create an issue.

  5. 10 lines (9 sloc): sloc: source lines of code 原始碼 的行數.

在程式碼中, 也要非常重視 表格table的 佈局 和使用, 通過設定 表格的 樣式, 可以起到非常 豐富 的 各種樣式的效果, 比如, 隱藏表格的框線, 隱藏表格的標題欄, 在表格中輸出 按鈕等.

raw 和 blame的含義:　

  1. ｒａｗ是指剝去html標籤後, 只顯示文字內容, 相當於 strip_tags.
    • htmlspecialchars, strip_tags, addslashes, 這三個都是函式, 既然是函式, 肯定就只能放在php標籤中了.
    • 都是用於對 傳入的 字串進行處理的, 引數都是傳入的字串, 字串的來源可以是使用者輸入, 也可以是 html的 textarea輸入..
    • htmlspecialchars, 是轉換指定的html特殊字元為html實體(實體, 就是不具備標籤等含義了, 只是 literal 文字含義了, 只是一個 普通的字元, 沒有標籤的含義了). 既然是special字元,那就不是所有的了, 只是指定的那幾個字元了, 包括: &, ', ", <, >
    • strip_tags, 是剝去標籤, 沒有說是什麼標籤, 那就是 所有的 標籤, 包括 html標籤, php標籤, xml標籤等.
    • addslashes是在 指定的 幾個 字元 (包括 單引號, 雙引號, null, 反斜槓) 前加入反斜槓 表示轉義, 主要是要清楚使用addslashes的目的: 他主要 是用在資料庫的 查詢字串中, 用來轉義 查詢字串中本身包含 引號的 情況, 避免 查詢字串出錯, 如 引號不匹配成對的 錯誤報錯. 參考: http://ekenfire.blog.163.com/blog/static/11842915220102146144561/
  1. blame本意是 "責備 把...歸責於", 其實就是對程式碼的 push, commit追蹤. 因為 github允許對同一檔案, 多個使用者進行修改, 提交, 因此, 你要 track是誰提交的什麼內容, 什麼時候提交的, 要看看錯誤程式碼是誰 push的, 就要用這個blame了, 他會把程式碼的每一行 是誰 是什麼時候提交的, 都列表出來...

作為專業的 計算機 東西的顯示, 還是 稍微 "小一點的" 字型看起來 更 專業, 頁面採用白色底面, 看起來更清爽, 內容, 文字, 圖片的佈局, 以自然 分佈" 大珠小珠落玉盤"的感覺自然佈局就好了. 頁尾的部分, 一般是 copyright資訊, 不一定必須 要在 頁面的最底部, 不一定要抵攏 最底部.只要不是留的空白太多就無所謂了.

設定 pinned repositories倉庫, pin 表示 丁點兒, 和 "固定"的意思, pinned 表示 固定的, 固定顯示的, 一直顯示的倉庫..

821299-20170831140649452-1672662036.png

  1. 表示"有"的含義, 可以用there be (在某個地方有什麼), 如果是要 表示 某個人 擁有什麼, 使用have, 他的否定形式是: The repository doesn't have any projects yet.

  2. as當...的時候, 跟when比較, 他的強調同時的 意味更多... occasionally: 偶爾, 有時, 有時候...

  3. 分清使用者和倉庫的區別: username 1個使用者, 可以有 多個倉庫repositories. 使用者中的倉庫, 可以有兩種途徑獲得, 一個是: create, 一個是fork.

    當 fork 一個倉庫後, 就相當於 (copied) 一個倉庫到自己的github的 倉庫中, 還是在 網路中. 雖然你的這個倉庫和別人的倉庫 是一模一樣的, 但是 , 兩者的 url路徑地址是不同的.

參考: http://blog.sina.com.cn/s/blog_4a0824490102wf5y.html 區別:

  1. fork和clone的區別: clone是將github上的 倉庫 下載到 "本地電腦"中, 是 "web" -> download "local", 而fork 是copy到github中 , 是 "web" -> "web"

  2. pull request, 拉請求, 是說, 當你fork了別人的倉庫後, 修改後, 再push回原來的倉庫時,( 注意: 是說 當你要把你修改後的原來倉庫中的程式碼, 要合併merge回 原來的 forked 被fork的倉庫時, 你 不能直接push, 不能隨便就push成功了, 因為原來的 /remote倉庫 , 他不屬於你, 所以, 你要把你 修改after editing後的程式碼 請求合併回去 , 合併到原來的倉庫時, 就必須 進行 pull request, 即 拉請求, 請求別人把你 的修改 "拉回去". 於是 在 )的時候, 會失敗. 是因為, 你沒有 建立 pull request. 解決方法是: 你 建立一個 pull request. 或者申請成為一個 contributor. (貢獻者).

  3. pull = fetch+merge. fetch是獲得別人的倉庫的更新updates. merge是將更新與 自己fork下來的倉庫進行 融合. fetch+merge的方式可以自己決定怎樣merge. 而pull則是不加區分地用updates完全覆蓋

github不只是一個 程式碼倉庫 更是一個 "基因庫". 是 嚴肅的 開原始碼和開源專案的 平臺庫, 才是唯一的 開源專案得以發展和繁衍的土壤. 從github中可以獲取程式碼片段/ 模組, 然後插入自己的專案中, 然後再開發/組成自己的package, coding是 cloud developing platform,主要是提供 私有化的 專案程式碼 託管等服務.

lobby: 門廳, 休息廳, /// 遊說, 暗中活動.

git clone 或下載 倉庫的時候, 其實是通過一個 .git檔案來 clone的 這個.git檔案並不包含具體的程式碼, 他只是一個索引/描述/敘述/說明 倉庫包含哪些資源和 克隆.gitignore等情況的描述性檔案.

通常我們要靈活使用 多種 ui元件, 但是單純的 全貫通式的使用這些ui widgets 是沒有多大的意義的, 要 將ui widgets和 右邊的 具體的設定 介面部分 相結合起來!!

821299-20170831140730937-183655493.jpg

兩種方式實現 push access許可權: 1. 新增一個collaborator (成為別人倉庫的contributor) 後,這個user就可以直接 push access the repo了, 否則, 如果他 是fork的倉庫, 那麼當他要push的時候, 就要 申請 pull requests. 或者說:: : 2 . 如果你要能夠push一個別人的 倉庫的話, 那麼你就不要 fork別人的倉庫, 而是採用 " pull request" 的方式, 那麼如果別人同意了, 你就可以 push 到別人的倉庫了!!

821299-20170831140440405-304620613.jpg

github的project 並不是 傳統意義上的 程式碼 工程?

他實際上是 倉庫的 程式碼管理工具, 並不是 傳統意義上的程式碼工程.
他是用來管理 倉庫事情/進度/ 需要完成的工作, 進行 管理和 track跟蹤的 一種kanban "看板" 而已, 一個 project可以包含 多個列column, 每個 column 上可以建立多個 card, 一個card就是 要做的事情. 他實際上是吧 原來的issue/ todo/ pull request 這些功能 整合到 project中來進行 倉庫程式碼開發的一種 管理和 跟蹤而已.
821299-20170831154453171-1379425184.jpg

  1. github的tag就是release發行版, 是一個比較完善完整的程式碼點了.

approve : 可以做及物動詞和不及物動詞. 有幾個意思: 批准; 同意; | 贊成; | 滿意. 他的名詞是 : approval. approve後 跟的賓語, 可以帶of, 也可以不要of: 凡是 所跟的sth跟人有關就要用of, sth跟人無關的就 不要帶of: the professor did not approve the government's foreign policy. your parents won't approve of your decision to go there.

wait approval: 等待批准...

  1. 所謂的 內容為王, 是指, 網站叫做 web應用程式, 既然是應用程式, 那麼他主要的就是 要實現 "功能", 那麼功能主要還是 "業務邏輯", 還是程式設計, 而不是 內容的呈現方式, 是 業務邏輯的實現和 實現架構 以及內部的邏輯 關係.

  2. terms and conditions: 條款和細則, 條款和限定性條件.

做網頁中 , 一定要有 "標題+正文" 的思想和組織布局習慣, 這樣, 才能 做到 有條理, 分塊, 有邏輯, 像段落一樣來組織 整個文章, 而不是 沒有重點, 沒有條目的感覺.

github desktop 需要.net framework 4.5的支援, 4.5是 4.0的一個本地更新包, 他本身只有幾百kB, 但是 4.5的更新包 需要 window 7.0 以上的版本, xp系統不能安裝 4.5的 .net framework. 所以要使用 github的desktop 最好就是要使用 win7的系統. 看來要使用windows的某些軟體, 還得需要win7以上的系統, xp系統最多可以支援 /安裝 .netframework 4.0 的版本.

github站點中, 超連結的一個很大的特點就是, 超連結並不總是使用的button按鈕, 而是 放在 描述性的 文字 一句話之中, 然後在這句話中選取某些關鍵字作為超連結.

github中的 fork是 複製一份倉庫到你的github空間中, 與clone複製的區別是, fork包含原來倉庫中的 所以commit資訊. watch: "關注" star: "標為星星,作為收藏" watch和star的區別是, watch某個倉庫後, 當這個倉庫有新的 commit時, 會通知你; 而star只是 標記一下, 相當於收藏夾, 以便今後能迅速的找到你所標記的倉庫, 但是不會接收到commit通知.

sight: 視界, 看see的名詞; 而insights: 是: sight into.. . 看到....裡面了, 所以是 " 洞察" 的意思. github中的 insights是用圖形或 統計的方式來表現 倉庫的各種資訊. 如各種 pull requests: 包括 : merged pull request, proposed （提議/建議/打算; 求婚） pullｒｅｑｕｅｓｔ等. 所謂的 ui widget 是一些小的元件, 主要是在一些小的/細節的地方使用 不可能是大的/ 全域性的/頁面佈局式的使用.

821299-20170831215158155-1295232279.jpg

程式碼託管和 託管程式碼?

1, 應用程式是"直接"或"間接"地跟作業系統打交道, 呼叫os的系統api,叫做系統呼叫. 像c/c++語言, 自己管理記憶體和安全和多執行緒機制, 直接呼叫作業系統底層的api, 這個就叫做"非託管"程式碼unmanaged code. 直接編譯生成的 適合本地機器的二進位制程式碼.

  1. 而託管程式碼managed code,是指 像java程式碼要在jvm上執行的一樣, 程式編譯生成的並不是直接在本地機器上呼叫os的二進位制程式碼, 而是生成 il中間語言的程式碼, 然後在ms提供的統一 的 clr(公共語言執行庫)上執行, 由CLR來提供統一的程式碼檢查, 程式載入, 型別安全檢查, 記憶體管理, 安全管理, 陣列越界, 執行緒管理等服務), 使用者在 程式程式碼中就不必管這些東西了 , 主要關注於業務邏輯的實現, 而像 記憶體洩漏, 物件銷燬, 記憶體回收等之類的問題就交由 clr去處理就好了.
  2. clr支援的語言, 主要是ms提供和開發的語言, 也有其他語言, 如c++可以是託管的, 也可以是非託管的 .

same和identical的區別:　ｓａｍｅ是兩者在外觀/顏色等上的相同, 而實際本質不一定相同. identical則是完全相同.

ssh的公鑰和私鑰? 參考看: https://segmentfault.com/q/1010000003951402

  1. 對稱密碼 是指 只有一個密碼, 在伺服器上和 使用者的密碼都是一樣的. 對稱密碼是用得最多的密碼方式, 實際生活中基本上都是用的對稱密碼, 比如登入郵箱, 登入mysql伺服器等等. 但是這有個問題, 就是 密碼== 金鑰在 網路傳遞過程中, 可以被洩露被hack. 而不安全. 更安全的方式是 非對稱金鑰.
  2. 非對稱金鑰. 就是金鑰有兩個, 一個是公鑰, 一個是私鑰. 不能簡單的說, 公鑰在伺服器/私鑰在使用者上, 或者說, 公鑰是鎖, 私鑰是鑰匙, 要分情況. 但是始終是: 用 鑰匙 去開鎖!
  3. 現在的非對稱密碼使用場合主要是兩個, 一個是ssh, 另一個是https. 這兩種的公鑰和私鑰剛好是相反的.

  4. 對於ssh來說, 使用場景比同於: 你與房東租房. 是你自己去買鎖及鑰匙, 然後你把鎖給房東安裝好, 你住房子的時候, 鑰匙始終在你手上,你就可以用鑰匙開啟鎖了. 這種情況下, 即使考慮到不良房東, 即使他把你給他的鎖 去複製, 分發或洩露, 但是由於他沒有鑰匙, 所以他始終是開不了鎖的, 這樣就保證了你的住房安全.
    類比到ssh, 你在 本地機器上, 用ssh 的命令ssh-keygen -t rsa 生成 一對金鑰(一個公鑰和一個私鑰) . 然後把公鑰 給github伺服器( 在github的 settings -> deploy keys) 中 複製/貼上公鑰. 另一個私鑰就存放在 你的 本地機器上. 當用ssh 連線github時, github要驗證你的身份, 他拿的是 公鑰(是鎖), 你就要提供 私鑰(鑰匙key) , 驗證成功後(鎖被開啟後), 你才算被認證成功authentication成功, 然後才能繼續操作. 在 ssh 這種場景下, 是 客戶端使用者 產生 金鑰對, 公鑰 提供給 github伺服器/ 或linux機器, 是鎖, 私鑰 留在使用者本地, 是鑰匙 key.
    為什麼要 由 本地端機器上 產生 公鑰對 呢? 如果是在 伺服器端產生公鑰對 , 因為有一個原則:　A要驗證B的身份，A拿公鑰，B拿私鑰．　所以, 他要驗證客戶端使用者,他要保留鎖, 保留公鑰, 他要把私鑰 傳送(通過網路) 給使用者. 這就產生了一個問題, 私鑰在傳遞過程中, 可能被hacker鎖截獲, 從而key鑰匙被複制洩露, 從而威脅到 安全. 如同租房子是一樣的, 如果你是租客 , 你讓房東去 買鎖和鑰匙, 遇到不良房東, 鑰匙被洩露, 或者他把鑰匙再分一把給別人, 那麼別人hacker就可能開啟你的房間, 威脅到你的安全.
    即: 使用者手裡的是鑰匙，不可公開。你提交給GitHub的公鑰是可以公開的。。

  5. 在另外一種場景下, https下, 本地客戶端使用者和 伺服器之間的 驗證關係, 和地位發生了改變, 是客戶端要 驗證伺服器端, 因為害怕 伺服器端不真實, 是假冒的虛假網站. 所以這個時候, 客戶端是驗證端, 網站是被驗證端. 所以 , 就要由網站伺服器產生 金鑰對, 客戶端拿 公鑰, 伺服器端拿私鑰. 然後 這個時候 公鑰就是key 鑰匙, 私鑰就是鎖, 當客戶端驗證檢查 伺服器的證照(證照就是 公鑰!!!) 正常後, 就用公鑰(鑰匙 可以) 去解密 伺服器用私鑰 加密的網站內容.

=====
所以 對於 ssh而言:
公鑰是鎖，私鑰是鑰匙。
你把鎖分發給別人，你自己留一把鑰匙。
要驗證的時候你拿你的鑰匙去開鎖，能開開就是驗證通過了。鎖被別人複製了沒關係，他們並不能做什麼。
但是你如果自己留鎖把鑰匙分給別人，那麼鑰匙被別人複製了誰都能開你的鎖了。

==========
這要分場合的
看你的標籤貼得是ssh-key，這個場景下你的描述是有問題的，不是伺服器『給使用者』， 而是使用者生成好公鑰，給伺服器。不能公開的私鑰，在使用者自己手裡，伺服器拿到的公鑰，即使被洩露了，沒有任何影響。這種情況下，伺服器是作為驗證的一方，驗證使用者的身份。

如果是訪問HTTPS網站這種場景，建立連線時，伺服器會把自己的公鑰證照給客戶端，在客戶端驗證過證照(證照就是 公鑰) 沒問題之後，需要用這個公鑰來解密伺服器用私鑰加密的訊息。這種情況下，使用者端是驗證的一方，驗證伺服器的真實性。

============

總之，A要驗證B的身份，始終是由 被驗證端B產生金鑰對, 然後 A拿公鑰，B拿私鑰， 就這樣簡單~

======
如果你是在伺服器上生成公鑰-私鑰對，讓後把私鑰發給使用者，那非對稱加密機制已經喪失意義了。你在伺服器上設定一個普通的（對稱加密的）密碼，然後發給使用者，效果不是一樣的嗎？
非對稱加密發明時，想要解決的問題就是：金鑰可能在傳遞過程中洩露。通過在客戶端生成公鑰-私鑰對，然後把公鑰貼到Github上/傳到伺服器上，就保證了只有公鑰需要通過網路傳輸，私鑰始終在使用者的本地放著，這樣就保證了加密的可靠性。公鑰就算公開也不影響加密，所以稱之為公鑰。

=========

sshd連線?

  1. ssh: secure shell, 是基於c-s模式, 所以 要在目標機器上安裝ssh的伺服器端程式: ‵yum install openssh-server, 當然可以在同一個機器上安裝伺服器和客戶端兩種程式 yum install openssh-client ` 因為ssh 傳輸的資料要經過加密, 所以它是一種安全的 網路協議, 最常用的, 一般linux機器上安裝的都是 openssh,包括 openssh-server和 openssh-client.兩種包.

  2. 在 ssh target-host 只有當 目標機器上安裝了 ssh-server軟體時, 才會有響應: the authen'ticity of host '.....' is not established. 是說目標機器的 "真實性" 沒有確立. 只有當驗證了真實性後才能連線, 驗證資訊放在 當前使用者的 家目錄下的 .ssh檔案中.

  3. openssh-client 提供的命令是ssh, openssh-server 提供的命令是sshd.
  4. 當提示 ssh服務 port 22 refused connection時, 排查步驟是: ssh-server: 首先要安裝這個服務.server伺服器端. 其次, 要啟動 sshd服務; 然後要設定 防火牆和selinux允許ssh型別的流量通過.
  5. 一般 linux主機 (伺服器) 都同時 開通了ssh功能和 sshd 服務. 所以 測試 ssh時, 可以直接: ssh 127.0.0.1 或 ssh localhost

There were 2 failed login attempts since the last successful login.

821299-20170901150026718-1172692132.png

所有的 已經經過真實性: authenticity驗證的主機都儲存在 ~/.ssh/ known_hosts 檔案中
821299-20170901150320374-129144254.png

  1. RSA: 是公鑰加密體系, 可以同時用於 加密 和 簽名演算法. 而DSA / ECDSA : 是數字簽名演算法/橢圓曲線數字簽名演算法: digital signature algorithm. 這個只能用作 數字簽名, 好像不能加密, 要和另外的加密演算法一起使用..
  2. ssh-keygen [-b 金鑰長度 多少位bits] [-t 型別包括: dsa/ecdsa/rsa1/rsa/...] [-C comment註釋] [-f output_keyfile 預設的是 ~/.ssh/id_rsa]
  3. passphrase [freiz], 口令, 密碼, 在生成ssh金鑰對時, 要求輸入passphrase, 這個密碼是對私鑰(字串) 進行加密的, 如果要實現 ssh登入 自動登入的話, 就不要輸入 私鑰口令了.
  4. 生成ssh金鑰公鑰對: 就儲存在 ~/.ssh/myssh.ppk(私鑰), myssh.ppk.pub(公鑰)
    821299-20170901155159233-278042349.png

ssh的fingerprint 指紋, 是指 由於 rsa的長度1024太長, 不便於比較, 於是就給RSA 生成一個 md5字串, 這個就是 ssh的指紋, 它只有128位, 便於比較.

因為ssh如果採用 密碼登入的方式, 可能產生 網站假冒, 所以 因為這個風險 ssh本身也不能 解決, 所以它要警告你, 然後, 如果你要審查 伺服器 的真實性, 你到它的伺服器上去看, 伺服器會把他的 RSA 及md5 指紋貼出來, 你自己對照就好了. 指紋儲存在 ~/.ssh/known_hosts中，對於SSH v2指紋，則是 ~/.ssh/known_hosts2。 用ssh登入時, 如果儲存的指紋與登入時接收到的不符， 則將會給出警告。

==========

ssh登入遠端 主機有兩種方法: 一是 普通的密碼登入; 而是 公鑰登入. (要注意, 預設的, 公鑰登入並沒有開啟, 要在伺服器上去配置 : /etc/ssh/ sshd_config檔案中, 開啟 : # RSAAuthentication yes 一定要先開啟這個 RSA 認證, 然後開啟公鑰認證才有意義 # PubKeyAuthentication yes, 要去掉這個井號 ; MaxAuthTries 6 MaxSession 10等配置). 要注意這兩種方式下, 的公鑰 是不同的!!

821299-20170901211201343-1540257472.png

參考: http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

  1. 如果是 密碼登入的話, 就是 由 伺服器產生公鑰和私鑰對, 然後將公鑰 傳送給 客戶端, 客戶端收到公鑰後, 用公鑰對密碼進行加密, 然後傳回到 伺服器, 伺服器用私鑰進行解密, 獲得密碼, 然後 查詢伺服器上存放的 使用者-祕密資料庫(即 使用者在伺服器上的註冊賬號密碼: user-account@server 的密碼) 來確定是否登入成功. 注意, 這個時候, 公鑰傳送給客戶端, 私鑰在伺服器上, 跟 "公鑰登入"是正好相反的.

ssh user@host. 因為由可能受到 中間人 攻擊, 所以, 會提出 authen'ticity 警告. 一旦你 接受 了 伺服器的RSA 指文 真實性, 就會永久儲存.

  1. 另一種登入方式是, 公鑰登入. 此時是由客戶端產生公鑰-私鑰對....

  2. ssh有客戶端工具, 很多種工具, 也有 伺服器的軟體程式是 openssh-server, 由openssh-server提供的工具是 sshd. sshd是用來配置和管理 伺服器端的 工具.

  3. ssh -l username: 表示指定登入使用者, 其中 -l: 表示 login_username. 如果不指定 登入使用者, 則表示預設的 當前使用者進行 登入. ssh登入時, hostname即要登入的目標機器名稱是 必須要指定的. 其中 useranme@ 跟 -l login_name是一樣的效果.

  4. 使用ssh時, 要 時刻區分到 : ssh- 表示客戶端的, sshd-表示 伺服器端的.

  5. shd認證方式：1、基於口令的認證； 2、基於金鑰的認證；

  6. 遠端主機將使用者的公鑰，儲存在登入後的使用者主目錄的$HOME/.ssh/authorized_keys檔案中。公鑰就是一段字串，只要把它追加在authorized_keys檔案的末尾就行了。

注意區分 登入使用者, 比如說 root, 或者說 Foo. 這些使用者一定是 伺服器上 存在的使用者. 而不是說你在 ssh客戶端機器上的使用者(@@@ 實際上, ssh登入 跟本地客戶端機器上的使用者根本就沒有什麼關係!!), 比如你在windows的機器上使用ssh登入伺服器,或linux機器. 那windows的機器上根本就沒有 什麼root 或Foo 賬戶吧. 所以ssh登入的賬戶一定是server/ 提供sshd的機器上的賬戶. 那麼windows機器通過ssh來登入, 為什麼能登上呢, 就是因為它提供的是 伺服器機器/linux機器上 本身就存在的賬戶資訊. 所以 公鑰登入 RSAAuthentication, PubKeyAuthentication 後儲存的公鑰資訊 AuthorizedKeyFile .ssh/authorized_keys 檔案就是放在 伺服器上 登入使用者所對應的 $Home/.ssh/authorized_keys.

下面的圖片顯示了 使用者 root 通過RSA-PubKey 公鑰登入 的方式 登入到 伺服器上的情況(由於這個情況有點特殊: 客戶端機器和伺服器機器是同一個, 所以 兩者放 客戶端金鑰對的地方 , 跟 "公鑰登入"方式 放 "公鑰"的位置在 同一個地方了): 可以看出: 通過 ssh-copy-id root@localhost的方式 上傳的 公鑰 myssh.ppk.pub 和authorized_keys 是identical的.

821299-20170901215150515-736899456.png

821299-20170901220400249-1643850662.png

公鑰登入 的 principle?

在金鑰對進行 驗證登入的過程中, 公鑰始終是事先存放在 伺服器上的. 私鑰 始終是一直 放在 本地客戶端機器上的. (實際上, ssh登入 只是 藉助了 本地客戶端的殼 , 只不過是安全的殼, 所以叫secure shell == ssh. 登入過程中使用的 賬戶資訊 完全就是 伺服器上的賬戶資訊 , 跟 客戶端機器沒有毛錢 的關係) 整個過程是沒有 金鑰傳遞的. 傳遞的 只是一段 隨機字串: 首先 伺服器產生一段 隨機字串, 傳送給ssh請求的機器, 然後 ssh客戶端機器用 存在它上面的 私鑰對 字串進行 加密, 加密後的字串在網路中傳輸回伺服器(這個過程中, 私鑰並沒有傳遞), 然後伺服器用 事先儲存的公鑰 來解密, 如果能夠解密, 或者說 解密後的字串 正好是 之前它傳送的字串, 那麼就認為 客戶端機器 提供的賬戶是可信的, 就同一其登入.
821299-20170901221447577-1941124959.png

==========

setenforce & getenforce, 並不像 set xxx=??? 的方式, 而是直接 就是setenforce作為一個整體的命令, 後面跟0或1關閉或開啟selinux.
host: 可以作為動詞, 表示 "作為 ...宿主機" "為...提供主機服務"

Once you delete a repository, there is no going back. please be certain. Certain: adj. 確信的, 肯定的.

deploy: 是部署, 分發的意思, 是指 部署 ssh keys.
doubt: 懷疑 : cast doubt on 對...產生懷疑
authenticity: n. 真實性, 確實性, 真偽 cast doubt on the statue's authenticity. statue'st2tju: 形容詞: au'thentic 可靠的, 可信的, 真實的
principle: (個人的/工作上的) 原則, 底線; (科學上的, 理論上的) 原理, 基本原則, 法則. ... a matter of principle for us. "like cures like" principle.

ssh 的幾個選項使用:

821299-20170901223833187-1320195203.png

ssh -l, user@, -p: 指定sshd的埠號 修改的話, 在 /etc/ssh/sshd_config檔案中
-b [bind-address] 如果客戶端有多個ip地址時,指定ssh使用的哪個ip地址
-F [config] 預設的/etc/ssh/ssh_config是應用於所有使用者的配置檔案, 你可以為某個使用者建立特定的配置檔案: ~/.ssh/config . ssh -F .....
-C target_host: 指定壓縮
-v 啟用除錯. 如: ssh -v localhost 將會把 ssh連線過程 詳細的顯示出來, 便於檢視和 排錯.
-X 啟用x11 forward轉發.

關於git的雜項

帳戶和賬戶的區別: 在日常生活中, 表示金錢有關的用賬戶. 但是在網路中網際網路中, 賬戶和帳戶是通用的. 基本上沒有區別. 用賬號和帳號的都有.
origin: [2r2gin]: 主要有三種意思: 原點; 起源, 起因, 來源, 根源; (表示人的) 出身

  1. git只是一個命名組prefix. 實際記憶的是 他後面的命令, 都不說git的, 如: 牽涉到遠端倉庫的有三個命令collaborate命令: fetch , pull, push.
  2. git的remote命令, 是專門用來管理 被跟蹤的 遠端倉庫 的命令, 包括 ,可以向 git中新增遠端倉庫 : git add
  3. 通過 git 的remote命令新增,命名另外的倉庫後, 你就可以在 fetch, pull push等命令 中 , 使用這些名字了 , 因為git會 建立這些 關聯的.
  4. 只要你使用 git fetch / git pull命令 , 就總是 會將 遠端倉庫的 分支的 最新版本 下載下來. 使用 先fetch 然後檢視檢查, 最後再merge, 比 直接pull 要安全些

始終牢記, git管理的 是兩個端: 一端是 遠端的源倉庫(origin), 當clone一個遠端倉庫後, git會自動地將元倉庫命名為 origin, 並自動建立一個 本地的master指標 -> 指向遠端的origin的master分支. ;另一個端 是 本地的 倉庫. git就是 在這兩個倉庫之間 進行管理的. 而且 git是通過在他自己內部 建立 指向 遠端和本地 倉庫的 指標 來實現 連結 /跟蹤/溝通/關聯 操作的.

821299-20170902104933046-1840109207.png

pull和pull requests 是不同的! 總之, pull是你去拉別人的程式碼; pull request 是你請求別人來拉你的程式碼. 兩者的方向是相反的. 即:當你 請求 pull request後, 別人就來pull你的程式碼.

  1. 當你 clone 一個專案的時候, 比如: foobaby.git的專案的時候, 就會在你的當前目錄 建立一個 跟原來的 倉庫/專案 名稱相同的 目錄(當然要去掉.git). 這樣你在 可以在當前目錄中直接工作了, 也不必去修改目錄名稱了, 他正好和遠端倉庫名稱對應.
  2. pull是從原始倉庫中 fetch 更新, objects和 refs. 然後合併到本地的 分支中.
  3. 而pull request是當你 fork /clone原始倉庫後, 你 edit了. 然後 push到遠端倉庫.

  4. 當你 push到遠端倉庫後, 你的程式碼 並沒有 馬上/立即 被合併到 原來的原始倉庫( 這個時候 , 修改的程式碼 只是 上傳到了 你從原始倉庫 fork出來 到你的 賬戶空間的 那個倉庫 副本 ), 要想是你的程式碼合併到 原始倉庫中, 你就必須建立一個 pull requests, 等到原始倉庫的所有者 稽核後, 確認後, 才能正式將你的修改的程式碼 合併進去(注意, 這裡的合併就是pull , 更保險的方式是fetch + merge ), 這樣才能算 你對 原來的倉庫做contribution了.

  5. 網上的解釋
'' 有一個倉庫，叫Repo A。你如果要往裡貢獻程式碼，首先要Fork這個Repo，於是在你的Github賬號下有了一個Repo A2,。然後你在這個A2下工作，Commit，push等。然後你希望原始倉庫Repo A合併你的工作，你可以在Github上發起一個Pull Request，意思是請求Repo A的所有者從你的A2合併分支。如果被稽核通過並正式合併，這樣你就為專案A做貢獻了

"  我從單純的語言學角度解釋一下為什麼“pull request”這個片語這麼令人費解。先說正確的理解：<strong> pull request是一個request，它的目的是讓別人pull你的東西。 原始倉庫:  請你來拉我的程式碼吧.  你來拉我的程式碼 的請求</strong>   然而pull和request兩個名詞直接相連構成偏正短語，二者之間具體是什麼關係是不確定的。   我第一次看到pull request這個片語的時候，誤以為這個request的目的是請求別人允許自己pull別人的東西。

"  就是說: 老司機, 帶上我"

"  很簡單，pull request就是請求別人pull你的repo。當然，<strong> 一般發起pull request的人都是從被請求人哪裡clone的程式碼(github上則可以直接fork)，一般比被請求人的專案提前若干commit。所以, 如果你是自己建立和書寫 的程式碼, 就沒有必要 pull request了. </strong>   pull request只是一種專案合作形式，github只是整合了相應功能，脫離github照樣能pr。  比如Linux核心專案，直接給linus發郵件，標題就是Pull Request。郵件裡寫上git的url和泥新增的feature或者修的bug。如果linus覺得ok，就會根據給出的git url去git pull  .   GITHUB只是把上述過程整合在了站內，更加方便新手。

"  我改了你們的程式碼，但是我不是你們git庫成員，不能開個分支改好求合併（merge request），只能自己搞一份副本改好求你們拉我程式碼了（pull request）

" 我修改了你的程式碼，所以請求（request）你把我修改過的程式碼拉（pull）回去看看

" 就是從一個其他分支，或fork出去倉庫的分支，申請向主倉庫合併（一般為master分支），我覺得叫 Merge Request更合適，GitLab就是這樣叫的！

"  github用pull request這個表達是因為git有一個pull命令，是用來獲取目標的程式碼的。即用pull的物件的程式碼更新自己的程式碼。pull request就是發request讓你想讓其更新的人去pull你的程式碼，從而用你的程式碼去更新他的程式碼。

"  相當於變更請求.
主repo(upstream)只開放給某些人，其他人做貢獻就得用pull request，讓有許可權的人review後merge進去

"  pull request對於code review非常有用！Github的專案通常只針對程式碼倉庫的某幾個維護著開放許可權，當非許可權使用者想通過修改程式碼對專案作出貢獻，需要先fork一份拷貝倉庫，clone到本地，然後修改完後，發起pull request請求別人拉取程式碼來看看，程式碼倉庫的維護者code review後，決定是否接受這次修改，接受的話就可以merge了。
  1. 要建立 pull requests , 必須先做comparing, 看有沒有changes. 如果沒有改變, 就不能建立 pull requests.

  2. 要建立pull requests , 通常是 你 clone 或者fork了 別人的程式碼 倉庫...

    821299-20170902133926968-995583714.png

git的所有工具中 , 只是最多提供了 git push 本地分支 的功能 , 但是 並沒有 pull request 的命令和功能, 要 進行 new pull request 必須先進行比較.下面就是comparing changes的圖示:

821299-20170902140509530-1497151995.jpg

因為git 可以管理 多個 遠端 倉庫, 所以 他 的倉庫/分支指定是: 用 remotes/origin/master 來表示的..

git push origin master: "git push" 就相當於 upload上傳的意思, origin表示 上傳到遠端的origin對應的倉庫. 那麼上傳 哪些本地的分支程式碼呢? master是指 "本地的" 分支, 你指定遠端分支是沒有意義的, 因為push本身就是上傳到對應的分支的. 所以, master是本地分支, 因為你還可以上傳其他分支... 比如git push 沒有指定分支, 就是上傳本地的所有分支. (到遠端對應的分支).

  1. workflow: 工作流, 就是常說的 "流程, 工作流程"

總之, 你要push 的話, 前提是 你要有一個 remote repo. 這個遠端倉庫, 要麼 可以是你自己用git 搭建的, 要麼 或者是你在 github上的賬戶 . 所以, 如果你沒有遠端倉庫, 你是不能進行push的, 你想 你把程式碼push到哪裡去呢?? 至於 pull request, 是你fork了別人的 倉庫副本後 , clone到本地, 修改後, 先 commit your_fixed_bug -> push origin master (到你fork的副本) -> 然後向 原始倉庫 / 主開發者/ 原始開發者 New pull requests!

github賬戶和倉庫?

  1. 一個github賬戶可以建立多個倉庫.

  2. 像github一樣, 內容的呈現一定要有自己的特點, 和佈局, 不必拘泥於古代的樣式
    你覺得怎樣好看 怎樣更好的呈現就怎樣做

git的refs:就是refspec: references specification, 指定的引用, 或者說叫 "引用表示式"

  1. git push <repository> <refs>
  2. refs的格式是: <src>:<dst>
    821299-20170902144025999-1891980512.png

821299-20170902145621687-142866308.jpg

git clone->git push 的過程舉例

  1. 檢視所有的分支:
    821299-20170902210818233-1480701812.png

  2. 在github上的倉庫, 地址, 就是用於 下載/clone的地址, 就是 .git 檔案, 即倉庫名稱.git
    821299-20170902211231452-550226232.png

  3. fetch的格式是: git fetch [options] [<repository>] [<refspec>] repo 可以是named repo, 也可以是url. refspec是引用表示式, 在各種命令中, refspec的格式都是 一樣的:
    The format of a

  4. 拒絕fetch到非空的 non-bare倉庫中?
    要fetch遠端的origin/master到本地, 必須是fetch到一個空的 --bare 目錄中, 因為你不能更新一個 成熟的/非空的 倉庫. you can not update a full-fledged(完備的/發育良好的/成熟的) , non-bare repository.
    821299-20170902214155499-584231414.png

  5. accuse: excuse: 詞根 -cuse 是譴責, 責備的意思, ex-cuse: 是免於責備, 在譴責之外的, 就是"原諒"的意思. 所以 ac-cuse就是 譴責, 控告的意思, ac- 是強調.
    publish: pub是公共的, 公開的 -ish是動詞字尾, 所以 publish就是 "使公開的意思", 即釋出. 就是將本地的commits 釋出到github上去. "use 'git push' to publish your local commits"

  6. 在使用git push origin +master:master publish your local commits的時候, 要使用 openssh來驗證 遠端remotes的合法賬戶和密碼. 肯定不是任何人都可以push 的, 只能是 倉庫的 主人和它的collaborator. 所以 要進行使用者驗證. 驗證時, 為了安全, 故意 (有意地) 隱藏口令的長度: ``passphrase length (is) hidden intentionally" intention: 目的/意圖/打算/計劃. 但是 intentional 則是形容詞, 表示 有意的, 故意的...

push的過程:
821299-20170902222515171-2033549189.png

delta: (河流的) 三角洲, 增量的, 所以 delta comprssion表示的是: 增量壓縮, 差值壓縮. 是一種壓縮演算法和壓縮方式

測試pull的過程

any of: ....中的任何一個.
當要使用git 命令中的任何一個 subcommand 子命令, 都必須是 當前目錄為.git, 或者 在 他的父目錄中 至少有任意一個目錄 是.git 否則報錯: fatal: not a git repository ( or Any of the parent directories) . 意思說是, 必須 先 clone 或 initialize當前的git倉庫才可以使用 git 命令.
o'mit: 以便看一看, 看一下, 要用 "to see" 而不是使用 " to look" omit --config to see the identity only in this repo : identity: 身份; (還有 "一致性" "一致"的意思)

ident: ['aident], 是 identification, identity 的 縮寫 , 標誌符, 身份.

注意 在clone完 一個 github的倉庫後, 首先要做的事就是: 配置自己的 使用者資訊. 因為你在後面要進行的所有的 git操作, 包括commit push, pull等都要用到 使用者資訊: user.name + user.email : 對github來說合法的 (使用者名稱+使用者email資訊, github就是通過這 兩個 註冊時提供的資訊 來判斷你的identity 身份是否合法的). 如果不設定config 你的使用者資訊, 預設的 就是 使用 你當前 在 客戶端 正在使用的使用者, 如administor...那當然是不能登入和 push的..

821299-20170903181334952-1681309601.jpg

pull already up-to-date: 已經是最新的了 . 要從遠端remote pull程式碼下來. 必須是 當你的clone倉庫中的程式碼 跟github上的程式碼 有區別, 不同的時候, 才會pull. 因為 你請求pull的時候, git會比較 本地倉庫中的每個物件 和 遠端倉庫中的 對應的物件 (git/github中的物件, 實際上就是 倉庫中的 檔案 等) 是否一樣. 如果pull出錯, 可能是你這邊有新的 add, 沒有commit , 或沒有push.

如果你覺得 remote上的程式碼有更新了, 但是pull 又提示 up-to-date, 那麼你就要仔細檢查一下, remote的程式碼是否更新成功了, 有時候, 你修改了伺服器上的程式碼, 但是由於網路原因, 你可能沒有儲存成功 . 所以 git檢查還是 本地端== remote
821299-20170903211345796-1252547076.jpg

821299-20170903211458437-489538053.jpg

可以看出:　pull的時候, 首先要counting 遠端伺服器上的物件; 然後 適當 comprssing壓縮, 最後 統計, 然後 unpacking: 解包...

expect: 料想, 預料, 想到...
no one expects him to get involved in the hurly-burly campaining.
volve: 沃爾沃, involve: 牽涉, 涉及, 影響到. 引申為 "加入, 參加到" get involved in
envolve: 進化,演變... 注意, in - en的區別, en是使動用法, 所以是演變的意思, in-是 進入到....裡面

await 和 wait 的區別

await是及物動詞, wait是不及物動詞; await後通常接抽象名詞, wait後通常接人和事; await後接動詞時, 通常是動名詞, wait後接動詞不定式. wait還可以作名詞. i had a long wait for the train.

ssh要向github上傳ssh公鑰, ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

  1. 通過 -i選項指定要上傳的公鑰檔案 , 這樣就不一定必須處在 ~/.ssh目錄下了
  2. 在設定user和server的時候, user指定你註冊的賬戶, server直接指定 為 https://github.com 就行了, 不比指定到賬戶, 更不必 指定到你的倉庫.

關於公鑰和私鑰

1、私鑰演算法
私鑰加密演算法, 又稱 對稱加密演算法，因為這種演算法解密金鑰和加密金鑰是相同的。也正因為同一金鑰既用於加密又用於解密，所以這個金鑰是不能公開的。常見的有《DES加密演算法》、《AES加密演算法》。

2、公鑰演算法
公鑰加密演算法，也就是 非對稱加密演算法，這種演算法加密和解密的密碼不一樣，一個是公鑰，另一個是私鑰：
公鑰和私鑰成對出現
公開的金鑰叫公鑰，只有自己知道的叫私鑰
用公鑰加密的資料只有對應的私鑰可以解密
用私鑰加密的資料只有對應的公鑰可以解密
如果可以用公鑰解密，則必然是對應的私鑰加的密
如果可以用私鑰解密，則必然是對應的公鑰加的密
公鑰和私鑰是相對的，兩者本身並沒有規定哪一個必須是公鑰或私鑰。

  1. origin 和 master的關係: origin是倉庫, master是分支

關於git fetch, merge, push, pull request等的理解, 一個比較好的例子:

````
舉個例子：你在大家上隨便找了個人，看人家的衣服很漂亮。你按照別人的衣服樣式，自己複製了一份(clone)，別人既然穿出來了，就不怕他人抄。過了一段時間，人家覺得有些地方不夠美觀，進行了一些改動，然後再次穿到自己身上秀出來了(push)。這個時候你仍然可以將新改動的部分再次抄過來(fetch)，然後合併到你的衣服上(merge)。這兩步可以合併為一步，即pull。後來，你覺得衣服的有些部分不夠美觀，如你想把長袖改成短袖。沒問題，你自己改，改完後穿上(commit)也覺得很美，你想“既然這麼美，要不把改動也告訴給別人吧”，然後你duang就想上前拉住別人，“來來來，看看我的改動好不好”。別人肯定會想“你誰啊？有病吧？”問題出現了，如果你本身是一個很牛X的服裝設計師，看到有些人的衣服設計的實在是太爛，完全看不下去了，你下定決心，“我要更漂亮、更實用、更節能”。那麼怎麼辦？第一步：要先知會(fork)一下對方，“我要針對你的設計進行調整了”第二步：你仍然需要先複製(clone)一份，你肯定不能直接在別人身上改動吧第三步：修改完成後，需要自己先上身(commit)看看效果第四步：如果對於改動滿意，那麼好，這個時候就可以告知(push, 這裡是先push到你的fork倉庫中, 然後是要把自己倉庫中的新程式碼 -> 合併/contribute to 到原始專案的時候, )對方，"我剛才說要對你的設計進行修整，現在是修整後的效果，你看看，滿意否 ? (這時候, 要建立一個 pull request ) "當然，這個時候，對方是不是接受，那就看人傢俱體的意願啦。

=所以，我的理解是，如果你想push，請先fork； 所以, 你要想參與 並貢獻給別人的專案, 必須 先 fork!! 別人的原始倉庫, 就像 目錄 可讀但不可寫 一樣!

如果只是拿來主義，那麼直接clone然後pull就可以了。
這個設計理念應該是包含了人與人直接最基本的一個尊重。

```

git fetch 和 merge?

  1. fetch的源 總是 "remote 遠端倉庫" , 這個remote倉庫, 不一定就是 origin. 你也可以新增多個 remotes repos, 比如: fork的原作者倉庫, 就可以新增為 upstream(上游) 倉庫: git add upstream https://原始作者的倉庫地址, 這樣你的git中, 就可以有多個 remotes 倉庫

  2. fetch的目的地, 總是 本地倉庫, 客戶端倉庫, 即你clone後的倉庫目錄.

  3. 如果fetch 出自 origin. 則是獲取origin上的更新程式碼. 如果 fetch 自 upstream , 則是獲取原作者/原始作者的倉庫...

  4. merge是將 fetch 下來的程式碼, merge合併到本地的倉庫中.

他們的關係, 大概是:
821299-20170903222035327-993731317.png

同步一個遠端倉庫: 參考: https://help.github.com/articles/syncing-a-fork/

可以在 倉庫的.git目錄中, 檢視 config檔案, 其中的remote, origin 就是 你遠端clone的倉庫地址 . git 已經自動將 clone的倉庫命名為 origin了.

github的地址, 分, 公有地址和私有地址:
公有地址: https://github.com/username/username.github.io 專案
私有地址(ssh地址) : 註冊郵箱號: 使用者名稱/倉庫名稱: someone@git.com : foo/afoobar.git

相關文章