1.建一个叫test的文件夹:
$ mkdir test
2.如果在文件夹里添加（就是创建）一个文件 例如a.txt
$ touch test/a.txt
3.删除test文件夹:
$ rm -rf test/
4.将java文件(夹)加入到.gitignore文件中:
$ Add .gtiignore:java
5.查看hello文件和example文件中的内容：
$ cat hello example
6.创建文件:
$ echo "Hello world" > hello
7.编辑文件:
$ echo "It's a new day for git" >> hello
8.添加hello文件到版本库文件索引当中:
$ git add hello
(hello文件此前并没有提交到 git 的内容跟踪范畴之内)
9.去除索引:
$ git rm -cached hello
10.查看当前的工作变化情况(没有则不显示)：
$ git diff
11.将某个目录下(必须是仓库内)的所有内容全都纳入内容跟踪之下:
$ git add e:/git_1/oldproject
or
$ git add .
12.查看hello文件内容：
$ cat hello
13.退出当前编辑状态:
$ esc + :wq
#######################################################################
1.程序员Bob将仓库munger项目拷贝到当前目录下的myrepo(不存在则自动新建)文件夹下：
$ git clone e:/munger myrepo
这样就创建了一个保存着程序员Alice 的版本库的镜像的新目录 "myrepo"，这个镜像保存着原始项
目的起点和它的发展历程。
2.接着 Bob 对项目做了些更改并提交了这些更改(编辑一些文件),然后提交：
$ git-commit -a
(如果需要的话再重复这个步骤)
3.当他搞定之后，他告诉Alice将他的东西从 e:/myrepo 中引入，Alice只需要这样：
$ cd e:/project
$ git pull e:/myrepo
这样就将 Bob 的版本库中的 "master" 分支的变化引入了。Alice 也可以通过在pull命令的后面加
入参数的方式来引入其他的分支:
$ git pull e:/myrepo [branch name]
4. 在导入了 Bob 的工作之后，用 "git whatchanged" 命令可以查看有什么新的提交对象。
如果这段时间里以来，Alice也对项目做过自己的修改，当Bob的修改被合并进来的时候，那么她需要手动修复所有的合并冲突。
5.谨慎的 Alice 在导入 Bob 的工作之前，希望先检查一下。那么她可以先将 Bob 的工作导入到一
个新创建的临时分支中，以方便研究 Bob 的工作：
$ git fetch e:/myrepo master:bob-incoming
这个命令将Bob的master分支的导入到名为bob-incoming的分支中(不同于git pull命令，git fetch 命令只是取得Bob的开发工作的拷贝,而不是合并进来)
6.接着：
$ git whatchanged -p master bob-incoming
这会列出Bob自取得Alice的master分支之后开始工作的所有变化。检查过这些工作，并做过必须的调整之后,Alice就可以将变化导入到她的master分支中：
$git checkout master
$git pull . bob-incoming
最后的命令就是将bob-incoming分支的东西导入到Alice自己的版本库中，稍后Bob就可以通过下面的
命令同步 Alice 的最新变化:
$ git pull
注意:不需为这个命令加入Alice的版本库的路径，因为当Bob克隆Alice的版本库的时候，git已经将
这个路径保存到.git/remote/origin 文件中，它将会是所有的导入操作的默认路径。
7.Bob可能已经注意到他并没有在他的版本库中创建过分支(但是分支已经存在了)：
$ git branch
* master
origin
origin分支是运行 "git-clone" 的时候自动创建的，他是Alice的master分支的原始镜像，Bob应
该永远不要向这个分支提交任何东西。
8.如果Bob以后决定在另外一部主机上开展工作，那么他仍然需要通过SSH协议重新克隆和导入(Alice
的版本库)：
$ git-clone alice.org:/home/alice/project/ myrepo
我们可以使用git自然协议，或者是rsync,http等协议的任何一种，详情请参考git-pull。
Git同样可以建立类似CVS那样的开发模式，也就是所有开发者都向中心版本库提交工作的方式，详情
参考git_push和git for CVS users 。
#########################################################
为版本库打包:
1. 在前面，我们已经看到在.git/objects/??/目录中保存着我们创建的每一个git对象。这样的方式对于自动和安全地创建对象很有效，但是对于网络传输则不方便。git对象一旦创建了，就不能被改变，但有一个方法可以优化对象的存储，就是将他们"打包到一起":
$ git repack
2.上面的命令让你做到这点，如果你一直是做着我们的例子过来的，你现在大约会在.git/objects/??/目录下积累了17个对象。git-repack会告诉你有几个对象被打包了，并且将他们保存在.git/objects/pack目录当中。你将会看到两个文件:pack-*.pack and pack-*.idx.在.git/objects/pack 目录中,他们的关系是很密切的，如果你手动将他们拷贝到别的版本库中的话你要决定将他们一起拷贝。前者
是保存着所有被打包的数据的文件，后者是随机访问的索引。如果你是个偏执狂，就运行一下 git-
verity-pack 命令来检查一下有缺陷的包吧，不过，其实你无须太多担心，我们的程序非常出色~~~
2.一旦你已经对那些对象打包了，那么那些已经被打过包的原始的对象，就没有必要保留了:
$ git prune-packed
会帮你清除他们。
3.如果你好奇的话，你可以在执行git-prune-repacked命令之前和之后，都运行一下:
$ find .git/objects -type f，
这样你就能看到有多少没有打包的对象，以及节省了多少磁盘空间。
对于 HTTP 传输来说，一个打包过的版本库会将一定数量的相关联的对象放进一个有关联性的打包中。如果你设想多次从HTTP公共版本库中导入数据，你也许要频繁地 reapck & prune，要么就干脆从不这样做。如果你此时再次运行 git-repack，它就会说 "Nothing to pack"。
要是你继续开发，并且积累了一定数量的变迁，再运行git-repack 将会创建一个新的包，它会包含你自上次对库打包以来创建的对象。我们建议你尽快在初始化提交之后打包一下你的版本库(除非你现在的项目是个涂鸦式的草稿项目)，并且在项目经历过一段很活跃的时期时，再运行git-repack一下。
当一个版本库通过git-push和git-pull命令来同步源版本库中打包过的对像的时候，通常保存到目标版本库中的是解包了的对象，除非你使用的是 rsync(远程同步协议)协议的传输方式。正是这种容许你在两头的版本库中有不同的打包策略的方式，他意味着你也许在过一段时间之后，需要在两头的版本库中都重新打包一下。
