使用git reflog命令，查看当前仓库的操作日志。在日志中找出 回溯历史之前的哈希值，通过 git reset --hard命令恢复到回溯历史前的状态。
只要不进行 Git 的 GC（Garbage Collection，垃圾回收）， 就可以通过日志随意调取近期的历史状态。
哈希值只要输入 4 位以上就可以执行。
要修改上一条提交信息，可以使用 git commit --amend命令。
git rebase -i——压缩历史
在合并特性分支之前，如果发现已提交的内容中有些许拼写错误等， 不妨提交一个修改，然后将这个修改包含到前一个提交之中，压缩成一个历史记录。可以用 git commit -am 来完成这两步操作
错字漏字等失误称作 typo，所以我们将提交信息记为 "Fix typo"。
git rebase——在历史记录中合并为一次的提交。
git rebase可以选定当前分支中包含 HEAD（最新提交）在内的两个最新历史记录为对象，并在编辑器中打开。
推送至远程仓库——创建远程仓库时不要勾选 Initialize this repository with a README 选项, 因为一旦勾 选该选项，GitHub 一侧的仓库就会自动生成 README 文件，从创建之初便与本地仓库失去了整合性。虽然到时也可以强制覆盖，但为防止这一情况发生还是建议不要勾选该选项，直接点击 create repository创建仓库。
用 git remote add命令将它设置成本地仓库的远程仓库。
执行git remote add命令之后，Git 会自动将远程仓库的名称设置为 origin（标识符）。
git push——推送至远程仓库。-u参数可以在推送的同时，将 origin 仓库的 master 分支设置为本地仓库当前分支的 upstream（上游）。添加了这个参数，将来 运行 git pull命令从远程仓库获取内容时，本地仓库的这个分支就可以直接从 origin 的 master 分支获取内容，省去了另外添加参数的麻烦。
远程仓库也可创建其他分支。
git clone——获取远程仓库。（注意不要再之前操作的仓库下）
git branch -a命令查看当前分支的相关信息。添加 -a 参数可以同时显示本地仓库和远程仓库的分支信息。
如果两人同时修改了同一部分的源代码，push 时就很容易发生冲突。所以多名开发者在同一个分支中进行作业时，为减少冲突情况的发生，建议更频繁地进行 push 和 pull 操作。
在各个页面按下 shift ＋ / 都可以打开键盘快捷键。
Gist 功能主要用于管理及发布一些没必要保存在仓库中的代码，比如小的代码片段等。
Raw 可以直接在 浏览器中显示该文件的内容。使用这个 URL，就能通过 HTTPS 协议获 取该文件。Blame 能够按行显示最新提交的信息，如果将"#La"改成"#La-b"，则会标记该文件的第 a～b行。
比如我们想查看 A 分支与 B 分支之间的差别，可以 像下面这样将分支名加到 URL 里：
https://github.com/... /compare/A...B
这样，就可以查看两个分支间的差别。
查看 master 分支在最近n 天内的差别，可以像下面这样 这样将时间加入 URL:
https://github.com/... /compare/master@{n.day.ago}...master
● day ● week ● month ● year 指定期间可以使用以上四个时间。
假设我们想查看 master分支 yyyy 年 mm 月 dd 日与现在的区别，可以 将日期加入 URL:
https://github.com/... /compare/master@{yyyy-mm-dd}...master
管理 Issue 的系统称为 BTS（Bug Tracking System，BUG 跟踪系统）
遇到下面几种情况时，各位就可以使用这个功能。
● 发现软件的 BUG 并报告
● 有事想向作者询问、探讨
● 事先列出今后准备实施的任务
GitHub 的 Issue 及评论可以使用 GFM语法进行描述
只需将图片拖曳到文本框中便可以粘贴图片。
添加标签以便整理 I s sue 可以通过添加标签（Labe l）来进行整理。添加标签后，Issue的左侧就会显示标签（图 5.15）。点击页面左侧的标签，还可以只显示该类标签的 Issue。
标签可以自由创建。
小建议：其实在Issue 比较少的情况下不必每个都添加标签， 大可等Issue积攒到一定数量，只有进行筛选才能清晰把握时再添加 标签。
还可以通过添加里程碑（milestone）来管理Issue。
规范的内容一般包括报告时 Issue 的描述方法、Pull Request 时的规则或要求、许可证的相关信息等。
GFM 的一项独有功能——Tasklist 语法 。
# Examples
- [ ] text A
- [x] text B
- [ ] text C
这段文字就会被标记成复选列表的样式。这个复选列表可以直接勾选或者取消，不必打开 Issue 的编辑页面重新编辑。
描述 Issue 时，常常会看到图 a中这种贡献规范的链接。在该仓库的根目录下添加 CONTRIBUTING. md 文件后该链接就会显示出来。规范的内容一 般包括报告时 Issue的描述方法、Pull Request 时的规则或要求、许可证的相关信息等。
只要在提交信息的描述中加入"#issueNumber"，就可以在Issue中显示该提交的相关信息，使关联的提交一目了然。这里只需点击一下便可以显示相应提交的具体内容，在代码审查时省去了从大量提交日志中搜索相应提交的麻烦。
如果一个处于 Open 状态的 Issue 已经处理完毕，只要在该提交中以下列任意一种格式描述提交信息，对应的 Issue 就会被 Close。
- fix #issueNumber
- fixes #issueNumber
- fixed #issueNumber
- close #issueNumber
- closes #issueNumber
- closed #issueNumber
- resolve #issueNumber
- resolves#issueNumber
- resolved #issueNumber
利用这个方法， 每次提交并 push之后， 就不必到 GitHub 的 Issue 中寻找相应 Issue 再手动Close。
Issue与 Pull Request 的编号通用即可。
Pull Request 是用户修改代码后向对方仓库发送采纳请求的功能，也是 GitHub 的核心功能
如果想获取 diff 格式的文件，在 URL 末尾 添加 . diff 即可。
https://github.com/用户名/仓库名/pull/28. diff
同 理， 想 要 patch 格 式 的 文 件， 只 需 要 在 URL 末 尾 添 加 . patch 即可。
https://github.com/用户名/仓库名/pull/28. patch
提交日志的右侧有该提交的哈希值，点击链接即可确认相应提交的详细信息。
选中想引用的评论然 后按 R 键，被选择的部分就会自动以评论语法写入评论文本框。
评论中输入 : 便会启动表情自动补全功能。登录 http://www.emoji-cheat-sheet.com/ 查找可使用的表情。
Files Changed 标签页中可以查看当前 Pull Request 更改的文件内容以及前后差别。标签上的数字表示新建及被更改的文件数。
只要在 URL 的末尾添加"?w=1"就可以不显示空格的差别。
Wiki 是一个编写文档的功能，适合用来针对更新频率较高的软件进行文档等信息方面的汇总。
用户能够通过 clone 操作获取 Wiki 仓库，然后在本地创建、编辑页面，进行提交再 push， 便可以完成对 Wiki 的创建及编辑工作。
在 Pages 标签页中可以列表查看 Wiki 页面。
所有 Wiki 页面都可以显示侧边栏。只要创建名为"_sidebar"的页面即可。_sidebar 页不会显示在 Pages 的页面一览中。在编辑各页面时页面下部会附加 Sidebar 段， 用户可以在这里编辑侧边栏的内容。
Pulse 是体现该仓库软件开发活跃度的功能。
GitHub 有一个名为 GitHub Pages 的仓库，用户可以利用该仓库中的资料创建 Web 页，用来发布仓库中软件的相关信息。如果已经创建过 GitHub Pages，则会显示相应 URL。点击 Automatic Page Generator 即可 以自动创建 GitHub Pages
Danger Zone设置——用户可以将仓库改为私有或是变更仓库所有者，甚至删除仓库本身。
Collaborators 用户主要在这里设置仓库的访问权限。如果仓库隶属于个人账户， 那么可以添加 GitHub 的用户名，赋予该用户直接读写仓库的权限。
如果仓库隶属于 Organization 账户，则需要先创建 Team，然后赋予该 Team 读写仓库的权限。
在 GitHub 上发送 Pull Request 后，接收方的仓库会创建一个附带源代码的 Issue，我们在这个 Issue 中记录详细内容。
PR is short for Pull Request.