查看文件状态: git status
在git-study中:
这表明没有什么需要修改. 这个命令非常常用
将文件纳入到版本控制中: git add
假设当前目录下有个aa目录, 还有bb.txt, cc.txt 文件, 如果想将aa目录下的所有文件, bb.txt纳入到版本控制中, 使用命令:
git add aa bb.txt cc.txt
另外, git add 这个命令既可以将新建的文件纳入到版本控制中, 也可以将已修改的文件加入到暂存区.
比如我修改了 README.md 文件:
使用vim编辑器修改文件
vim README.md
修改完之后, 将其加入到暂存区
git add README.md
此时再使用 git status命令查看文件状态:
Git会提示你, 使用什么命令对文件做什么操作, 比如使用 git add 将修改的文件加入到缓存区, 或者使用 git checkout -- file 把这些修改废弃掉.
建议使用 git add 的时候, 后面的文件一个一个的写, 最好不要写文件夹的名字, 否则很有可能把不需要暂存的文件加入到暂存区
忽略某些文件: .gitignore
一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。来看一个实际的例子：
# built application files
*.apk
*.ap_
# files for the dex VM
*.dex
# Java class files
*.class
# generated files
bin/
gen/
# Local configuration file (sdk path, etc)
local.properties
# Eclipse project files
.classpath
.project
# Proguard folder generated by Eclipse
proguard/
# Intellij project files
*.iml
*.ipr
*.iws
.idea/
这是git@osc中新建 Android 项目时自动生成的 .gitignore 文件.
查看文件的改变情况: git diff
加入现在一个文件修改后暂存, 另一个修改后没有暂存, 使用git status查看:
要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容。
如果只想看某个文件的改动情况, 使用 git diff filename 即可
若要看已经暂存起来的文件和上次提交时的快照之间的差异，可以用 git diff --cached filename命令。（Git 1.6.1 及更高版本还允许使用 git diff --staged，效果是相同的，但更好记些。）来看看实际的效果：
请注意，单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。
提交更新: git commit
现在的暂存区域已经准备妥当可以提交了。在此之前，请一定要确认还有什么修改过的或新建的文件还没有 git add 过，否则提交的时候不会记录这些还没暂存起来的变化。所以，每次准备提交前，先用 git status 看下，是不是都已暂存起来了，然后再运行提交命令 git commit. 这种方式会启动文本编辑器以便输入本次提交的说明。
可以看到，默认的提交消息包含最后一次运行 git status 的输出，放在注释行里，另外开头还有一空行，供你输入提交说明。你完全可以去掉这些注释行，不过留着也没关系，多少能帮你回想起这次更新的内容有哪些。（如果觉得这还不够，可以用 -v 选项将修改差异的每一行都包含到注释中来。）退出编辑器时，Git 会丢掉注释行，将说明内容和本次更新提交到仓库。
注意, 如果不写提交说明的话, 是无法完成提交的. 另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新：
可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添改和删改过。
提交时记录的是放在暂存区域的快照，任何还未暂存的仍然保持已修改状态，可以在下次提交时纳入版本管理。每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。
需要注意的是, 如果你不写提交信息, Git是不允许你提交的. 如果你想使用一个提交命令就搞定提交和输入提交信息, 可以使用: git commit -m ‘initial commit‘
引号中的文字表示提交信息, 但是这种做法是不推荐的, 我们希望提交信息尽可能详细.
移除文件: git rm
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是未暂存清单）看到：
这就是我将 test.txt删掉之后运行git status 的输出, 然后再运行 git rm 记录此次移除文件的操作：
最后提交的时候，该文件就不再纳入版本管理了。如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。
另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆 .a 编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 --cached 选项即可:
git rm --cached readme.txt
移动文件: git mv
不像其他的 VCS 系统，Git 并不跟踪文件移动操作。如果在 Git 中重命名了某个文件，仓库中存储的元数据并不会体现出这是一次改名操作。不过 Git 非常聪明，它会推断出究竟发生了什么，至于具体是如何做到的，我们稍后再谈。
既然如此，当你看到 Git 的 mv 命令时一定会困惑不已。要在 Git 中对文件改名，可以这么做：
git mv file_from file_to, 比如下面这个例子:
查看提交历史: git log
在提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史，可以使用 git log 命令查看。
默认不用任何参数的话，git log 会按提交时间列出所有的更新，最近的更新排在最上面。每次更新都有一个 SHA-1 校验和、作者的名字和电子邮件地址、提交时间，最后缩进一个段落显示提交说明。
git log 有许多选项可以帮助你搜寻感兴趣的提交，接下来我们介绍些最常用的。
我们常用 -p 选项展开显示每次提交的内容差异，用 -2 则仅显示最近的两次更新：
在做代码审查，或者要快速浏览其他协作者提交的更新都作了哪些改动时，就可以用这个选项。
如果提交次数比较多的话, 一个屏幕放不下, 可以使用 j, k 上下移动查看, 输入大写的ZZ可以退出.
修改提交: git commit --amend
有时候我们提交完了才发现漏掉了几个文件没有加，或者提交信息写错了。想要撤消刚才的提交操作，可以使用 --amend 选项重新提交：
此命令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，但将要提交的文件快照和之前的一样。
启动文本编辑器后，会看到上次提交时的说明，编辑它确认没问题后保存退出，就会使用新的提交说明覆盖刚才失误的提交。
如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 --amend 提交, 比如下面这些操作：
git commit -m ‘initial commit‘
上面的三条命令最终只是产生一个提交，第二个提交命令修正了第一个的提交内容。
比如下面的操作, 首先我提交了一次:
然后我修改了某个文件, 并且添加到暂存区中:
然后再 git commit --amend
服务器上只有一次提交信息.
取消已经暂存的文件: git reset
有两个修改过的文件，我们想要分开提交，但不小心用 git add . 全加到了暂存区域。该如何撤消暂存其中的一个文件呢？其实，git status 的命令输出已经告诉了我们该怎么做：
git reset HEAD a.txt
这条命令运行后, a.txt 又回到了之前已修改未暂存的状态.
取消对文件的修改: git checkout --
如果觉得刚才对 benchmarks.rb 的修改完全没有必要，该如何取消修改，回到之前的状态（也就是修改之前的版本）呢？git status 同样提示了具体的撤消方法，接着上面的例子，现在未暂存区域看起来像这样：
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: benchmarks.rb
#
在第二个括号中，我们看到了抛弃文件修改的命令
可以看到，该文件已经恢复到修改前的版本。你可能已经意识到了，这条命令有些危险，所有对文件的修改都没有了，因为我们刚刚把之前版本的文件复制过来重写了此文件。所以在用这条命令前，请务必确定真的不再需要保留刚才的修改
任何已经提交到 Git 的都可以被恢复。即便在已经删除的分支中的提交，或者用 --amend 重新改写的提交，都可以被恢复（关于数据恢复的内容见第九章）。所以，你可能失去的数据，仅限于没有提交过的，对 Git 来说它们就像从未存在过一样。
远程仓库
查看当前远程库:
git remote
加上参数 -v, 显示对应克隆地址:
git remote -v
从远程库抓取数据: git fetch/git pull
此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。（我们会在第三章详细讨论关于分支的概念和操作。）
单纯的 fetch 之后, 本地的文件并不会变化, 有一点很重要，需要记住，fetch 命令只是将远端的数据拉到本地仓库，并不自动合并到当前工作分支，只有当你确实准备好了，才能手工合并(使用 git merge命令)。
如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。所以，git fetch origin 会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新（或是上次 fetch 以来别人提交的更新）。
如果设置了某个分支用于跟踪某个远端仓库的分支（参见下节及第三章的内容），可以使用 git pull 命令自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用，既快且好。实际上，默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支（假设远程仓库确实有 master 分支）。所以一般我们运行 git pull，目的都是要从原始克隆的远端仓库中抓取数据后，合并到工作目录中的当前分支。
推送数据到远程仓库: git push
git push [remote-name] [branch-name]。如果要把本地的 master 分支推送到 origin 服务器上（再次说明下，克隆操作会自动使用默认的 master 和 origin 名字），可以运行下面的命令：
只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。有关推送数据到远程仓库的详细内容见下一篇。
查看远程仓库信息: git remote show
我们可以通过命令 git remote show [remote-name] 查看某个远程仓库的详细信息，比如要看所克隆的 origin 仓库，可以运行：
