准备工作：配置信息

在着手创建版本库之前，我们需要进行一些配置工作。通过 git config 命令，我们可以设置当前用户的姓名和邮件地址，这些信息将如同身份标识，在后续的版本库提交中发挥重要作用。例如，我们可以在命令行中输入：

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

请务必将 "Your Name" 和 "your.email@example.com" 替换为您自己的真实姓名和邮箱地址，这样才能确保提交信息的准确性和可追溯性。

不配置会导致 commit 到本地仓库时失败。

初始化操作：创建一个空目录

首先，我们需要在一个空白的目录下创建一个Git版本库。可以使用以下命令来创建一个名为 GitGuide 的目录：

mkdir GitGuide
cd GitGuide

初始化Git版本库

接下来，我们需要使用git init命令来初始化Git版本库。这个命令会在当前目录下创建一个.git子目录，用于存储版本库的信息。可以使用以下命令来初始化Git版本库：

git init

执行完该命令后，我们会发现工作区中多了一个隐藏的 .git 目录，这便是 Git 版本库的所在地。它就像是一个神秘的宝库，将存储我们项目的所有版本信息和变更记录。

添加文件到版本库

现在，我们已经成功地初始化了一个Git版本库。但是，我们的版本库里面还没有任何文件。因此，我们需要将我们的源代码文件添加到版本库中。在工作区中创建一个新文件（例如 welcome.txt），并写入一些内容，如 echo "Hello." > welcome.txt。接下来，我们需要将这个新文件添加到版本库中，可以使用以下命令来添加文件：

git add .

这个命令将会把当前目录下的所有文件都添加到版本库中。如果你想只添加某个特定的文件，可以使用以下命令：

git add <filename>

如果你只想将已跟踪文件（之前添加到暂存区或已提交）的修改添加到暂存区，不会添加新文件（未被跟踪的文件）。可以使用以下命令：

git add -u

提交修改

此时，文件只是被标记为准备提交，但还未真正提交到版本库。我们还需要执行 git commit 命令来完成提交操作，并在提交时提供详细的提交说明：

git commit -m "Initial commit"

这个命令将会将我们刚刚添加的文件提交到版本库中，并且为这次提交添加一条注释信息。在这个例子中，我们使用了"Initial commit"作为注释信息。

思考：为什么工作区下有一个.git目录？

在 Git 的世界中，工作区下的.git 目录是整个版本控制系统的核心所在，它承载着版本管理的关键信息，对 Git 的高效运作起着至关重要的作用。

Git 工作区与版本库布局的独特性

Git 采用了一种与传统集中式版本控制系统（如 CVS 和 Subversion）截然不同的设计理念。在 Git 中，版本库被巧妙地安置于工作区的根目录之下，以一个名为.git 的隐藏目录形式存在。这种布局方式使得所有的版本控制操作（除了与远程版本库的交互）都能够在本地迅速完成，无需频繁地与远程服务器进行数据传输，极大地提升了操作的速度和便捷性。

一、与 CVS 工作区设计的对比

1.CVS 的工作区跟踪机制

• CVS 在工作区的根目录及每一个子目录下都创建了一个 CVS 目录，该目录中的 Entries 文件详细记录了从版本库检出到工作区的文件的名称、版本和时间戳等重要信息。通过对比这些时间戳，CVS 能够快速扫描工作区文件的改动情况。

• 例如，在一个多人协作的项目中，当开发者从 CVS 服务器检出代码到本地工作区后，CVS 会在每个目录下的 CVS/Entries 文件中记录文件的相关信息。当开发者对文件进行修改后，CVS 可以通过检查文件的时间戳与 Entries 文件中的记录是否一致，来判断文件是否发生了变化。

2.CVS 工作区设计的优缺点优点：

优点：这种设计使得工作区具有较强的移动性，即使将工作区移动到其他目录，或者将工作区的某个子目录移动到其他位置形成新的工作区，工作区与版本控制服务器的映射关系依然能够保持不变，从而保证工作区可以继续正常工作。

缺点：然而，CVS 的这种设计也存在明显的弊端。由于在提交修改时，CVS 只能依据时间戳判断文件是否改动，而无法获取文件的原始内容进行差异比较，因此只能对整个文件进行传输，无法仅传输文件的改动部分，这无疑降低了从客户端到服务器的网络传输效率。此外，Web 服务器目录下若包含 CVS 目录，其 Entries 文件可能会泄露目录下的文件列表，给服务器安全带来隐患。

二、与 Subversion 工作区设计的对比

1.Subversion 的工作区跟踪方式

Subversion 在工作区的根目录和每一个子目录下都设有一个.svn 目录。这个.svn 目录不仅包含了类似于 CVS 的跟踪目录下的配置文件，还存储了当前工作区下每一个文件的拷贝。这些文件的原始拷贝使得 Subversion 的某些子命令能够脱离版本库执行，并且在提交时，Subversion 可以通过将改动的文件与原始拷贝进行差异比较，从而只提交改动的部分，提高了网络传输效率。例如，在一个使用 Subversion 管理的项目中，当开发者修改了一个文件后，Subversion 会在提交时将修改后的文件与.svn 目录中的原始文件拷贝进行对比，计算出差异部分，然后仅将差异部分传输到服务器。

2.Subversion 工作区设计的优缺点

优点：Subversion 的这种设计在一定程度上提高了提交效率，减少了不必要的网络传输。

缺点：但是.svn 目录的存在同样带来了诸多问题。与 CVS 类似，.svn 目录下的文件可能会导致信息泄漏，危及服务器安全。而且，由于.svn 目录中存储了文件的原始拷贝，会加倍占用工作区的空间。在工作区目录下进行文件内容搜索时，.svn 目录下的文件拷贝会导致搜索结果加倍，使搜索结果变得混乱，给开发者带来困扰。

三、Git 工作区设计的优势

1.高效的本地操作

Git 将版本库置于工作区根目录下的.git 目录中，使得诸如查看提交日志、提交、创建里程碑和分支、合并分支、回退等操作都能够直接在本地迅速完成，无需依赖网络连接。这对于开发者来说，意味着可以更加快速地进行版本控制操作，提高工作效率。例如，在开发过程中，开发者可以频繁地进行本地提交，记录自己的工作进展，而不用担心网络延迟或服务器故障对工作的影响。

2.安全性提升

由于.git 目录是隐藏的，相对不易被误操作或恶意访问，只要保护好.git 目录，就能有效

思考：把版本库:file:`.git`目录放在工作区，是不是太不安全了？

从存储安全的角度上来讲，将版本库放在工作区目录下，有点“把鸡蛋装在一个篮子里”的味道。如果忘记了工作区中还有版本库，直接从工作区的根执行目录删除就会连版本库一并删除，这个风险的确是蛮高的。将版本库和工作区拆开似乎更加安全，但是不要忘了之前的讨论，将版本库和工作区拆开，就要引入其他机制以便实现版本库对工作区的追踪。

Git克隆可以降低因为版本库和工作区混杂在一起导致的版本库被破坏的风险。可以通过克隆版本库，在本机另外的磁盘/目录中建立Git克隆，并在工作区有改动提交时，手动或自动地执行向克隆版本库的推送（git push）操作。如果使用网络协议，还可以实现在其他机器上建立克隆，这样就更安全了（双机备份）。对于使用Git做版本控制的团队，每个人都是一个备份，因此团队开发中的Git版本库更安全，管理员甚至根本无须顾虑版本库存储安全问题。

思考：不设置姓名和邮箱可以提交到本地仓库吗?

引用

`思考：把版本库:file:`.git`目录放在工作区，是不是太不安全了？`回答来自<Git权威指南>