利用开源项目 gitbook，自己写本书吧～
前言：gitbook 平台在今年的4月9日发布了新的版本v2。新的版本官网已经变成
www.gitbook.com（旧的地址为legacy.gitbook.com）。新旧版本有很多的不一样，网上很多资料都是针对旧版。 比如新版不再支持把每本书作为一个Git Repository来进行版本管理。（以前是可以针对每本书从本地git push到 gitbook 的），这点也是坑了我很久（坑一个强迫症重度患者的结果就是，不扒出被坑的根本原因誓不罢休）。更多 v2 的重大改变可以看 这里。
以下的所有操作都是针对新版的 gitbook。
想给 github 项目发布一个可访问的地址，网上的资料虽然多，但是乱。总的来讲，分为两种方法：一种是通过 github 的
htmlpreview插件来展示。另一种就是通过 github pages 来展示。关于 github pages 网上很多人对它有误解，认为一定要先创建username.github.io这个 repository 才可以，其实并不需要；还有人认为一定要把要展示的静态资源放在项目的 gh-pages 分支上才可以，其实也不用。
总结一下我利用 github pages 给自己的项目创建主页的方法。
步骤如下：
结论：
例如new Date('2018-09-26').getTime() 获取的是距离1970年1月1日0点UTC时间。new Date('2018-9-26').getTime() 获取的是距离1970年1月1日0点本地时间。
Date.now()、 +new Date()、 new Date().getTime(), 获取的都是距离1970年1月1日0点本地时间。检验依据：
Date.UTC()该方法使用的是UTC时间。而Date.UTC(2018, 8, 26)跟Date.now()、+new Date()、new Date().getTime()获得的值相差8个小时。
我们对 git log 应该很熟悉了，它是我们常用的用来查看提交记录的命令，而对另一个查看日志的命令 git reflog，可能就不那么熟悉了。我最近因为排查一个线上bug，定位到一段代码被注释掉了，从 log 日志上看，是在一次 merge 的过程中发生的，但因为 rebase 和 amend 等命令的存在，光看 log 有的时候是不可靠的，为了进一步确认该操作是如何发生的，我用到了 git reflog。顺便把 reflog 的用法整理了一份。
git log shows the current HEAD and its ancestry. That is, it prints the commit HEAD points to, then its parent, its parent, and so on. It traverses back through the repo’s ancestry, by recursively looking up each commit’s parent.
(In practice, some commits have more than one parent. To see a more representative log, use a command like git log –oneline –graph –decorate.)
git reflog doesn’t traverse HEAD’s ancestry at all. The reflog is an ordered list of the commits that HEAD has pointed to: it’s undo history for your repo. The reflog isn’t part of the repo itself (it’s stored separately to the commits themselves) and isn’t included in pushes, fetches or clones; it’s purely local.
Aside: understanding the reflog means you can’t really lose data from your repo once it’s been committed. If you accidentally reset to an older commit, or rebase wrongly, or any other operation that visually “removes” commits, you can use the reflog to see where you were before and git reset –hard back to that ref to restore your previous state. Remember, refs imply not just the commit but the entire history behind it.
git log 是显示当前的HEAD和他的祖先的，递归是沿着当前指针的父亲，父亲的父亲……这样的原则。
git reflog 根本不遍历HEAD的祖先，他是HEAD所指向的一个顺序的提交列表。reflog并不是repo的一部分，它单独存储，而且不包含在pushes、fetches、或者clones里，它纯属是本地的。
reflog查看的是所有的 HEAD 改变的记录，约等于记录用户操作行为。reflog 可以很好地帮助你恢复你误操作的数据，例如你错误地 reset 了一个旧的提交，或者 rebase 等等，这个时候想要查看在错误操作之前的信息，log就做不到了，而reflog可以。然后使用 git reset –hard 去恢复之前的状态。
git log shows the commit log accessible from the refs (heads, tags, remotes)
git reflog is a record of all commits that are or were referenced in your repo at any time.
That is why git reflog (a local recording which is pruned after 90 days by default) is used when you do a “destructive” operation (like deleting a branch), in order to get back the SHA1 that was referenced by that branch.
See git config
参考：https://stackoverflow.com/questions/17857723/whats-the-difference-between-git-reflog-and-log
HEAD@{2} means “where HEAD used to be two moves ago”, master@{one.week.ago}means “where master used to point to one week ago in this local repository”
HEAD@{2}表示HEAD指针在两次移动之前的情况；而 master@{one.week.ago}表示master在本地仓库一周之前的情况。
1 | git reflog <subcommand> <options> |
1 | git reflog [show] [log-options] [<ref>] |
“expire”子命令会删除掉更老的reflog条目。
“delete”子命令从reflog中删除一个条目。
“exists”子命令检查一个ref是否有一个reflog。
reflog 跟 log 一样也可以自定义输出格式1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43%H: commit hash
%h: 缩短的commit hash
%T: tree hash
%t: 缩短的 tree hash
%P: parent hashes
%p: 缩短的 parent hashes
%an: 作者名字
%aN: mailmap的作者名字 (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1))
%ae: 作者邮箱
%aE: 作者邮箱 (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1))
%ad: 日期 (--date= 制定的格式)
%aD: 日期, RFC2822格式
%ar: 日期, 相对格式(1 day ago)
%at: 日期, UNIX timestamp
%ai: 日期, ISO 8601 格式
%cn: 提交者名字
%cN: 提交者名字 (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1))
%ce: 提交者 email
%cE: 提交者 email (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1))
%cd: 提交日期 (--date= 制定的格式)
%cD: 提交日期, RFC2822格式
%cr: 提交日期, 相对格式(1 day ago)
%ct: 提交日期, UNIX timestamp
%ci: 提交日期, ISO 8601 格式
%d: ref名称
%e: encoding
%s: commit信息标题
%f: sanitized subject line, suitable for a filename
%b: commit信息内容
%N: commit notes
%gD: reflog selector, e.g., refs/stash@{1}
%gd: shortened reflog selector, e.g., stash@{1}
%gs: reflog subject
%Cred: 切换到红色
%Cgreen: 切换到绿色
%Cblue: 切换到蓝色
%Creset: 重设颜色
%C(...): 制定颜色, as described in color.branch.* config option
%m: left, right or boundary mark
%n: 换行
%%: a raw %
%x00: print a byte from a hex code
%w([[,[,]]]): switch line wrapping, like the -w option of git-shortlog(1)
git 建分支很 cheap，本地和远程都常常各自拥有大量分支，有时本地分支需要跟某个新的远程分支建立追踪映射，以便于在 pull、 push 等操作时，简化命令，也在一定程度上防止误传到其他分支。今天建立了新的远程分支，本地不想弄一个新的跟它对应，想用当前分支换个关联，用到了该技能。
pull 代码再次遇到冲突，这次突发奇想，想试试用 git stash 来处理，结果 push 完，队友反映她 pull 后好多代码被重置，并且遇到严重冲突，受牵连70几个文件。我查看了下 commit 记录，惊讶地发现，我处理完冲突传上去的代码确实都变成了我本地的老代码，pull 下来的修改都被我重置了。都是乱用 git stash 的错。。还好发现的及时，我立即决定撤回远程仓库中我的那次 push，让代码回滚到我 push 前的状态。那么如何让远程仓库回退到某个之前的版本？步骤如下。