Git-Repo-Gerrit-2-Git基础

Git工作目录下的文件状态

工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新，已修改或者已放入暂存区。而所有其他文件都属于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区域。初次克隆某个仓库时，工作目录中的所有文件都属于已跟踪文件，且状态为未修改。

 

在编辑过某些文件之后，Git 将这些文件标为已修改。我们逐步把这些修改过的文件放到暂存区域，直到最后一次性提交所有这些暂存起来的文件，如此重复。所以使用 Git 时的文件状态变化周期如图 2-1 所示:

 

 

下面关于git的操作我会以git@osc为例.

克隆仓库: git clone

我在开源中国上新建了个项目, 使用如下命令将仓库克隆到本地(进入到e:/gyrepo/目录下)

git clone http://git.oschina.net/gaoyuan/git-study.git

之后就可以看到该目录中自动新建了个 git-study 目录, 里面有几个文件, 其中 .git 文件夹 就是记录整个仓库的文件夹

 

查看文件状态:  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 选项重新提交：

git commit --amend

此命令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动，直接运行此命令的话，相当于有机会重新编辑提交说明，但将要提交的文件快照和之前的一样。

启动文本编辑器后，会看到上次提交时的说明，编辑它确认没问题后保存退出，就会使用新的提交说明覆盖刚才失误的提交。

 

如果刚才提交时忘了暂存某些修改，可以先补上暂存操作，然后再运行 --amend 提交, 比如下面这些操作：

git commit -m 'initial commit'

git add forgotten_file

git commit --amend

上面的三条命令最终只是产生一个提交，第二个提交命令修正了第一个的提交内容。

比如下面的操作, 首先我提交了一次:

 

然后我修改了某个文件, 并且添加到暂存区中:

  

  

然后再 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

可以用下面的命令从远程仓库抓取数据到本地：

git fetch [remote-name]

此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后，你就可以在本地访问该远程仓库中的所有分支，将其中某个分支合并到本地，或者只是取出某个分支，一探究竟。（我们会在第三章详细讨论关于分支的概念和操作。）

单纯的 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 push origin master

只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送。有关推送数据到远程仓库的详细内容见下一篇。

 

查看远程仓库信息: git remote show

我们可以通过命令 git remote show [remote-name] 查看某个远程仓库的详细信息，比如要看所克隆的 origin 仓库，可以运行：

git remote show origin

 

打标签(Tag)

Git 可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做。

关于这部分内容, 由于我们公司不常用, 我这里不再记录, 有兴趣的可以看: http://git.oschina.net/progit/2-Git-%E5%9F%BA%E7%A1%80.html#2.6-%E6%89%93%E6%A0%87%E7%AD%BE