多看了一眼
哦
原来是 windows

这命令又不会删除任何实质性东西的，仅仅是修改了 index
reset 不就回来了吗

generic / covariant / invariant

这几个概念建议都要看一下

早期的 java 没有泛型，但有数组，而数组在 java 语言里面是定义为 covariant 的，也就是赋值相容的，这其实是一个错误，因为把一个 String[] 类型转换为 Object[] 没有任何警告，但以后的元素赋值可能会产生 ClassCastException

Java 泛型的设计纠正了这个错误，是 invariant 的，也就是赋值不相容，你不能把 List<String> 直接当成 List<Object> 来用，但可以当做 List<? extends Object> 来用，自然而然， extends 和 super 关键字就是必须的了

invariant 的泛型也给编程带来很多麻烦，因为无法进行类型转换（当然，因为 java 的泛型是擦除的，强制转换并且消除警告也总是有办法做到的）

进一步的，如果你有看过 kotlin 的话，有专门章节介绍泛型， kotin 用 in / out 标记来代替了 extends / super ， in / out 关键字不仅仅能修饰泛型参数类型，还能用来修饰泛型参数声明，配合不可变集合类型就能够支持 convariant 泛型（赋值相容）

比如 kotlin 的 List 是不可变的，其接口声明是 interface List<out E>;
意思是只能从里面取出来 E 类型的元素，不能保存
那么 List<String> 和 List<Object> 就变得赋值相容了

长连接的首要前提数据协议必须可分段，而且你得知道协议分段的细节，怎么可能有通用方案

你要类比也应该拿 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