#18 楼 @sundevilyang [email protected]

#29 楼 @dfang NERDtree 和 Ctrl-P 我都没有在用，所以回答不了你的问题了。我只是感觉 fuzzyfinder 和 vim 自己的 command-line mode 太强大了。 #35 楼 @AlphaLiu

没太理解问题是什么，不过不知大家有没有试试 vim 的 lcd 命令

#17 楼 @zhex 对，其实这样也是干净利落

这样又可以省几个字符

:so %

#8 楼 @sundevilyang Thank for your kindness, but maybe not this time. Cause I still can not make sure if I can be there this time. Things have been messy recently

#25 楼 @dfang 试试这个

imap kk :updatea

我自己临时凑出来的，肯定能用，但肯定不是完美解决方案。

不用 <c-s> 是因为 Ctrl+* 系列的快捷键很多情况下都有特殊用途，很容易被 gnome 或是 terminal 之类的东西半路截住。

估计能到场，努力努力

#19 楼 @dfang I don't use "ctrl-p", not sure if it has a fuzzy mode or not. I love fuzzyfiner. With fuzzyfinder ( http://happycasts.net/episodes/24 ), your request call be easily accomplished.

#37 楼 @dfang

"单独维护比较好...可以 fork 下来，然后定制下" Feels nice

#15 楼 @lyfi2003 对，也有很多人会对这个命令做个快捷键映射，如

map ,r :source ~/.vimrc

手动的东西总是较让人放心。

#35 楼 @dfang 我遇到的问题是在 vim72 + vundle 使用时，安装插件时不能像正常的那样显示哪个插件已经装完，哪个正在安装。相信如果我把 vim 升级到 73 应该就没有这个问题了，所以理论上讲不是问题，实际开发中诸如此类的小问题还是有点烦人。

vim + pathogen 功能相对较弱，使用较为不酷，但是很多时候简单笨拙确实更高效。

说说 vundle 的问题：

1. 有一个我还没有搞清楚的问题，如果我有几个自己写的小插件，那用 vundle 如何处理呢？是不是还要把每个都单独上传到 github 之后才行呢？如果是这样，就略显繁琐了。
2. 如果我想把我的插件分享给别人，在使用 vundle 的时候，别人不但要会用 git 还要了解 vundle，这也略显繁琐。
3. 如果别人想使用我用 pathogen 管理的 .vim, 他只要 clone 一个 git repo 就可以了，使用 vundle 我要保证十几个几十个 git repo 都健在，略显风险大。

本评论略显啰嗦 我还是等待 vundle 真正成熟的那一天。

#33 楼 @lovejoy vundle will be talked in detail in the revised version of this episode

#9 楼 @zw963 #31 楼 @hisea

#13 楼 @lidashuang Yes

#11 楼 @suupic 录屏用：screenflow, 按键显示：keycastr http://happycasts.net/about

#9 楼 @chinacheng 这个我得重视起来

#5 楼 @chinacheng 可以尝试“下载”，或者到 youku 去观看，网页上都有相应链接的。 视频是放在 Linode 东京。个别时候确实存在连接不上的问题。其实我的需求比较单纯，就是能跑 rails，并托管视频就行，现在正在寻找提速方案，求各位指点

#4 楼 @lgn21st 回复：

1. 有道理，会尽快加的

2. vimrc 里加这一行

   autocmd! bufwritepost vimrc source ~/.vim/vimrc

   NOTE: 我首先 mv .vimrc .vim/vimrc, 然后做了个符号链接 ln -s ~/.vim/vimrc ~/.vimrc

3. 这个视频的实例部分太干瘪，这是硬伤，改进版里会解决这个问题 不过，前面的原理部分对于有些 unix 初入门者还是有点用的。Happycasts 会尽量对 0 基础学习者友好。

#2 楼 @googya 果然是很优秀的资源

@azhao @billie @camel @cantin @chucai @dfang @ery @googya @jiffies @jinleileiking @jjym @kenshin54 @lex @lgn21st @lidashuang @linjunpop @lyfi2003 @poshboytl @rainly @randuin @reducm @sectic @stc @superbatironmans5 @tudou @toy @thisiskun @xmonkeycn @xufeng @ywjno @zhangyuan @AlphaLiu @PrideChung

希望大家多给批评建议，每个视频都会有改进版，将来我会把大家的智慧都融入到改进版里的，谢谢

#31 楼 @randuin 差不多这里有 6 个人推荐 vundle 了，算我自己 7 个，最近几天在各个平台各个 vim 较老版本中用了一下 vundle，零星的小问题还是有一些的。

通常我们的一个项目中会包含两个东东：

1. .git/ 目录，这个其实是一个 git 项目的心脏
2. 除了 .git/ 之外的其他文件，我们叫做 working tree，是浮云

working tree 其实最初就是 .git/ 中的某个 branch 的一个 checkout。当我们对 working tree 做修改，那么此时它的内容就会和 .git/ 中它对应的那个分支有差异，此时 git 会检测到这个差异，也就认为 working tree 上现在有了一个 patch. 对应您上面的情况，此时 git 检测到的 patch 就是 README 中的修改内容。

当我们从 test 转回 master 时，git 的默认行为是：

1. 删除 test 对应的 working tree
2. checkout 出 master 分支的 working tree
3. 对新的 working tree 打刚才的那个 patch, 有 conflict 则放弃，没有就成功

如果您“可以看到 modify_on_test_branch 的修改”，那证明这个 patch 恰巧打成功了，其实实际开发中十有八九是失败的。

现在，我们重回 test 分支，运行

git commit -am 'commit on test branch'

那么我们刚才的那个 patch 就被添加到了 .git/ 之中，亦即 .git/ 中的 test 分支和现在的 working tree 又一样了，一样就没有了 patch, 那自然再次回 master 的时候也就没有什么 patch 好打了。

我研究生同学 @luckyyang, 毕业后工作一年（也差不多是你这个年龄）才被我忽悠搞开发，到现在也有一年多，看起来也算 happy。

所以我表示支持你，if 你是个勤奋的人 and 英文足够好

http://gitref.org/

一些简单基础的命令

#2 楼 @huacnlee 不过最终结果感觉很专业啊，颜色很舒服

https://github.com/styleguide/ 这个是很牛的东西，一定要顶起

#27 楼 @reducm 是 keycastr，跑在 Mac 上，其实录屏时我的 ubuntu 是跑在虚拟机里的。

目前这书还有很大工作量，大家积极参与吧。我也是个参与者，有写权限，大家发 pull request，我和 @billie66 会及时相应的。