前言：今天刚刚把开发环境配好，真是兴奋，打开Git——clone 修改了代码 pull push 好像文件没有更新成功，页面没有变化，囧了，然后我就不停在那边Pull来Pull去，Push来Push去，结果还是没有解决问题。终于我发现使用Git管理图片和代码真的是完全不一样，管理图片会3个就行了，Clone\Pull\Push，但是代码好像没那么简单。
在园子里找了一些资料，整理下。
Git的缺点：漏洞百出的抽象
Git 包含太多不是抽象的抽象，在定义用户接口和实现上经常没有任何区别，这是可以理解的，对一个高级用户来说他需要了解一些功能的具体实现，以掌握各个命令的 微妙之处。但大量的内部细节对初学者来说简直是噩梦。有这么一个说法，关于水暖器材和瓷器，但你必须成为一个水暖工才能知道器材如何安装在瓷器上。
很多人对我的抱怨予以回应说：你无需使用所有的命令，你可以向 Subversion 一样来使用 Git。这是狡辩，就好比是告诉一个老奶奶说高速公路并不可怕，她可以在高速路上靠左边的快车道上以时速 20 公里爬行，一样的道理。Git 并没有提供任何有用的子集，每个命令都会连带着对其他命令的要求，很简单的动作经常需要很复杂的动作来撤销或者改进。
下面是一个 GitHub 项目维护者的一些善意的建议：
1. 在分支和 master 上寻找合并的基准: ‘git merge-base master yourbranch’
2. 假设你已经提交了更改记录，从对你的提交重新基准化到合并准，然后创建一个新分支
3. git rebase –onto <basecommit> HEAD~1 HEAD
4. git checkout -b my-new-branch
5. 检出你的 ruggedisation 分支，然后移除提交: ‘git reset –hard HEAD~1′
6. 合并新的分支到 ruggedisation: ‘git merge my-new-branch’
7. 检出 master (‘git checkout master’)， 合并新分支 (‘git merge my-new-branch’)， 然后检查合并后的情况，接着移除合并 (‘git reset –hard HEAD~1′).
8. 提交新的分支 (‘git push origin my-new-branch’) 并记录 pull 请求
翻译：“奶奶，在高速公路上开车很容易的。松开离合器，让转速超过 6000 转使车轮打滑，然后进入第一个弯道并上高速公路，看路牌到出口前，使用手刹飘逸转向出口。
Git的缺点：简单任务也要诸多命令
如果你在开发一个开源项目，你做了一些改变，然后想与其他人分享，你只需要：
1. 修改代码
2. 执行 svn commit
如果你增加了一些新文件：
1. 添加文件
2. svn add
3. svn commit
如果你的项目托管在 Github 类的网站中，那么你需要：
1. Make some changes
2. git add [not to be confused with svn add]
3. git commit
4. git push
5. 到此为止，你的更改只完成了一半，接下来你需要登录到 Github，查找你的提交，然后发布一个 “pull request” ，这样其他人才可以获取你的改动
在现实中，Github 的维护者希望你的改动是功能方面的分支，他们会要求你这样操作：
1. git checkout master [to make sure each new feature starts from the baseline]
2. git checkout -b newfeature
3. Make some changes
4. git add [not to be confused with svn add]
5. git commit
6. git push
7. 然后登录到 Github，切换到你的新特性分支，发布 “pull request”
为了将你的更改从你的本地目录中移到实际的项目资源库，你需要：add, commit, push, “click pull request”， pull, merge, push.
下面是一个流程图向你展示一个典型的开发者在 Subversion 上要做的工作：
“Bread and butter” 是与远程 SVN 资料库操作的命令和概念。
然后我们再来看看如果你的项目托管在 Github 上会是怎样的：
如果 Git 的强大之处是分支和合并，那么它的弱点就是让简单的任务变得非常复杂。
翻译版：我痛恨Git 的 10 个理由 英文版： 10 things I hate about Git）
其他分享资料
