再谈git和github-深入理解-2

github中的 sloc是什么意思?
sloc: source lines of code: 代码行数, 源代码行.

要向仓库中 create file/upload file/edit file等操作, 你需要在某个分支上才行: you must be on a certain branch.
在github上 创建/修改/删除 一个文件都是一个 commit

一个节点的 父节点(parent version 父版本) 是指比他 更早的 那个提交 节点. 所以 git节点的表示方法是: a <- b <-c (current HEAD)
一次提交/commit等 就是 一个新的节点, 一个新的版本.

git/github的 commitID为什么是7个数字

• (工作树/版本库 的版本号是 5 ~ 7 个数字, 是 commitID的前面几个数字, 完整的commitID是40个字符).
• commitID是一个sha1的160bit, 40个16进制数字, 在 .git/objects中, 根据commitID 进行了目录划分: 一个 commitID的 前两位数字 就是目录名, 剩余的38位数字 组成该目录下的一个文件.

command-line 命令行(是 一个完整的 "单词")

git rm 怎样用?

• git rm : to remove files from the working tree and from the index
• git rm 的用法: git rm [options] [--] ...
• git rm的选项: -f = --force, -q = --quiet, -r 递归删除
• git rm --cached: 只是 从删除 暂存区删除, 而工作树 中的对应文件并不变, 因此, git rm 总是要从index 区删除的, 要用 git rm删除的文件 必须是已经 被 git add 添加到 staged 区域了的. 否则就会报错...
• git命令中的 "通用"选项 [--] 两个横线, 它是一种 "分隔符" 用来分隔 前面的命令行选项options 和 后面的文件列表(因为linux下文件名称可以是 类似 --cached 这样的), 以免文件名被误认为 是 选项 : it can be used to separate the command-line options from the list of files. (useful when files might be mistaken for command-line options)
• be mistaken for: 被误解(成....)

git 中的工作树和 工作区?

两者其实是一样的: 都是用户编辑/工作的目录, 叫工作树 working　ｔｒｅｅ可以, 叫 工作区 working space 也可以
同样的, 本地仓库 也叫: 版本库, 数据库 都是它

git的index/stage 暂存区是git高效 的关键所在, 是git设计的关键点.

git rm 删除 '--cached' 文件?

• 如果要删除 以 横线- 或 双横线开头 的文件, 不能直接 rm -file/ --filename 因为会把这些当做是 命令的选项, 应该要指明 其路径,比如: rm ./-file 或 rm ./--filename
• git rm 'file' 不能删除文件, 但是 直接用 rm就能删除? 报错: fatal pathspec 'fielname...' did not match any files? 是因为, git rm (或 git rm --cached) 总是要从 stage区删除文件, 如果文件没有被 git add, 处于 untracked 状态, git没有对该文件进行管理/索引/跟踪的话, git就会 "视而不见" 说找不到这个文件了, 因此, 如果确实要用 git rm来删除的话, 就一定要先 git add...

在shell中, $str是表示变量 的引用, 如果要对字符串进行 处理/运算, 要使用 花括号, 比如: ${...}
有哪些运算符:

• 只有当 # 在字符串前面 , 表示求长度 ${#str}
• 其余的都是 运算符都在字符串后面 , 比如 ${str#*/}
• 字符串截取方法

有3种截取符号, 用# 截取; 用 % 截取; 用冒号截取
${str#/} ${str##/}: # 表示从左边截取, 保留右边; 通配符　* 在 截止字符的左边, 　实际上，　常常有这样的需求：　要截取取的范围是：　第一个和最后一个截止符：　两个##表示匹配最后一个 截止符;
${str% /} ${str%% /} % 表示从右边截取, 保留左边; 所以通配符　*　在截止符的右边；　两个％％　．．．
${str:0:7} ${str:0} ${str:0-4:3} ${str:0-4} 表示从 ? 位置开始, 截取多少个字符.

如何指定css文件的字符编码?

• 当css文件中, 出现"非ascii"字符时,比如: font-family: venda, '宋体',...时, 才需要指定编码
• 指定方法是: 在css文件的开头写上"标记" : @charset 'utf8'
• 如果没有指明 @charset , css文件将使用对应的html中的字符编码.
• html4中的 link标签有 charset这个属性, 但是h5中则废弃.

git status -s?
-s = --short 是指 用剪短/简洁方式 列出 staged/but uncommitted的文件和 untracked文件. 其中的A是 是已经 added的 , ?问号是没有 被tracked的文件
每次提交前, 用 status命令查看, 是一个 好习惯!

• 已经 committed的文件用 log命令查看.
• 如果文件已经被add到 index区了, 即 have been staged. 要从暂存区删除, 即unstaged, 使用 : git rm --cached -- ...

---

### 关于git 中的 checkout 命令: 这是一个 非常 "危险的命令", 是对("未提交到 暂存区的") 工作区/或 暂存区中的 文件的 修改/编辑/ 你前面所做的 工作的 放弃/cancle/discard! 差不多相当于 对文件的 rm命令. 所以要 小心使用! 同时也可以看出, 在使用 git 的过程中, 要及时 使用 git add命令! 这样 才能把 你的所做的修改等工作 提交到 暂存区( 更新暂存区的虚拟目录树, 同时修改内容 也被 存储到 objects 对象库中). (相当于 在 word中 编辑文档的时候 要时常记得 ctrl+s保持) 参考: `http://www.worldhello.net/2010/11/30/2166.html` 感觉这个里面讲得很好, 很通俗易懂! 特别是那个图很明了!

git为什么设计 index暂存区? stage的作用? 是为了便于 跟踪工作区的文件, 通过检测 工作树中文件的 时间戳/文件size等来判断文件是否发生了 changes, 从而提示用户提交和保持更改.

当执行 "git status" 命令扫描工作区改动的时候，先依据 .git/index 文件中记录的（工作区跟踪文件的）时间戳、长度等信息判断工作区文件是否改变。如果工作区的文件时间戳改变，说明文件的内容 可能 被改变了，需要要打开文件，读取文件内容，和更改前的原始文件相比较，判断文件内容是否被更改。如果文件内容没有改变，则将该文件新的时间戳记录到 .git/index 文件中。因为判断文件是否更改，使用时间戳、文件长度等信息 (文件的元信息) 进行比较要比通过文件内容比较要快的多，所以 Git 这样的实现方式可以让工作区状态扫描更快速的执行，这也是 Git 高效的因素之一。

文件 .git/index 实际上就是一个包含文件索引的目录树，像是一个虚拟的工作区。在这个虚拟工作区的目录树中，记录了文件名、文件的状态信息（时间戳、文件长度等），文件的 内容并不存储其中，而是 " 文件的真实内容 和 修改" 保存在 Git 对象库（.git/objects）中，文件索引建立了文件和对象库中对象实体之间的对应。

github上 添加文件 New file, 通过分支来添加??? 测试pull?

---

content可以用作复数, 也可以用作单数

• 复数时,表示 "包含的内容物"
• 单数时, 表示 抽象的含义, "要旨, 含义"等
  通常用作复数的形式要多一些

ls / ll 默认的情况下, 是显示 目录中的内容.
有时候, 我们只是想查看目录本身, 那么 同样的命令, 要使用 -d 或 --directory 选项.
比如: ll -d [DV]* /home

关于shell中的字符颜色表示方法?

• 在shell中, 中括号是有特殊含义的, 表示的是 多个字符中的其中之一, 如果要表示 中括号的本义, 就要 用转义: [ ]
• shell表示字符颜色, 转义符可以用 e 或 33 来表示, 要注意 33一定要加上最前面的数字0, 表示 是 8进制数字?? 如果写成 33是不会被转义的.
  表示颜色的转义字符串, 要放在 [和m之间. [表示起点,m表示 终点. 所以 echo　 -e 'e[1;32m abc' 或者: echo -e '33[1;32m abc'将输出绿色的abc.
• 表示颜色不需要在颜色前后 加上 中括号的!

git的remote操作?

git remote: 显示 远程仓库的简短信息(名称)
git remote -v 显示远程仓库的 简短名称 和 详细地址(包括fetch抓取 + merge合并)
git remote add shortName repos_addr 添加远程仓库: shortname: 简短名称(简名/别名) 后面是远程仓库的详细地址

• 默认的clone的远程仓库, 的 简名叫做 orign, 只有这个你才可以 push上的

git的push和pull?

• push是将本地仓库 (的 修改) 推送到 /提交到 远程 仓库
• pull 则是 将远程仓库的内容 拉取到 本地机器的 工作树. 主要是在 当远程仓库有更新了, 而本地仓库还没有这些更新; 或者是 当从本地仓库 push到远程仓库时 发生 conflict冲突了, 说明 远程仓库上 (的某个同名文件) 有 本地仓库 所没有的更新了, 也就是 本地仓库 :out-of -date了. 这个时候, 就要将远程仓库 pull到本地 机器的工作区, pull的时候, 会报错, 有冲突

push 失败的原因?

error: failed to push some refs to 'https://github.com/onprinciple/onprinciple.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. (因为别人做了的工作, 事先push到远程仓库了, 你当然不能直接push了, 因为如果可以直接push的话, 就会将别人的工作给覆盖掉, cancel掉了) You may want to first integrate the remote changes (所以需要 整合 远程的 更改, 整合就是 先pull下来, 然后消除conflict, 然后再push)
hint: (e.g., 'git pull ...') before pushing again.

#### 在push的时候 注意两个问题: 1. 当你要push时, 如果别人(的仓库)已经　ｐｕｓｈ过一次代码到远程仓库了, 那么这时候 即使 是 你的本地工作区中的文件代码 (内容) 跟远程仓库上的 同名文件的内容 完全一样的, 也会报上面的错. 这时候, 仍然要先 pull一次(integrate 整合一次) 1. 当pull时, 自动成功的进行merge时, 只有三种情况: - 那就是你工作区的同名文件的内容 跟远程仓库中的 同名文件的内容完全一致, - 或者前面的完全相同, 而另一个文件(不管是本地仓库的还是远程仓库的)的内容 更多一些; - 两者在对应位置的行, 一个文件的..为空, 另一个文件的...不为空, 有内容...

• 什么叫冲突: 就是本地仓库跟要push到的目标 远程仓库 中, 有 同一个名称的 文件: 在相同位置处的内容　不同. 当pull的时候 "本地仓库的同名文件会自动的和 远程仓库的同名文件 合并:　merge （当ｍｅｒｇｅ的时候，如果发生了冲突）　：会将冲突记录到 一个同名文件中, 这时候, 只要 将同名文件中 冲突的内容 处理后, 就可以再add, 再commit, 再push了.

• 什么时候会冲突? 并不一定两个文件 的内容不同 , 合并时就一定会发生冲突, 所谓冲突是指: 两个同名文件, 在同一个位置处 (同一行, 同一列的位置处) 两者的内容不同. 因为合并后 在同一位置处的内容 只能有一个样, 只能保留 其中一个内容.
  但是 在不同位置, 不同行中的内容可以不同 , 实际上内容是 可以 "互补的"

---

git status -s(--short简短输出)的结果输出中, M(= modified)表示 该文件有内容的修改! 如果是新增 的untracked文件, 会显示 两个红色 的问号??

git的好处之一是: 每操作一步, 后面都会有相应的提示, 提示你下一步该怎样做/做什么. 比如 committed后, 会提示你 " use 'git push' to publish your local commits"

username or password is hidden intentionally: (故意隐藏的)intent: 目的, 意图; intention 目的/意图; intentional 有意的, 故意的; intentionally: 故意地, 有意地.

commit时 message是必须的 , 否则单是 git commit 命令的话, 会打开vim编辑器提示你输入 commit msg. 如果msg为空, 将放弃提交: Aborting commit due to empty commit message

---

history : historian: 历史学家
'annotate 重音在最前面: vt. 注释, 注解

关于 git tag命令

• git tag [-l]