Cheatsheet on Binary Life

macOS 应用图标：用 Figma 制作超椭圆图标

Sat, 04 Apr 2026 00:00:00 +0000

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

macOS 应用图标：去背景 + 导入 Xcode

Sat, 28 Mar 2026 00:00:00 +0000

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

通过跳板机 SSH 一键登录

Fri, 20 Mar 2026 00:00:00 +0000

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

Markdown Style

Mon, 16 Dec 2013 15:26:28 +0800

本文仅用于有洁癖者(本人)统一 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 多行模式
打开该文本文件的命令可以写在一起, 命令和文本之间空一行

Linux 手册

Sun, 08 Dec 2013 12:13:45 +0800

常用命令

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 手册

Tue, 03 Dec 2013 18:13:53 +0800

基本操作

创建版本库: 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 到远程的提交
1. 使用下面的方法修改已经 push 到远程的提交
2. git push <repo-name> +<branch>:<remote-branch>
修改上一个提交: git commit --amend
修改多个提交(交互式)
1. git rebase -i <rev>, 编辑 rev 之后的提交, rev 默认为 repo-name/remote-branch
2. 对于想合并到前一个的提交, 选择 fixup
3. 对于想删除的提交, 直接删除对应的行
将上 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>

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 新手小记

Sun, 24 Nov 2013 21:10:28 +0800

信息焦虑的第二个症状：换过好几个博客，但都因为配置复杂、格式不可控、备份麻烦等原因放弃了。

作为一个程序员，深深地为自己不能迅速地把博客搞定而惭愧。在构思许久之后，终于还是决定先偷懒，把习惯陪养起来再说。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 文件。