建立你的第一个 Git 仓库建立你的第一个 Git 仓库

虽然 Git 确实是被许多重要软件选作版本控制工具,但是并不是仅能用于这些重要软件;它也能管理你购物清单(如果它们对你来说很重要的话,当然可以了!)、你的配置文件、周报或日记、项目进展日志、甚至源代码!

使用 Git 是很有必要的,毕竟,你肯定有过因为一个备份文件不能够辨认出版本信息而抓狂的时候。

Git 无法帮助你,除非你开始使用它,而现在就是开始学习和使用它的最好时机。或者,用 Git 的话来说,“没有其他的 push 能像 origin HEAD 一样有帮助了”(千里之行始于足下的意思)。我保证,你很快就会理解这一点的。

类比于录音

我们经常用名词“快照”来指代计算机上的镜像,因为很多人都能够对插满了不同时光的照片的相册充满了感受。这很有用,不过,我认为 Git 更像是进行一场录音。

也许你不太熟悉传统的录音棚卡座式录音机,它包括几个部件:一个可以正转或反转的转轴、保存声音波形的磁带,可以通过拾音头在磁带上记录声音波形,或者检测到磁带上的声音波形并播放给听众。

除了往前播放磁带,你也可以把磁带倒回到之前的部分,或快进跳过后面的部分。

想象一下上世纪 70 年代乐队录制磁带的情形。你可以想象到他们一遍遍地练习歌曲,直到所有部分都非常完美,然后记录到音轨上。起初,你会录下鼓声,然后是低音,再然后是吉他声,最后是主唱。每次你录音时,录音棚工作人员都会把磁带倒带,然后进入循环模式,这样它就会播放你之前录制的部分。比如说如果你正在录制低音,你就会在背景音乐里听到鼓声,就像你自己在击鼓一样,然后吉他手在录制时会听到鼓声、低音(和牛铃声)等等。在每个循环中,你都会录制一部分,在接下来的循环中,工作人员就会按下录音按钮将其合并记录到磁带中。

你也可以拷贝或换下整个磁带,如果你要对你的作品重新混音的话。

现在我希望对于上述的上世纪 70 年代的录音工作的描述足够生动,这样我们就可以把 Git 的工作想象成一个录音工作了。

新建一个 Git 仓库

首先得为我们的虚拟的录音机买一些磁带。用 Git 的话说,这些磁带就是仓库;它是完成所有工作的基础,也就是说这里是存放 Git 文件的地方(即 Git 工作区)。

任何目录都可以成为一个 Git 仓库,但是让我们从一个新目录开始。这需要下面三个命令:

创建目录(如果你喜欢的话,你可以在你的图形化的文件管理器里面完成。)
在终端里切换到目录。
将其初始化成一个 Git 管理的目录。

也就是运行如下代码:

$ mkdir ~/jupiter  # 创建目录
$ cd ~/jupiter     # 进入目录
$ git init .       # 初始化你的新 Git 工作区

在这个例子中,文件夹 jupiter 是一个空的但是合法的 Git 仓库。

有了仓库接下来的事情就可以按部就班进行了。你可以克隆该仓库,你可以在一个历史点前后来回穿梭(前提是你有一个历史点),创建交替的时间线,以及做 Git 能做的其它任何事情。

在 Git 仓库里面工作和在任何目录里面工作都是一样的,可以在仓库中新建文件、复制文件、保存文件。你可以像平常一样做各种事情;Git 并不复杂,除非你把它想复杂了。

在本地的 Git 仓库中,一个文件可以有以下这三种状态:

未跟踪文件Untracked:你在仓库里新建了一个文件,但是你没有把文件加入到 Git 的管理之中。
已跟踪文件Tracked:已经加入到 Git 管理的文件。
暂存区文件Staged:被修改了的已跟踪文件,并加入到 Git 的提交队列中。

任何你新加入到 Git 仓库中的文件都是未跟踪文件。这些文件保存在你的电脑硬盘上,但是你没有告诉 Git 这是需要管理的文件,用我们的录音机来类比,就是录音机还没打开;乐队就开始在录音棚里忙碌了,但是录音机并没有准备录音。

不用担心,Git 会在出现这种情况时告诉你:

$ echo "hello world" > foo
$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
    foo
nothing added but untracked files present (use "git add" to track)

你看到了,Git 会提醒你怎样把文件加入到提交任务中。

不使用 Git 命令进行 Git 操作

在 GitHub 或 GitLab 上创建一个仓库只需要用鼠标点几下即可。这并不难,你单击“New Repository”这个按钮然后跟着提示做就可以了。

在仓库中包括一个“README”文件是一个好习惯,这样人们在浏览你的仓库的时候就可以知道你的仓库是干什么的,更有用的是可以让你在克隆一个有东西的仓库前知道它有些什么。

克隆仓库通常很简单,但是在 GitHub 上获取仓库改动权限就稍微复杂一些,为了通过 GitHub 验证你必须有一个 SSH 密钥。如果你使用 Linux 系统,可以通过下面的命令生成:

$ ssh-keygen

然后复制你的新密钥的内容,它是纯文本文件,你可以使用一个文本编辑器打开它,也可以使用如下 cat 命令查看:

$ cat ~/.ssh/id_rsa.pub

现在把你的密钥粘贴到 GitHub SSH 配置文件 中,或者 GitLab 配置文件。

如果你通过使用 SSH 模式克隆了你的项目,你就可以将修改写回到你的仓库了。

另外,如果你的系统上没有安装 Git 的话也可以使用 GitHub 的文件上传接口来添加文件。

建立你的第一个 Git 仓库建立你的第一个 Git 仓库

跟踪文件

正如命令 git status 的输出告诉你的那样,如果你想让 git 跟踪一个文件,你必须使用命令 git add 把它加入到提交任务中。这个命令把文件存在了暂存区,这里存放的都是等待提交的文件,或者也可以用在快照中。在将文件包括到快照中,和添加要 Git 管理的新的或临时文件时,git add 命令的目的是不同的,不过至少现在,你不用为它们之间的不同之处而费神。

类比录音机,这个动作就像打开录音机开始准备录音一样。你可以想象为对已经在录音的录音机按下暂停按钮,或者倒回开头等着记录下个音轨。

当你把文件添加到 Git 管理中,它会标识其为已跟踪文件:

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

加入文件到提交任务中并不是“准备录音”。这仅仅是将该文件置于准备录音的状态。在你添加文件后,你仍然可以修改该文件;它只是被标记为已跟踪和处于暂存区,所以在它被写到“磁带”前你可以将它撤出或修改它(当然你也可以再次将它加入来做些修改)。但是请注意:你还没有在磁带中记录该文件,所以如果弄坏了一个之前还是好的文件,你是没有办法恢复的,因为你没有在“磁带”中记下那个文件还是好着的时刻。

如果你最后决定不把文件记录到 Git 历史列表中,那么你可以撤销提交任务,在 Git 中是这样做的:

$ git reset HEAD foo

这实际上就是解除了录音机的准备录音状态,你只是在录音棚中转了一圈而已。

大型提交

有时候,你想要提交一些内容到仓库;我们以录音机类比,这就好比按下录音键然后记录到磁带中一样。

在一个项目所经历的不同阶段中,你会按下这个“记录键”无数次。比如,如果你尝试了一个新的 Python 工具包并且最终实现了窗口呈现功能,然后你肯定要进行提交,以便你在实验新的显示选项时搞砸了可以回退到这个阶段。但是如果你在 Inkscape 中画了一些图形草样,在提交前你可能需要等到已经有了一些要开发的内容。尽管你可能提交了很多次,但是 Git 并不会浪费很多,也不会占用太多磁盘空间,所以在我看来,提交的越多越好。

建立你的第一个 Git 仓库建立你的第一个 Git 仓库

commit 命令会“记录”仓库中所有的暂存区文件。Git 只“记录”已跟踪的文件,即,在过去某个时间点你使用 git add 命令加入到暂存区的所有文件,以及从上次提交后被改动的文件。如果之前没有过提交,那么所有跟踪的文件都包含在这次提交中,以 Git 的角度来看,这是一次非常重要的修改,因为它们从没放到仓库中变成了放进去。

完成一次提交需要运行下面的命令:

$ git commit -m 'My great project, first commit.'

这就保存了所有提交的文件,之后可以用于其它操作(或者,用英国电视剧《神秘博士》中时间领主所讲的 Gallifreyan 语说,它们成为了“固定的时间点” )。这不仅是一个提交事件,也是一个你在 Git 日志中找到该提交的引用指针:

$ git log --oneline
55df4c2 My great project, first commit.

如果想浏览更多信息,只需要使用不带 --oneline 选项的 git log 命令。

在这个例子中提交时的引用号码是 55df4c2。它被叫做“提交哈希commit hash”(LCTT 译注:这是一个 SHA-1 算法生成的哈希码,用于表示一个 git 提交对象),它代表着刚才你的提交所包含的所有新改动,覆盖到了先前的记录上。如果你想要“倒回”到你的提交历史点上,就可以用这个哈希作为依据。

你可以把这个哈希想象成一个声音磁带上的 SMPTE 时间码,或者再形象一点,这就是好比一个黑胶唱片上两首不同的歌之间的空隙,或是一个 CD 上的音轨编号。

当你改动了文件之后并且把它们加入到提交任务中,最终完成提交,这就会生成新的提交哈希,它们每一个所标示的历史点都代表着你的产品不同的版本。

这就是 Charlie Brown 这样的音乐家们为什么用 Git 作为版本控制系统的原因。

在接下来的文章中,我们将会讨论关于 Git HEAD 的各个方面,我们会真正地向你揭示时间旅行的秘密。不用担心,你只需要继续读下去就行了(或许你已经在读了?)。

原文来自:http://os.51cto.com/art/201608/515601.htm

转载地址:http://www.linuxprobe.com/first-git-warehouse.html