12 KiB
建立你的第一个仓库
现在是时候学习怎样创建你自己的仓库了，还有怎样增加文件和完成提交。
在本系列前面文章的安装过程中，你已经学习了作为一个目标用户怎样与 Git 进行交互；你就像一个漫无目的的流浪者一样偶然发现了一个开源项目网站，然后克隆了仓库，Git 走进了你的生活。学习怎样和 Git 进行交互并不像你想的那样困难，或许你并不确信现在是否应该使用 Git 完成你的工作。
Git 被认为是选择大多软件项目的工具，它不仅能够完成大多软件项目的工作；它也能管理你杂乱项目的列表（如果他们不重要，也可以这样说！），你的配置文件，一个日记，项目进展日志，甚至源代码！
使用 Git 是很有必要的，毕竟，你肯定有因为一个备份文件不能够辨认出版本信息而烦恼的时候。
你不使用 Git，它也就不会为你工作，或者也可以把 Git 理解为“没有任何推送就像源头指针一样”【译注： HEAD 可以理解为“头指针”，是当前工作区的“基础版本”，当执行提交时， HEAD 指向的提交将作为新提交的父提交。】。我保证，你很快就会对 Git 有所了解 。
类比于录音
我们更喜欢谈论快照上的图像，因为很多人都可以通过一个相册很快辨认出每个照片上特有的信息。这可能很有用，然而，我认为 Git 更像是在进行声音的记录。
传统的录音机，可能你对于它的部件不是很清楚：它包含转轴并且正转或反转，使用磁带保存声音波形，通过放音头记录声音并保存到磁带上然后播放给收听者。
除了往前退磁带，你也可以把磁带多绕几圈到磁带前面的部分，或快进跳过前面的部分到最后。
想象一下 70 年代的磁带录制的声音。你可能想到那会正在反复练习一首歌直到非常完美，它们最终被记录下来了。起初，你记录了鼓声，低音，然后是吉他声，还有其他的声音。每次你录音，工作人员都会把磁带重绕并设置为环绕模式，这样在你演唱的时候录音磁带就会播放之前录制的声音。如果你是低音歌唱，你唱歌的时候就需要把有鼓声的部分作为背景音乐，然后就是吉他声、鼓声、低音（和牛铃声【译注：一种打击乐器，状如四棱锥。】）等等。在每一环，你完成了整个部分，到了下一环，工作人员就开始在磁带上制作你的演唱作品。
你也可以拷贝或换出整个磁带，这是你需要继续录音并且进行多次混合的时候需要做的。
现在我希望对于上述 70 年代的录音工作的描述足够生动，我们就可以把 Git 的工作想象成一个录音磁带了。
新建一个 Git 仓库
首先得为我们的虚拟的录音机买一些磁带。在 Git 术语中，这就是仓库；它是完成所有工作的基础，也就是说这里是存放 Git 文件的地方（即 Git 工作区）。
任何目录都可以是一个 Git 仓库，但是在开始的时候需要进行一次更新。需要下面三个命令：
- 创建目录（如果你喜欢的话，你可以在你的 GUI 文件管理器里面完成。）
- 在终端里查看目录。
- 初始化这个目录使它可以被 Git管理。
特别是运行如下代码：
$ mkdir ~/jupiter # 创建目录
$ cd ~/jupiter # 进入目录
$ git init . # 初始化你的新 Git 工作区
在这个例子中，文件夹 jupiter 是空的但却成为了你的 Git 仓库。
有了仓库接下来的事件就按部就班了。你可以克隆项目仓库，你可以在一个历史点前后来回穿梭（前提是你有一个历史点），创建可交替时间线，然后剩下的工作 Git 就都能正常完成了。
在 Git 仓库里面工作和在任何目录里面工作都是一样的；在仓库中新建文件，复制文件，保存文件。你可以像平常一样完成工作；Git 并不复杂，除非你把它想复杂了。
在本地的 Git 仓库中，一个文件可以有下面这三种状态：
- 未跟踪文件：你在仓库里新建了一个文件，但是你没有把文件加入到 Git 的提交任务（提交暂存区，stage）中。
- 已跟踪文件：已经加入到 Git 暂存区的文件。
- 暂存区文件：存在于暂存区的文件已经加入到 Git 的提交队列中。
任何你新加入到 Git 仓库中的文件都是未跟踪文件。文件还保存在你的电脑硬盘上，但是你没有告诉 Git 这是需要提交的文件，就像我们的录音机，如果你没有打开录音机；乐队开始演唱了，但是录音机并没有准备录音。
不用担心，Git 会告诉你存在的问题并提示你怎么解决：
$ echo "hello world" > foo
$ git status
位于您当前工作的分支 master 上
未跟踪文件：
（使用 "git add <file>" 更新要提交的内容）
foo
没有任何提交任务，但是存在未跟踪文件（用 "git add" 命令加入到提交任务）
你看到了，Git 会提醒你怎样把文件加入到提交任务中。
### 不使用 Ｇit 命令进行 Git 操作
在 GitHub 或 GitLab（译注：GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。）上创建一个仓库大多是使用鼠标点击完成的。这不会很难，你单击 New Repository 这个按钮就会很快创建一个仓库。
在仓库中新建一个 README 文件是一个好习惯，这样人们在浏览你的仓库的时候就可以知道你的仓库基于什么项目，更有用的是通过 README 文件可以确定克隆的是否为一个非空仓库。
克隆仓库通常很简单，但是在 GitHub 上获取仓库改动权限就不简单了，为了进行用户验证你必须有一个 SSH 秘钥。如果你使用 Linux 系统，通过下面的命令可以生成一个秘钥：
$ ssh-keygen
复制纯文本文件里的秘钥。你可以使用一个文本编辑器打开它，也可以使用 cat 命令：
$ cat ~/.ssh/id_rsa.pub
现在把你的秘钥拷贝到 GitHub SSH 配置文件 中，或者 [GitLab 配置文件2。
如果你通过使用 SSH 模式克隆了你的项目，就可以在你的仓库开始工作了。
另外，如果你的系统上没有安装 Git 的话也可以使用 GitHub 的文件上传接口来克隆仓库。
跟踪文件
命令 git status 的输出会告诉你如果你想让 git 跟踪一个文件，你必须使用命令 git add 把它加入到提交任务中。这个命令把文件存在了暂存区，暂存区存放的都是等待提交的文件，或者把仓库保存为一个快照。git add 命令的最主要目的是为了区分你已经保存在仓库快照里的文件，还有新建的或你想提交的临时文件，至少现在，你都不用为它们之间的不同之处而费神了。
类比大型录音机，这个动作就像打开录音机开始准备录音一样。你可以按已经录音的录音机上的 pause 按钮来完成推送，或者按下重置按钮等待开始跟踪下一个文件。
如果你把文件加入到提交任务中，Git 会自动标识为跟踪文件：
$ git add foo
$ git status
位于您当前工作的分支 master 上
下列修改将被提交：
（使用 "git reset HEAD <file>..." 将下列改动撤出提交任务）
新增文件：foo
加入文件到提交任务中并不会生成一个记录。这仅仅是为了之后方便记录而把文件存放到暂存区。在你把文件加入到提交任务后仍然可以修改文件；文件会被标记为跟踪文件并且存放到暂存区，所以你在最终提交之前都可以改动文件或撤出提交任务（但是请注意：你并没有记录文件，所以如果你完全改变了文件就没有办法撤销了，因为你没有记住最终修改的准确时间。）。
如果你决定不把文件记录到 Git 历史列表中，那么你可以撤出提交任务，在 Git 中是这样做的：
$ git reset HEAD foo
这实际上就是删除了录音机里面的录音，你只是在工作区转了一圈而已而已。
大型提交
有时候，你会需要完成很多提交；我们以录音机类比，这就好比按下录音键并最终按下保存键一样。
在一个项目从建立到完成，你会按记录键无数次。比如，如果你通过你的方式使用一个新的 Python 工具包并且最终实现了窗口展示，然后你就很肯定的提交了文件，但是不可避免的会发生一些错误，现在你却不能撤销你的提交操作了。
一次提交会记录仓库中所有的暂存区文件。Git 只记录加入到提交任务中的文件，也就是说在过去某个时刻你使用 git add 命令加入到暂存区的所有文件。还有从先前的提交开始被改动的文件。如果没有其他的提交，所有的跟踪文件都包含在这次提交中，因为在浏览 Git 历史点的时候，它们没有存在于仓库中。
完成一次提交需要运行下面的命令：
$ git commit -m 'My great project, first commit.'
这就保存了所有需要在仓库中提交的文件（或者，如果你说到 Gallifreyan【译注：英国电视剧《神秘博士》里的时间领主使用的一种优雅的语言，】,它们可能就是“固定的时间点” ）。你不仅能看到整个提交记录，还能通过 git log 命令查看修改日志找到提交时的版本号：
$ git log --oneline
55df4c2 My great project, first commit.
如果想浏览更多信息，只需要使用不带 --oneline 选项的 git log 命令。
在这个例子中提交时的版本号是 55df4c2。它被叫做 commit hash（译注：一个SHA-1生成的哈希码，用于表示一个git commit对象。），它表示着刚才你的提交包含的所有改动，覆盖了先前的记录。如果你想要“倒回”到你的提交历史点上就可以用这个 commit hash 作为依据。
你可以把 commit hash 想象成一个声音磁带上的 SMPTE timecode,或者再夸张一点，这就是好比一个黑胶唱片上两首不同的歌之间的不同点，或是一个 CD 上的轨段编号。
你在很久前改动了文件并且把它们加入到提交任务中，最终完成提交，这就会生成新的 commit hashes，每个 commit hashes 标示的历史点都代表着你的产品不同的版本。
这就是 Charlie Brown 把 Git 称为版本控制系统的原因。
在接下来的文章中，我们将会讨论你需要知道的关于 Git HEAD 的一切，我们不准备讨论关于 Git 的提交历史问题。基本不会提及，但是你可能会需要了解它（或许你已经有所了解？）。
via: https://opensource.com/life/16/7/creating-your-first-git-repository
作者：Seth Kenlon 译者：vim-kakali 校对：校对者ID