《Git学习指南》——2.2 第一个Git项目

2.2 第一个Git项目

在这里,我们建议你最好能为接下来的Git测试单独开辟一个项目。总之应先从一个简单的小项目开始。在我们这个小小的示例项目中,first-steps目录下只有两个文本文件,如图2.1所示。

图2.1 我们的示例项目

在开始摆弄这个玩具项目之前,我们建议你最好先做一个备份!尽管在Git中,想要造成永久性的删除或破坏也不是件容易的事情,而且每当你要做某些“危险”动作的时候,Git通常也会发出相应的警告消息。但是,有备无患总是好的。

2.2.1 创建版本库
现在,我们首先需要创建一个版本库,用于存储该项目本身及其历史。为此,我们需要在该项目目录中使用init命令。对于一个带版本库的项目目录,我们通常称之为工作区。

> cd /projects/first-steps
> git init
Initialized empty Git repository in /projects/first-steps/.git/

init命令会在上述目录中创建一个名为.git的隐藏目录,并在其中创建一个版本库。但请注意,该目录在Windows资源管理器或Mac Finder中可能是不可见的。

图2.2 本地版本库所在的目录

2.2.2 首次提交
接下来,我们需要将foo.txt和bar.txt这两个文件添加到版本库中去。在Git中,我们通常将项目的一个版本称之为一次提交,但这要分两个步骤来实现。第一步,我们要先用add命令来确定哪些文件应被包含在下次提交中。第二步,再用commit命令将修改传送到版本库中,并赋予该提交一个散列值以便标识这次新提交。在这里,我们的散列值为2f43cd0,但可能会有所不同,因为该值取决于文件内容。

> git add foo.txt bar.txt
> git commit --message "Sample project imported."
master (root-commit) 2f43cd0] Sample project imported.
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 bar.txt
create mode 100644 foo.txt

2.2.3 检查状态
现在,我们来修改一下foo.txt文件的内容,先删除bar.txt文件,再添加一个名为bar.html的新文件。然后,status命令就会显示出该项目自上次提交以来所发生的所有修改。请注意,新文件bar.html在这里被标示成了未跟踪状态,这是因为我们还没有用add命令将其注册到版本库。

> git status 

# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in
#                                                     working directory)
#
#      deleted:   bar.txt
#      modified:  foo.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#      bar.html
no changes added to commit (use "git add" and/or "git commit -a")

如果我们还想看到更多细节性的内容,也可以通过diff命令来显示其每个被修改的行。当然。有很多人可能会觉得diff的输出是个非常难读的东西。幸运的是,在这一领域,我们有许多工具和开发环境可用,它们可以将这一切显示得更为清晰(见图2.3)。

图2.3 图形工具(kdiff3)中的Diff报告

> git diff foo.txt
diff --git a/foo.txt b/foo.txt
index 1910281..090387f 100644
--- a/foo.txt
+++ b/foo.txt
@@ -1 +1 @@
-foo
\ No newline at end of file
+foo foo
\ No newline at end of file

2.2.4 提交修改
接下来,所有的修改都必须要先被归档成一次新的提交。我们要对修改过的文件和新文件执行add命令,并对要删除的文件使用rm命令。

> git add foo.txt bar.html
> git rm bar.txt
rm 'bar.txt'

现在再次调用status命令,我们会看到所有的修改已经被纳入了下一次提交中。

> git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   bar.html
#       deleted:    bar.txt
#       modified:   foo.txt
#

然后用commit命令提交这些修改。

> git commit --message "Some changes." 

[master 7ac0f38] Some changes. 

3 files changed, 2 insertions(+), 2 deletions(-)
create mode 100644 bar.html
delete mode 100644 bar.txt

2.2.5 显示历史
log命令可用来显示项目的历史,所有提交都会按时间顺序被降序排列出来。

> git log

commit 7ac0f38f575a60940ec93c98de11966d784e9e4f
Author: Rene Preissel <rp@eToSquare.de>
Date: Thu Dec 2 09:52:25 2010 +0100 

    Some changes. 

commit 2f43cd047baadc1b52a8367b7cad2cb63bca05b7
Author: Rene Preissel <rp@eToSquare.de>
Date: Thu Dec 2 09:44:24 2010 +0100 

    Sample project imported.
时间: 2024-10-24 13:33:07

《Git学习指南》——2.2 第一个Git项目的相关文章

《Git学习指南》——2.3 Git的协作功能

2.3 Git的协作功能 现在,我们已经有了一个存放项目文件的工作区,以及一个存放项目历史的版本库.在一个像CVS和Subversion这样传统的集中式版本系统中,尽管每个开发者也都有属于他/她自己的工作区,但所有人都共享了一个通用的版本库.而在Git中,每个开发者拥有的是一个属于他/她自己的.自带独立版本库的工作区,因此这已经是一个不依赖于中央服务器的.完整的版本控制系统了.开发者们可以通过交换各自版本库中的提交来实现项目合作.下面我们就来做个试验,先创建一个新的工作区,以便我们模拟第二位开发

《Git学习指南》——导读

** 前言 **Git的背后有着一个非常精彩的成功故事.2005年4月,Linus Torvalds因不满当时任何一个可用的开源版本控制系统,就亲自着手实现了Git.时至今日,如果我们在Google中搜索"git version control"这几个关键词,都会看到数以百万计的返回结果.Git已经俨然成为了新型开源项目的一个标准.许多大型的开源项目都已经或正在计划迁移到Git上来. 下面,我们来看一下这么多人之所以会选择Git的原因. Git允许我们利用分支来开展工作:在一个由多个开

API Demos 2.3 学习笔记 (2)--创建第一个Android项目(Hello World!)

更多精彩内容,请点击阅读:<API Demos 2.3 学习笔记> 一.根据新建项目向导创建项目 启动Eclipse,选择"File"--"New"--"Project",打开新建项目向导.   展开"Android"项,选择"AndroidProject",单击"Next"按钮继续创建.      在"Projectname:"字段后填写项目名称&quo

《Git学习指南》——第1章 基本概念 1.1分布式版本控制,有何过人之处

第1章 基本概念 在本章中,我们将介绍一个分布式版本控制系统的设计思路,以及它与集中式版本控制系统的不同之处.除此之外,我们还将带你了解分布式版本库的具体工作方式,以及为什么我们会说,在Git中创建分支和合并分支不是个大不了的问题. 1.1 分布式版本控制,有何过人之处 在具体探讨分布式版本控制的概念之前,让我们先来快速回顾一下传统的集中式版本控制架构. 图1.1中所显示的就是一个集中式版本控制系统(例如CVS或Subversion)的典型布局.每个开发者都在他或她自己的计算机上有一个包含所有项

《Git学习指南》——1.2 版本库,分布式工作的基础所在

1.2 版本库,分布式工作的基础所在 其实,版本库本质上就是一个高效的数据存储结构而已,由以下部分组成. 文件(即blob):这里既包含了文本也包含了二进制数据,这些数据将不以文件名的形式被保存.目录(即Tree):目录中保存的是与文件名相关联的内容,其中也会包含其他目录.版本(即commit):每一个版本所定义的都是相应目录的某个可恢复的状态.每当我们创建一个新的版本时,其作者.时间.注释以及其之前的版本都将会被保存下来.对于所有的数据,它们都会被计算成一个十六进制散列值(例如像1632acb

《Git学习指南》——第2章 入门 2.1准备Git环境

第2章 入门 第1章 Spring如果你想试着用一下Git的话,那么我们马上就可以开始了.本章将会带领你创建自己的第一个项目.我们会为你演示那些用于提交修改版本.查看历史和与其他开发者交换版本的命令. 2.1 准备Git环境 首先,我们需要安装好Git.你可以在Git的官网上找到你所需要的一切: http://git-scm.com/downloadGit是一个高可配置软件.首先,我们可以宣布用config命令配置一下用户名和用户邮箱:[1] > git config --global user

《Git学习指南》——2.4 本章小结

2.4 本章小结 工作区与版本库:工作区是一个包含.git子目录(内含版本库)中的目录.我们可以用init命令在当前目录中创建版本库.版本提交:一次版本提交通常定义了版本库中所有文件的一个版本,它详细说明了该版本是由何人在何时何地创建的.当然,我们需要用add命令来确定哪些文件将被纳入下一次提交,然后再用commit命令创建新的版本提交.查看信息:通过status命令,我们可以查看哪些文件已被本地修改,以及哪些修改将被纳入下次提交.另外,log命令可用来显示提交历史.diff命令可用来显示两个版

《Git学习指南》——1.3 分支的创建与合并很简单

1.3 分支的创建与合并很简单 对于大多数版本控制系统来说,分支的创建与合并通常会因其特殊性而被认为是高级拓展操作.但由于Git最初就是为了方便那些散落在世界各地的Linux内核开发者而创建的,合并多方努力的结果一直都是其面临的最大挑战之一,所以Git的设计目标之一就是要让分支的创建与合并操作变得尽可能地简单且安全. 在下面的图1.4中,我们向你展示了开发者是如何通过创建分支的方式来进行并行开发的.图中的每一个点都代表了该项目的一个版本(即commit).而由于在Git中,我们只能对整个项目进行

《Git学习指南》——1.4 本章小结

1.4 本章小结 在阅读完本章之后,我们希望你现在基本上熟悉了Git中的这些基本概念.也就是说,即使你现在放下了这本书(当然,希望不会!),你也可以参加与分布式版本控制系统有关的讨论,阐述其中使用散列值的必要性和实用性,介绍Git中的分支创建与合并操作了. 当然,你可能还会有以下疑问. 我们应该如何利用这些基本概念来管理项目呢?我们应该如何协调多个版本库呢?我们究竟需要多少分支呢?我们应该如何整合自己的构建服务器呢?对于第一个问题,你可以继续阅读下一章内容.在下一章中,你将会看到那些具体用于创建