原文地址：http://blog.csdn.net/ariesjzj/article/details/7747876
Git和SVN，CVS一样，是一种源代码管理系统。和后两者不同的是，它不仅可以集中式管理，也可以以分布式的形式工作，即所有操作都在本地，速度快，且本地提交不会影响共享的代码仓库。Git功能很多，本文列了一些常见用法。
配置和创建代码仓库
设置提交时的编辑器（默认是nano）：
$ export GIT_EDITOR=vim
或者
$ git config --global core.editor vim
设置文件比较工具：
$ git config --global merge.tool vimdiff
配置个人信息，即提交时显示的作者信息，如：
$ git config user.name "jzj"
$ git config user.email "jzj@domain"
创建一个新Git仓库：
$ git init
查询信息(inquiry)
这部分和SVN中对应命令很像
查看配置信息：
$ git config --list
查看仓库的状态信息：
$ git status
查看两个版本的差异
$ git diff
由于Git中引入了index的概念，因此和svn相比，git diff可分为加--cached和不加两种：
$ git diff # 显示本地改动但没有stage的改动
$ git diff --cached # 显示已经stage过的本地改动，也就是如果执行git commit会提交的改动
$ git diff master..test # 两个branch间的差别
$ git diff --stat # 显示统计信息
历史信息
$ git log
$ git log -p # 显示patch
$ git log --stat # 行数统计
$ git log --topo-order --graph # 用简单图形显示commit间的拓扑关系
$ git log -n # 仅列出前n个
$ git show-branch --more=n # 前n个提交历史信息
另外，对工作目录中文件操作有git ls-files，git grep等命令。
提交(commit)
和SVN不同的是，Git中的Checkin分两步，即stage和commit。如：
$ git add a.c # stage改动，更改index（index是一个临时动态文件，描述了整个工程目录，并记录了作了哪些改动）。stage过的改动会在git diff --cached中显示出来。
$ git commit -m "comments" # 提交改动
加-a参数可以将前面两步合二为一：
$ git commit -a
但它仅限于tracked的文件。比如新建一个文件但没有git add过，它还是untracked状态，那加-a也没用。
补丁(patch)
生成补丁
$ git format-patch -n master # 生成最近n次commit的patch
$ git format-patch master~4..master~2 # 生成master~4和master~2之间差异的patch
$ git format-patch -s <sha> # 生成指定commit的patch，加签名
应用补丁
git am 用了git apply，用它打补丁会生成commit信息。
前面方法用于已经commit的更改，如果是用git diff生成的本地修改的patch，则可以用下面方法：
生成本地修改的patch：
$ git diff | tee diff.patch
应用patch时用：
$ git apply --ignore-space-change --ignore-whitespace diff.patch
当然这更像Svn中的习惯，在git里反正是本地提交，提交的成本很低，所以可以先提交再生成patch。
branch之间打patch用：
$ git cherry-pick
撤消(undo)
和撤消相关的有三个命令：git checkout, git revert和git reset。
如取消本地没有stage过的改动（即没有通过git add等命令记录到index中的改动）：
$ git checkout . # index不变，工作目录改变
再如
$ git checkout HEAD^ # 返档到前一次commit的版本
$ git checkout <sha> # 返档到指定commit版本
git reset 不仅作用于工作目录，而且作用于index文件。git reset有三种方式，分别为soft, hard和mixed方式。
$ git reset --soft <sha> # 既不影响index也不影响工作目录，也就是说用git diff --cached还是可以看到撤消的改动
$ git reset --mixed <sha> # index改变，但工作目录不变
$ git reset --hard <sha>，# 将index和工作目录都恢复到指定版本。相当于svn revert -R *
撤消后，git log无法看到撤消的commit历史，但可以用下面命令看到：
$ git reflog
git checkout和git reset --hard的区别在于：
git checkout . # 清除本地更改，但不清除index。举例来说，之前git add但没commit的作用还在。
git reset --hard HEAD # 清除本地更改，包括index。所以git add过的也清除了。
git revert 进行一次与指定版本相反的commit。如：
$ git revert <sha> # commit一次和<sha>指定commit相反的改动
$ git revert -n <sha> # 和前一命令一样，但不提交
git revert可以把中间的commit作用消除，且git revert不会改变已有的历史记录。当项目是基于已有Git仓库时这很有用。
如果只是想修改commit时的提交信息，可以用：
$ git commit --amend
分支(branch)
新建
$ git branch new_branch
或
$ git checkout -b new_branch
查看
$ git show-branch
提取
$ git checkout new_branch
删除
$ git branch -d new_branch
归并其它分支
$ git merge branchname
杂项：
某些文件不需要让Git去track，可以在.gitignore中设置忽略这些文件。
指定特定文件用--，如：
$ git checkout -- dir/main.c
Git有几个内置的符号索引指针：
HEAD：永远指向当前分支的最近一次commit
ORIG_HEAD：git reset或git merge后，原来的HEAD被存在这里
FETCH_HEAD：git fetch后所有分支的头索引指针
MERGE_HEAD：git merge时另一分支的头索引指针
相对索引：HEAD^ HEAD^^ HEAD~2 HEAD@{2}等
如果手头的工作做了一半，但有一个小的但紧急的bug要fix，可以用git stash。它像一个栈一样将当前的工作上下文push到栈中，当bug fix完了再pop出来。
$ git stash "current work"
$ gt commit -a -m "trivial bug fix"
$ git stash apply
gitk：图形化的git diff
当碰到regression时，可以用git bisect和git blame。前者用来查找问题从哪个版本开始出现，后者列出每行代码的修改者和时间。
分布式管理
复制代码仓库
$ git clone /tmp/repo repo # 在当前目录下创建/tmp/repo的代码仓库拷贝
向远程代码仓库提交
$ git push /tmp/repo master # 将本地master分支中的改动提交到/tmp/repo中
从远程代码仓库同步
$ git pull /tmp/repo master # 将/tmp/repo中的改动同步到本地的master分支中
该命令相当于git fetch 加 git merge
一些相关资料：
给SVN用户的Git教程 http://git.or.cz/course/svn.html
Repo和Git http://source.android.com/source/version-control.html
活灵活现用Git-技巧篇 http://phoenixtoday.blogbus.com/logs/35149540.html
《Version Control with Git》
《Git Community Book》
效果图：
（旋转效果）
1.首先去网站http://lab.smashup.it/flip/下载插件
2.引入到网页
3.引入jquery的文件
4.在页面载入的时候调用函数
html页面：
完毕.
如果修改代码：
则反转后的内容中会出现文字
一、目标靠谱
按理论来讲，那就是一个项目要在几要素之间平衡。说白了，就是有多少时间，有多少资源，干多少事。这个道理很简单，能做到的真不多。
互联网移动客户端项目不要看一年，做好半年的目标和三个月的计划就可以了。当行业对速度的追求导致研发、产品、UI时刻都处在迭代状态时，长时间的规划一定会带来无数蛋疼的问题。听听大牛张小龙的名言吧：满足基本功能，然后根据用户反馈快速迭代才是王道。杜绝关上门制造用户需求。
二、资源靠谱
需要注意手里有多少干货：
你的那帮兄弟，他们无意给你惹事，但一部分人对流程和业务的陌生绝对是项目中的炸弹。这在人才快速流动的移动开发领域很常见。
你的老大好哪口？给你划结构，还是给你讲需求？更或者是撒手不管？不管怎么样，把他脑子里的东西掏出来，然后把你脑子里的东西告诉他，这对你们俩都很重要。
产品部是不是把个应届生塞给你了？UI新来的小女孩儿原来做IOS的吧？一个刚入行的测试会给你抛一些让你HI到死的BUG。你对服务器的接口了解么？这些问题每一个都能让你叫天天不应，防患于未然吧。
三、执行靠谱
任何人都是想负责任的，但任何人都不愿意为错误埋单。因此，需要通过制定计划，完善流程来帮助大家成为圣人。
1、把你的开发文档、产品文档、UI效果图做的细细的，这会费时间，但会避免让你在项目后期到处救火。
2、告诉大家把遇到的每个问题都记录下来，题材不限。工具没注释，产品的小辫子，UI的按钮要都变成发光的，等等。就算没有对眼前的问题有显示的好处，但绝对会让下一次的执行过程更顺畅。
3、大家都按计划，谁要变东西，可以，跟他约时间。不要答应那些“回头怎么样”、“我会怎么样”、“稍后怎么样”的事情。
4、任何东西都是有缺陷的，不要做完美的东西，要做稳定靠谱、符合原计划的东西。
四、细节靠谱
移动产品的开发，需要应对各种屏幕上，要想做到大家好才是真的好，确实挺难的。下面抛砖引玉，提这么几点：
1、如果想适配所有屏幕尺寸，那得覆盖满足下面这些要求的机子：3.x寸、4.x寸、5寸（default）、7寸(large)、8寸(x-large)、10寸(x-large);1.0、1.5、2.0这几种密度。
2、为了保证用户体验，GUI设计至少要做手机和10寸Pad两套方案。
2、2.2、2.3、3.0、3.2、4.0，这几个有重大更新的Android版本的机器都得有。Android每一次大的版本迭代都会带来一些API变化，以Android的更新速度，我们不可能了解每一个坑（尤其是使用了隐藏API的时候）。所以，尽量多测吧。
3、特殊机型是永远的痛。P1000的超大号字体设置，国产机800*600的分辨率，以及莫名其妙的字体变大等五光十色的特殊机型问题会时不时来骚扰。如果只是对特定机器做定制，那么恭喜了，否则的话，建议从这些方面下手试试：
(1)市场上总有那么几款街机很经典很蛋疼，一定要申请购买。
(2)国产机中每个大厂的搞上一个，只要一个就够了，他就算出一百个型号，也就那几个人几杆枪，改改Framework然后交给代工厂。
(3)Kindle Fire、乐Pad这种Framework被改的面目全非的明星机器不要忘了。
(4)国际几大厂商的机器要保证至少各有一台，他们软硬件一条龙，天知道他们对Framework层动了什么东西。
4、边边角角，总能发现很多不尽人意的地方被研发、产品和UI漏掉，把它们留给测试很蛋疼，最后让用户挑出来更蛋疼。需要让团队的每个人形成注重细节的意识，但更需要有人对这东西负责。
5、每一个界面的设计拍板之前，你至少得考虑一下在10寸大平板和小手机上是不是都行的通，不行就搞两套。不要寄希望UI和产品可以把每个东西都考虑到，研发的适配经验才是最有发言权的。
6、对那很细但很重要的体验，不要抱着“我应该可以做”的想法，抬起手写个Demo，放在几台经典的机器上面跑一下。
五、技术靠谱
项目中用到的任何新技术，一定要完全达到商用标准之后再应用到项目中。关于商用标准，我以自己的经历总结了这么几点：
1、应用效果达到预期。衡量软件模块的速度、内存、CPU等是否都满足预期？如果是GUI相关的话，效果和体验是否达到预期？
2、对其它模块的影响可控。上了这个东西，会不会牵连其它模块？
3、模拟环境与真实环境一致。不要拿起一个测试Demo，一看效果不错，就拍板。一定要真实的应用环境来检测。项目没有足够的时间或资源单独模拟真实环境的话，那就把它放在第一个里程碑中去。
4、备选方案。多个方案备用，周知大家。往最好的地方奔，但是，做最坏的打算。
5、技术上再帅的东西，转化不成生产力也是白搭。成功的项目不需要技术崇拜。