关闭

git 使用详解(3)-- 初体验

标签: gitbranchsubversion工作file正则表达式
2032人阅读 评论(0) 收藏 举报
分类:

Git 基础

本章将介绍几个最基本的,也是最常用的 Git 命令,以后绝大多数时间里用到的也就是这几个命令。读完本章,你就能初始化一个新的代码仓库,做一些适当配置;开始或停止跟踪某些文件;暂存或提交某些更新。我们还会展示如何让 Git 忽略某些文件,或是名称符合特定模式的文件;如何既快且容易地撤消犯下的小错误;如何浏览项目的更新历史,查看某两次更新之间的差异;以及如何从远程仓库拉数据下来或者推数据上去。

在工作目录中初始化新仓库

要对现有的某个项目开始用 Git 管理,只需到此项目所在的目录,执行:

$ git init

初始化后,在当前目录下会出现一个名为 .git 的目录,所有 Git 需要的数据和资源都存放在这个目录中。不过目前,仅仅是按照既有的结构框架初始化好了里边所有的文件和目录,但我们还没有开始跟踪管理项目中的任何一个文件。

如果当前目录下有几个文件想要纳入版本控制,需要先用 git add 命令告诉 Git 开始对这些文件进行跟踪,然后提交:

$ git add *.c 
$ git add README 
$ git commit -m 'initial project version'

现在,你已经得到了一个实际维护着若干文件的 Git 仓库

从现有仓库克隆

如果想对某个开源项目出一份力,可以先把该项目的 Git 仓库复制一份出来,这就需要用到 git clone 命令。如果你熟悉其他的 VCS 比如 Subversion,你可能已经注意到这里使用的是 clone 而不是 checkout。这是个非常重要的差别,Git 收取的是项目历史的所有数据(每一个文件的每一个版本)服务器上有的数据 克隆 之后本地也都有了。实际上,即便服务器的磁盘发生故障,用任何一个克隆出来的客户端都可以重建服务器上的仓库,回到当初克隆时的状态

克隆仓库的命令格式为 git clone [url]。比如,要克隆 Ruby 语言的 Git 代码仓库 Grit,可以用下面的命令:

$ git clone git://github.com/schacon/grit.git

这会在 当前目录下 创建一个名为 “grit” 的目录,其中包含一个 .git 的目录,用于保存下载下来的所有版本记录,然后从中取出最新版本 的文件拷贝。如果进入这个新建的 grit 目录,你会看到项目中的所有文件已经在里边了,准备好后续的开发和使用。如果希望在克隆的时候,自己定义要新建的项目目录名称,可以在上面的命令末尾指定新的名字:

$ git clone git://github.com/schacon/grit.git mygrit

唯一的差别就是,现在新建的目录成了 mygrit,其他的都和上边的一样。

Git 支持许多数据传输协议。之前的例子使用的是 git:// 协议,不过你也可以用 http(s):// 或者user@server:/path.git 表示的 SSH 传输协议。

记录每次更新到仓库

现在我们手上已经有了一个真实项目的 Git 仓库,并从这个仓库中取出了所有文件的工作拷贝。接下来,对这些文件作些修改,在完成了一个阶段的目标之后,提交本次更新到仓库。

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

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

图 2-1. 文件的状态变化周期

检查当前文件状态

确定 哪些文件 当前 处于 什么状态,可以用 git status 命令。如果在克隆仓库之后立即执行此命令,会看到类似这样的输出:

$ git status 
# On branch master nothing to commit (working directory clean)

这说明你 现在的工作目录 没有任何文件在上次提交后更改过。此外,上面的信息还表明,当前目录下没有出现任何处于未跟踪的新文件,否则 Git 会在这里列出来。最后,该命令还显示了当前所在的分支是 master,这是默认的分支名称,实际是可以修改的。

现在让我们用 vim 编辑一个新文件 README,保存退出后运行 git status 会看到该文件出现在未跟踪文件列表中:

$ vim README 
$ git status 
# On branch master
# Untracked files
# (use "git add <file>..." to include in what will be committed) 
# #	README nothing added to commit but untracked files present (use "git add" to track)

就是在“Untracked files”这行下面。Git 不会自动将之纳入跟踪范围,除非你明明白白地告诉它“我需要跟踪该文件”,因而不用担心把临时文件什么的也归入版本管理。不过现在的例子中,我们确实想要跟踪管理 README 这个文件。

跟踪新文件

使用命令 git add 开始跟踪一个新文件。所以,要跟踪 README 文件,运行:

$ git add README

此时再运行 git status 命令,会看到 README 文件已被跟踪,并处于暂存状态:

$ git status 
# On branch master 
# Changes to be committed
# (use "git reset HEAD <file>..." to unstage) 
# #	new file: README #

只要在 “Changes to be committed” 这行下面的,就说明是已暂存状态。如果此时提交,那么该文件此时此刻的版本将被留存在历史记录中。你可能会想起之前我们使用 git init 后就运行了 git add 命令,开始跟踪当前目录下的文件。在 git add 后面可以指明要跟踪的 文件 或 目录 路径如果是目录的话,就说明要递归跟踪该目录下的所有文件

暂存已修改文件

现在我们修改下之前已跟踪过的文件 benchmarks.rb,然后再次运行 status 命令,会看到这样的状态报告:

$ git status 
# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# #	new file: README 
# # Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# #	modified: benchmarks.rb #

文件 benchmarks.rb 出现在 “Changed but not updated” 这行下面,说明已跟踪文件的内容发生了变化,但还没有放到 暂存区。要暂存这次更新,需要运行 git add 命令(这是个多功能命令,根据目标文件的状态不同,此命令的效果也不同:可以用它开始跟踪 新文件,或者把 已跟踪的文件放到暂存区,还能用于合并时把 有冲突的文件标记为已解决状态等)。现在让我们运行 git add 将 benchmarks.rb 放到暂存区,然后再看看 git status 的输出:

$ git add benchmarks.rb 
$ git status 
# On branch master 
# Changes to be committed
# (use "git reset HEAD <file>..." to unstage) 
#	new file: README 
#	modified: benchmarks.rb #

现在两个文件都已暂存,下次提交时就会一并记录到仓库。假设此时,你想要在 benchmarks.rb 里再加条注释,重新编辑存盘后,准备好提交。不过且慢,再运行 git status 看看:

$ vim benchmarks.rb 
$ git status 
# On branch master 
# Changes to be committed
# (use "git reset HEAD <file>..." to unstage) 
# #	new file: README 
#	modified: benchmarks.rb 
# # Changed but not updated
# (use "git add <file>..." to update what will be committed) 
# #	modifiedbenchmarks.rb #

怎么回事?benchmarks.rb 文件出现了两次!一次算未暂存,一次算已暂存,这怎么可能呢?好吧,实际上 Git 只不过暂存了你运行 git add 命令时的版本,如果现在提交,那么提交的是添加注释前的版本,而非当前工作目录中的版本。所以,运行了 git add 之后又作了修订的文件,需要重新运行 git add 把最新版本重新暂存起来

$ git add benchmarks.rb 
$ git status 
# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
#
#	new file: README 
#	modified: benchmarks.rb 
#

忽略某些文件

一般我们总会有些文件无需纳入 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 # 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO 
build/ # 忽略 build/ 目录下的所有文件 
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3451851次
    • 积分:25530
    • 等级:
    • 排名:第239名
    • 原创:369篇
    • 转载:124篇
    • 译文:2篇
    • 评论:327条
    最新评论