经过一下午的git学习，感觉受益匪浅，不扯淡了，直接进入主题吧，以下是小二对git的一些见解。
首先取得项目的git仓库
有两种取得 Git 项目仓库的方法。第一种是在现存的目录下，通过导入所有文件来创建新的 Git仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来（一般来说克隆用得比较普遍）。
第一种：要对现有的某个项目开始用Git 管理，只需到此项目所在的目录，执行：
$ git init
第二种：
克隆仓库的命令格式为git clone [url]。比如，要克隆 Ruby 语言的 Git 代码仓库Grit，可以用下面的命令：
$ git clone
git://github.com/schacon/grit.git如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：
$ git clone git://github.com/schacon/grit.gitmygrit
现在已经有了本例仓库，以下是一些常用的操作：
检查当前文件状态
要确定哪些文件当前处于什么状态，可以用git status命令。如果在克隆仓库之后立即执行此命令，会看到类似这样的输出：
$ git status
On branch masternothing to commit, working directory clean
现在让我们用 vim 创建一个新文件 README，保存退出后运行git status会看到该文件出现在未跟踪文件列表中：
$ vim README
$ git status
On branch master Untracked files: (use "git add ..." to include inwhat will be committed) README nothing added to commit butuntracked files present (use "git add" to track)
在状态报告中可以看到新建的README文件出现在“Untrackedfiles”下面。未跟踪的文件意味着Git在之前的快照（提交）中没有这些文件；Git不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”，因而不用担心把临时文件什么的也归入版本管理。不过现在的例子中，我们确实想要跟踪管理 README 这个文件。
跟踪新文件
使用命令git add开始跟踪一个新文件。所以，要跟踪 README 文件，运行：
$ git add README
此时再运行git status命令，会看到 README 文件已被跟踪，并处于暂存状态：
$ git status
On branch master Changes to be committed: (use "git reset HEAD ..."to unstage) new file: README
只要在 “Changes to be committed”这行下面的，就说明是已暂存状态。如果此时提交，那么该文件此时此刻的版本将被留存在历史记录中。你可能会想起之前我们使用git init后就运行了git add命令，开始跟踪当前目录下的文件。在git add后面可以指明要跟踪的文件或目录路径。如果是目录的话，就说明要递归跟踪该目录下的所有文件。（译注：其实git
add的潜台词就是把目标文件快照放入暂存区域，也就是 add file into stagedarea，同时未曾跟踪过的文件标记为需要跟踪。这样就好理解后续 add 操作的实际意义了。）
忽略某些文件
一般我们总会有些文件无需纳入 Git的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。我们可以创建一个名为.gitignore的文件，列出要忽略的文件模式。来看一个实际的例子：
$ cat .gitignore *.[oa] *~
第一行告诉 Git 忽略所有以.o或.a结尾的文件。一般这类对象文件和存档文件都是编译过程中出现的，我们用不着跟踪它们的版本。第二行告诉 Git忽略所有以波浪符（~）结尾的文件，许多文本编辑软件（比如Emacs）都用这样的文件名保存副本。此外，你可能还需要忽略log，tmp或者pid目录，以及自动生成的文档等等。要养成一开始就设置好.gitignore文件的习惯，以免将来误提交这类无用的文件。
文件.gitignore的格式规范如下：
所有空行或者以注释符号＃开头的行都会被 Git 忽略。
可以使用标准的 glob 模式匹配。
匹配模式最后跟反斜杠（/）说明要忽略的是目录。
要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。
所谓的 glob 模式是指 shell所使用的简化了的正则表达式。星号（*）匹配零个或多个任意字符；[abc]匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如[0-9]表示匹配所有 0 到 9 的数字）。
我们再看一个.gitignore文件的例子：
# 此为注释 – 将被 Git 忽略
# 忽略所有 .a 结尾的文件*.a
# 但 lib.a 除外!lib.a# 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO/TODO
# 忽略 build/ 目录下的所有文件build/
# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txtdoc*.txt
查看已暂存和未暂存的更新
实际上git status的显示比较简单，仅仅是列出了修改过的文件，如果要查看具体修改了什么地方，可以用git diff命令。稍后我们会详细介绍git diff，不过现在，它已经能回答我们的两个问题了：当前做的哪些更新还没有暂存？有哪些更新已经暂存起来准备好了下次提交？git diff会使用文件补丁的格式显示具体添加和删除的行。
假如再次修改README文件后暂存，然后编辑benchmarks.rb文件后先别暂存，运行status命令将会看到：
$ git status
要查看尚未暂存的文件更新了哪些部分，不加参数直接输入git diff：
$ git diff
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容。
若要看已经暂存起来的文件和上次提交时的快照之间的差异，可以用git diff --cached命令。（Git 1.6.1 及更高版本还允许使用git diff --staged，效果是相同的，但更好记些。）
提交更新
现在的暂存区域已经准备妥当可以提交了。在此之前，请一定要确认还有什么修改过的或新建的文件还没有git add过，否则提交的时候不会记录这些还没暂存起来的变化。所以，每次准备提交前，先用git status看下，是不是都已暂存起来了，然后再运行提交命令git commit：
$ git commit -m "Story 182: Fix benchmarks for speed"
这种方式会启动文本编辑器以便输入本次提交的说明。（默认会启用 shell 的环境变量$EDITOR所指定的软件，一般都是 vim 或 emacs。当然也可以按照第一章介绍的方式，使用git config --global core.editor命令设定你喜欢的编辑软件。）
跳过使用暂存区域
尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git提供了一个跳过使用暂存区域的方式，只要在提交的时候，给git commit加上-a选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add步骤：
$ git commit -a -m 'added new benchmarks'
从远程仓库抓取数据
正如之前所看到的，可以用下面的命令从远程仓库抓取数据到本地：
$ git fetch [remote-name]
此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。
如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，git fetch origin会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch以来别人提交的更新）。有一点很重要，需要记住，fetch命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并。
如果设置了某个分支用于跟踪某个远端仓库的分支，可以使用git pull命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下git clone命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master分支（假设远程仓库确实有 master 分支）。所以一般我们运行git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中的当前分支。
推送数据到远程仓库
项目进行到一个阶段，要同别人分享目前的成果，可以将本地仓库中的数据推送到远程仓库。实现这个任务的命令很简单：git push [remote-name] [branch-name]。如果要把本地的 master 分支推送到origin服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin名字），可以运行下面的命令：
$ git push origin master
分支的命令
那么，Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如新建一个 testing 分支，可以使用git branch命令：
$ git branch testing
要切换到其他分支，可以执行git checkout命令。我们现在转换到新建的 testing分支：
$ git checkout testing
分支的新建与合并
现在，你决定要修补问题追踪系统上的 #53 问题。顺带说明下，Git并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行git checkout并加上-b参数：
$ git checkout -b iss53
Switched to a new branch 'iss53'
这相当于执行下面这两条命令：
$ git branch iss53 $ git checkout iss53
有必要作些测试，确保修补是成功的，然后回到master分支并把它合并进来，然后发布到生产服务器。用git merge命令来进行合并：
$ git checkout master
$ git mergeiss53
在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前hotfix分支和master都指向相同的提交对象，所以hotfix已经完成了历史使命，可以删掉了。使用git branch的-d选项执行删除操作：
$ git branch -diss53
遇到冲突时的分支合并
有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）。如果你在解决问题 #53 的过程中修改了hotfix中修改的部分，将得到类似下面的结果：
$ git merge iss53
Auto-merging index.htmlCONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：
<<<<<<< HEAD
contact : email.support@github.com
=======
please contact us at support@github.com
>>>>>>> iss53
可以看到=======隔开的上半部分，是HEAD（即master分支，在运行merge命令时所切换到的分支）中的内容，下半部分是在iss53分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
please contact us at
email.support@github.com
解决冲突过后不需要重新合并，只需要add把解决后的文件放在暂存中，然后commit就可以。
PS： 希望这些有所帮助，有什么问题欢迎留言。
