progit

如果愿意花点银子，推荐这个 https://tutsplus.com/course/git-essentials/

http://git-scm.com/book/zh

#3 楼 @Rei #1 楼 @jinleileiking 嗯，在看这个书

http://gitref.org/

一些简单基础的命令

#1 楼 @jinleileiking #2 楼 @lichao #3 楼 @Rei #5 楼 @happypeter

git branch test 新建一个 test 分支 git checkout text切换到新分支 echo modify_on_test_branch >> README

然后切换到 master 分支，为什么可以看到 modify_on_test_branch 的修改呢？

还有现在切换到 test 分支，git commit -am 'commit on test branch'

这样提交之后就在 master 分支看不到 modify_on_test_branch 的修改了，为什么呢？

#6 楼 @kikyous 推导一下就知道啦：不 commit 的内容不会进入分支

Git 最好的教程是那个 Git pro.

不过如果想提高，想进阶，去找男人吧。超级详细。很多我原先不明白的，后来都是找男人解决的。

如果不去使用多分支的开发流程，就很难去接触Git最精彩的部分，这样相比 svn 等还多了一步复杂的过程git add。

学习一项技能就是要去适应他的方法，而不是让他适应自己。

git add git commit git push git pull git branch git checkout

一开始只接触几个基本命令就足够的，后面的用多了慢慢就会了

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

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 好打了。