你要类比也应该拿 switch / case / if / else 来类比啊， goto 躺枪

@hronro 你难道 checkout 命令在分支后面多打了个点？貌似 checkout 命令这个行为是挺坑爹的。明明是 svn revert 命令要比 git checkout 合理的多

得到了一个 secret 帽子，是假面具。。。

@ioiioi 如果你不希望出现菱形合并，那么
git reset A0
git stash
git pull
git stash pop
然后提交你的变更就好了

第一个 reset 命令不会丢失任何本地变更，也不会丢失 A1 的变更
相反 A1 变更都回到了本地
为避免 pull 发生冲突， stash 一下是比较安全的做法

啊啊那个 65m 的无视，这是个 179k 的
https://www.apple.com/downloads/dashboard/status/countdowndashboardwidget.html

如果没有 -f 过，那必然是被 commit 所覆盖了， git blame 一般能找出来是被哪次 commit 覆盖的
如果 -f 过的话，原因会比较复杂，但在协作上一般不太可能

我觉得更大可能是开发者不熟悉 git ，在自己分支上开发 pull 的时候执行了错误的合并以及 conflict 处理所导致

『老板我』这个主语好叼

jar 里面的用 -injar
jar 外面的用 -libjar

居然手快打错了
git backup -> git branch backup

显然你的信息存在误导的地方
假如你的信息是正确的，版本的衍生过程是
家里: A0 - A1 (edit file.txt)
公司: A0 - A2 (edit file.txt)
repo: A0 - A2 (edit file.txt)

如果是正确的话， git reset --hard HEAD^ 就回到了 A0 这个点， pull 不会有任何冲突
肯定是你做了不止一个提交才会有这种情况

如果你确定本地所有变更都是无用的，可以直接放弃所有
git fetch origin
git backup # 为防止你做错事情，先备份一下
git checkout master # 回到 master
git reset --hard origin/master

你这个定义应该放内存里而不是数据表里
如果真的要做到可配置，那么放个某个配置文件里面就可以了
至于喷性能的是什么心态？实现上难道不应该 100%放内存，难道每次 api 解释还查数据库？

使用 Jekyll 最坑的地方在于， Github-Pages 不定期的更新
这货的兼容性几乎无任何保障
而且 Github-Pages 对一切 Warning 都持不允许的态度

对于我这种，半年都不更一次博客的懒人来讲，每次想更新一下，就要折腾半天改 config 甚至还要改 ruby 代码来适配它的兼容性变化，无疑让我更不愿意去更新博客了

国际惯例是 user
如果你是开银行的，应该明白 user 和 account 的差异
再如果你是运营京东或 QQ 的，也应该明白 member ≠ user