我只是学git时候知道有这个命令，后来工作中感觉用处不大，就没有用过。
我觉得用东西还是以需求为导向，有需求就找相关的命令，而不是尽可能多的各种各样的命令和参数。
前面提到的那几个命令都是我日常最常用的，多人开发分支切换合并等日常需求基本都能覆盖到。
【 在 hyperLee 的大作中提到: 】
: 这楼里边就有用git reset的呢。再说你到网上搜一下 git 浏览历史版本， 你看有几个网页不是讲 git reset的？
: 我自己当然用git checkout，但那也是踩坑后才研究出来的。
:
--
FROM 59.109.146.*

git太复杂，不适合直接面对用户，更适合当一个底层的infrastructure，如今这么流行，我猜测可能主要还是靠github上的海量资源。

【 在 hyperLee 的大作中提到: 】
: 今天看checkout， branch， switch功能， 都震惊了， 分支和commit的关系难道不应该在第一步就设计好吗？ 到了2.23 才觉得checkout功能承载太多，于是分裂出两个新的命令。
: 关键branch和switch功能还是重叠的。
: git的发展过程， 很明显就是凑合，再凑合， 然后改改， 继续凑合，结果文档虽然庞杂，在github的加持下拥趸也不少， 但功能设计就是一笔糊涂账。
: ...................
--
FROM 123.112.69.*

1 repo中的某个版本刷新到working tree，这个刷新就是合并。挺好，显式的动作。
2 reflog没有丢就好。猜测你说的软件，是reset后，show log后，可以看到最远的log，而不是只显示到所在版本这个区别。
有时不是写的代码复杂，是业务本身复杂。你做架构给同事们用时，就会深有体会。包括vim，实际是对“编辑、编码、修改代码”这个业务本身，进行了大量的抽象。至于这种抽象，不掌握也能干活。就像鼠标点点选选。有人用svn或git，怕搞不定，就拷贝一个副本，pull完再拷贝回来。都行。至于抽象质量的高低，就是看能不能通过尽可能少的正交的概念，覆盖所有业务，其次是方便理解。
git项目是不是shit mountain，跟git的使用体验没关系。要看代码本身多少行，写的怎么样，要增加、修改一个功能难不难。
【 在 hyperLee 的大作中提到: 】
: 1 mercurial中， 和git一样是区分working tree和repo的。repo中就是历史版本的“数据库”， mercurial中你要是pull的话， 只是拉去对方的repo，而当前working tree根本不涉及， 所以无论你working tree处于什么状态， 都所谓。
: 但是你要将repo中的某个版本刷新到working tree中，这时候mercurial会提醒你，如果Work tree中有改动。 这时候你可以有各种选择，比如强制刷新，比如shelve（把改动暂存起来，刷新后有必要的话手动在恢复出来）或者放弃等。重要的是，所有的选择产生的结果都符合你的直觉，不会说把你的某个提交搞得隐藏起来，让你都不知道。
: 2 你要是用git checkout的话，没问题；你要是用git reset的话， 你自己看一下log，不就知道效果了？reflog是没有丢，但你能在改动历史中看到吗？
: ...................
--
FROM 61.185.159.*

vim 这东西，连 edit 都不如，搞不懂怎么流行了那么久
【 在 DoorWay (DoorWay) 的大作中提到: 】
: 1 repo中的某个版本刷新到working tree，这个刷新就是合并。挺好，显式的动作。
: 2 reflog没有丢就好。猜测你说的软件，是reset后，show log后，可以看到最远的log，而不是只显示到所在版本这个区别。
: 有时不是写的代码复杂，是业务本身复杂。你做架构给同事们用时，就会深有体会。包括vim，实际是对“编辑、编码、修改代码”这个业务本身，进行了大量的抽象。至于这种抽象，不掌握也能干活。就像鼠标点点选选。有人用svn或git，怕搞不定，就拷贝一个副本，pull完再拷贝
: ...................
--
FROM 111.28.164.*

空文件夹到现在还不被支持
【 在 leadu (leadu) 的大作中提到: 】
: git的fetch pull stage, stash index设计真是很烂，别的scm都搞得清清楚楚的，到它这给搅成一坨，明显设计人员压根就没有概念
: 权限管理和submodule就更别提了，玩闹一样。
: changeset什么的高级功能就等着GitHub给它轮
: ...................
--
FROM 111.28.164.*