Cheatsheet

用 Figma 直接输出带透明背景的图标，替代之前用"预览"的方式。 ...

两步搞定：用"预览"去掉图标背景，再把透明 PNG 拖进 Xcode 的 AppIcon。 ...

两步搞定 SSH 跳板机：配置 ~/.ssh/config，再分发公钥，之后就能一条命令直连目标机器。 ...

本文仅用于有洁癖者(本人)统一 markdown 风格, 以及 check style 行文 标点 除非必要, 所有标点都使用英文标点 强调 说明性的词和短语用双引号("")强调 提示性的词和短语用双星号(**)强调 结论性的短语和句子用三星号(***)强调 删除 ~~删除的文字~~ -> 删除的文字 空格 第一级列表标记(比如*)前不需要空格 英文单词的前后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 如果英文单词在括号里, 则前后的空格写在括号外, 比如 " (abc) " 或 " (abc 很不错)" 左引号前和右引号后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 强调标记的前后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 链接 行文中需要文字的, 使用引用方式 直接贴链接不影响行文的, 可以直接贴连接 比如 少量 不是很长 且 在行尾 的链接 比如 少量 不是很长 的链接列表 其它情况均需要使用引用方式, 引用需要集中写在文章或段落末尾 [Display Name][name] ... [name]: http://external.link "Link Description" [name]: /blog/yyyy/MM/dd/internal-link/ "Link Description" 更新 在文档末尾添加 **** Update@yyyy.MM.dd: 更新的内容 大小写 TODO 用词 举例时用 “比如”, 不用 “如”; “比如” 后面不加冒号, 除非后面跟着列表 并列时用 “和”, 不用 “及”; 除非需要使用 “以及” “其他” 修饰人, “其它” 修饰非人 代码 单行模式 一行可执行代码使用变音符号(`)单行模式 一行文本内容使用变音符号单行模式或 pre-code 多行模式 特殊记号使用变音符号单行模式 比如文件路径 C:\Windows 比如代码元素 ++ -- 变音符号单行模式的空格规则同引号 可执行代码和支持代码高亮的文本 使用变音符号(`)多行模式 支持代码高亮的语言列表: http://pygments.org/docs/lexers/ 不支持代码高亮的文本内容 使用 pre-code 多行模式 打开该文本文件的命令可以写在一起, 命令和文本之间空一行

常用命令 find find . -name "*.xyz" find . -name "*abc*" -delete grep grep -i "abc" * # 忽略大小写 grep -R "abc" . wc wc -l find -name "*.java" # 统计 java 代码行数 权限 chmod u+x <file> # 设为可执行文件 chown <name> <file> chown -R <name> <dir> chgrp ... # 格式同 chown 系统工具 ssh ssh-add -D删除所有记住的key 解决 Mac 下所有使用过的 key 都会被记住，删除 key 文件没用的问题 链接库 查看链接库是否缺失: ldd <可执行文件> 修改系统加载库 vim /etc/ld.so.conf /sbin/ldconfig

基本操作 创建版本库: git init 克隆版本库 git clone /path/to/repo git clone user@host:/path/to/repo 多版本库: git remote add <repo-name> <repo> 多版本库列表: git remote -v 更新版本库 git pull [repo-name] repo-name 默认为 origin git pull --rebase 可以避免无意义的 pull-merge, 使版本树尽可能是一条直线 git fetch [repo-name] - git pull does a git fetch followed by a git merge repo-name 默认为 origin 会把 repo-name 的更新都 fetch 到本地, 包括新分枝和新标签, 但不会建立本地分枝 提交到本地 stage: git add <file/dir> git commit -m "<comment>" 对于已经处于版本控制中的文件, 可以使用 git commit -am "<comment>" 略过 stage 有时需要构造空提交: git commit --allow-empty -m "EMPTY" 提交到远程 git push [repo-name] [branch] repo-name 默认为 origin, branch 默认为当前分枝 git push -u <repo-name> <branch> 设置 push/pull 时默认使用的 repo-name git push <repo-name> <branch>:<remote-branch> - 如果本地和远程分枝名字不同 反悔 revert stage: git reset HEAD <file> reset working: git checkout -- <file> restore(1+2): git checkout HEAD <file> checkout 上一个版本, 放在 stage/working 中: git checkout HEAD~ <file> 如果改动, add, 再改动, 使用 1. 不会恢复到第一次改动的结果; 使用 2. 才行! git reset <rev> [file] 没有 file 把 HEAD/branch 指向 rev 有 file 把 rev 版本的 file checkout 出来 如果 --hard, 那么 stage 和 working 都更新为 rev; 如果 --soft, 那么 stage 和 working 都不变(但 git status 会发现有文件 stage 了, 这是相对运动的结果); 如果 --mixed (默认), 那么只更新 stage (这时 git status 会发现 working 中有改动, 原因同上) rev 默认为 HEAD: 如果 --hard, 那么 stage 和 working 都更新为 HEAD (和 3. 效果一样); --soft 没意义; 如果 --mixed, 那么只更新 stage (就是 1. 咯~) 没有 file 时 --hard 类似于 checkout, 区别在于 reset <rev> 会移动 branch 指针, checkout <branch> 回不去, 而 checkout <rev> 再 checkout <branch> 可以回去 放弃所有本地改动(含本地提交): git reset --hard <repo-name>/<remote-branch> git checkout <rev> [file] 没有 file 会建立一个 detached HEAD (匿名分枝) - 最好别用! 有 file 把 rev 版本的 file checkout 出来 rev 默认为 -- 即 stage, 从 stage checkout 到 working 其它 rev 从 rev checkout 到 stage 再到 working git revert <rev>: 类似 svn 中的倒着 merge, 生成一个新版本 V+, 和 V-完全一样 - 仅用于 revert 一个很久以前的错误改动! 修改已经 push 到远程的提交 使用下面的方法修改已经 push 到远程的提交 git push <repo-name> +<branch>:<remote-branch> 修改上一个提交: git commit --amend 修改多个提交(交互式) git rebase -i <rev>, 编辑 rev 之后的提交, rev 默认为 repo-name/remote-branch 对于想合并到前一个的提交, 选择 fixup 对于想删除的提交, 直接删除对应的行 将上 N 个提交合并成一个 git reset --soft HEAD^(N-1) git commit --amend 分枝 建立分枝: git checkout -b <branch> 在当前 HEAD 上创建分枝并切换到新分枝 git checkout -b <branch> <repo-name>/<remote-branch> 跟踪远程分枝 切换分枝: git checkout <branch> 删除分枝: git branch -d <branch> 对于没有合并或提交到远程的分枝, 删除时会提示用 -D 强制删除 将分枝提交到远程(在远程建立新分枝): git push <repo-name> <branch> 提交到远程之后, 如果希望能够 pull 该分枝, 需要 git push -u 删除远程分枝: git push <repo-name> :<remote-branch> 删除已删除远程分枝的本地缓存: git remote prune origin 查看所有分枝: git branch -av git branch 不显示远程分枝 diff 分枝 diff: git diff <src-branch> <tgt-branch> (tgt 默认为当前分枝) 如果是和 master 比较, src-branch 应该是master 版本 diff: git diff <src-rev> <tgt-rev> (tgt 默认为当前版本) src-rev 应该是比 tgt-rev 更老的版本(祖先版本) git merge-base <src-branch> <tgt-branch> 可能可以得到你需要的 src-rev 其它 diff working 和 stage 的 diff: git diff stage 和 HEAD 的 diff: git diff --cached working 和 HEAD 的 diff: git diff HEAD 注意 上述 3 种方式都不会 diff 新文件(未处于版本控制中的文件) 合并 合并 branch 到当前分枝: git merge <branch> fetch 后用 git merge <repo-name>/<remote-branch> merge 如果 merge <branch>, 修改 branch, 再 merge, 只 merge 修改的部分 合并冲突时, 不 merge 而是指定某个版本: git checkout --ours/--theirs <file> “复制” 一次提交(比如某个分枝只有一次提交需要保留): git cherry-pick <rev> 停止 “复制”: git cherry-pick --abort 将当前分枝 rebase 到 tgt-branch: git rebase <tgt-branch> merge 与 rebase 的区别 merge 建立了一个新版本, 而 rebase 是分枝上有多少新版本, 就会建立多少新版本 rebase 后需要再做一次快速 merge, 才能使 tgt-branch 的指针正确(两者指针移动方式不同) 查看状态信息 git status git log git reflog: 查看 HEAD 指针的移动历史 git branch --merge: 查看哪些分枝已被合并到当前分枝 git branch --no-merged: 查看尚未合并的分枝 git remote show <repo-name>: 查看远程信息 暂存 git stash git stash pop git stash list git stash clear git stash apply stash@{x} git stash drop stash@{x} git stash branch <branch> 标签 git tag # 标签列表 git tag <tag> # 在当前版本上打标签 git show <tag> # 查看标签 git tag -d <tag> # 删除标签 git push <repo-name> <tag> # 提交标签 git push <repo-name> :<tag> # 删除远程标签 submodule @2015.04.13 git submodule add <remote-path> [<local-path>] # 添加 remote-path 为当前项目的 submodule git rm -r <local-path> # 如果有问题, 试试 git rm --cached <local-path> vim .gitmodules # 通常会在 git rm 时自动执行 git commit rm -rf .git/modules/<local-path> # 可能不必要 vim .git/config

信息焦虑的第二个症状：换过好几个博客，但都因为配置复杂、格式不可控、备份麻烦等原因放弃了。 作为一个程序员，深深地为自己不能迅速地把博客搞定而惭愧。在构思许久之后，终于还是决定先偷懒，把习惯陪养起来再说。Octopress 还是非常符合我审美的，没有太多可配置的东西，所有格式都能自己掌控，更不用说备份——噢！又犯病了。。。 唐巧的博客很容易搜到，但我还是建议第一次搞的同学看一下官网。如果你像我一样在使用最新版的 MacOS，那么 ruby 部分就会简化许多： git clone git://github.com/imathis/octopress.git octopress cd octopress sudo gem install bundler bundle install rake install rake new_post['Article Name'] 写作就是 MarkDown 了, 虽然和 wiki 的写法有些差异, 容易记混. 通常我都会使用 Sublime Text + MarkDown 插件, 同时运行 rake preview 进行调试(-___-b). Preview 模式下, published:false 的文章会是可见的; 可能由于 bug, 如果你开着 preview 运行 deploy, published:false 的文章也会是可见的… rake deploy 前务必退出 preview, 并运行 rake generate. rake deploy 之前，要 git add 和 git push origin source, git 新手（像我）往往都习惯于顺手来个 git pull。唔，然后就悲剧了。因为这个时候 git 已经很傻地把你的 source 分枝和远程的 master 分枝关联在一起了，所以 pull 的时候会没头没脑地要 merge 这两个分枝。已经 merge 的怎么回退我就不说了，还没 pull 的，先修改一下 config 文件。 ...