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" 首字母缩写:
    

---

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/后面再加上仓库名.

---

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 表示 固定的, 固定显示的, 一直显示的仓库..

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和 右边的 具体的设置 界面部分 相结合起来!!

两种方式实现 push access权限: 1. 添加一个collaborator (成为别人仓库的contributor) 后,这个user就可以直接 push access the repo了, 否则, 如果他 是fork的仓库, 那么当他要push的时候, 就要 申请 pull requests. 或者说:: : 2 . 如果你要能够push一个别人的 仓库的话, 那么你就不要 fork别人的仓库, 而是采用 " pull request" 的方式, 那么如果别人同意了, 你就可以 push 到别人的仓库了!!

---

github的project 并不是 传统意义上的 代码 工程?

他实际上是 仓库的 代码管理工具, 并不是 传统意义上的代码工程.
他是用来管理 仓库事情/进度/ 需要完成的工作, 进行 管理和 track跟踪的 一种kanban "看板" 而已, 一个 project可以包含 多个列column, 每个 column 上可以创建多个 card, 一个card就是 要做的事情. 他实际上是吧 原来的issue/ todo/ pull request 这些功能 整合到 project中来进行 仓库代码开发的一种 管理和 跟踪而已.

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 是一些小的组件, 主要是在一些小的/细节的地方使用 不可能是大的/ 全局的/页面布局式的使用.

---

代码托管和 托管代码?

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.

所有的 已经经过真实性: authenticity验证的主机都保存在 ~/.ssh/ known_hosts 文件中

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(公钥)
   

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等配置). 要注意这两种方式下, 的公钥 是不同的!!

参考: 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的.

公钥登录 的 principle?

在密钥对进行 验证登录的过程中, 公钥始终是事先存放在 服务器上的. 私钥 始终是一直 放在 本地客户端机器上的. (实际上, ssh登录 只是 借助了 本地客户端的壳 , 只不过是安全的壳, 所以叫secure shell == ssh. 登录过程中使用的 账户信息 完全就是 服务器上的账户信息 , 跟 客户端机器没有毛钱 的关系) 整个过程是没有 密钥传递的. 传递的 只是一段 随机字符串: 首先 服务器产生一段 随机字符串, 发送给ssh请求的机器, 然后 ssh客户端机器用 存在它上面的 私钥对 字符串进行 加密, 加密后的字符串在网络中传输回服务器(这个过程中, 私钥并没有传递), 然后服务器用 事先存储的公钥 来解密, 如果能够解密, 或者说 解密后的字符串 正好是 之前它发送的字符串, 那么就认为 客户端机器 提供的账户是可信的, 就同一其登录.

==========

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 的几个选项使用:

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是通过在他自己内部 创建 指向 远程和本地 仓库的 指针 来实现 链接 /跟踪/沟通/关联 操作的.

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了 别人的代码 仓库...

   

git的所有工具中 , 只是最多提供了 git push 本地分支 的功能 , 但是 并没有 pull request 的命令和功能, 要 进行 new pull request 必须先进行比较.下面就是comparing changes的图标:

因为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>
   

---

git clone->git push 的过程举例

1. 查看所有的分支:
   

2. 在github上的仓库, 地址, 就是用于 下载/clone的地址, 就是 .git 文件, 即仓库名称.git
   

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.
   

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的过程:

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的..

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

可以看出:　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合并到本地的仓库中.

---

他们的关系, 大概是:

---

同步一个远程仓库: 参考: 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