Git学习笔记之起步
起步
版本管理工具
版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单,但是特别容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。
其中最流行的一种叫做 RCS,现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。
集中化的版本控制系统
中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)可以让在不同系统上的开发者协同工作。这类系统,诸如 CVS、Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
缺点是中央服务器的单点故障,如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据——包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
分布式版本控制系统
分布式版本控制系统(Distributed Version Control System,简称 DVCS),像 Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。 每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
Git简介
关于Git的历史这里不赘述,总结下来,Git的设计理念是:
- 速度快
- 设计简单
- 对非线性开发模式的强力支持
- 完全分布式
- 有能力高效管理超大规模醒目
理解了 Git 的思想和基本工作原理,用起来就会知其所以然,游刃有余。尽管 Git 用起来与其它的版本控制系统非常相似, 但它在对信息的存储和认知方式上却有很大差异,理解这些差异将有助于避免使用中的困惑。
直接记录快照,而非差异比较
一些版本控制系统,统以文件变更列表的方式存储信息,这类系统将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 (它们通常称作 基于差异(delta-based) 的版本控制)。
例如上图,版本2记录的是与版本1中的File A和File B的差异。版本3记录是与版本2中的File C的差异。
Git 不按照以上方式对待或保存数据。反之,Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中,每当你提交更新或保存项目状态时,它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
例如上图,版本2保存的是变更后的A1和C1,以及没有变更的版本1中的File B。
这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统,提供了许多以此为基础构建的超强工具,而不只是一个简单的 VCS。
近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其它计算机的信息。Git在本地有仓库的完整克隆,因此基本上只需要在本地操作即可,本地操作完整,可以将本地仓库push
到远端,此时才需要网络。
Git 保证完整性
Git 中所有的数据在存储前都计算校验和,然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容(而不是文件名)或目录结构计算出来。
Git 一般只添加数据
你执行的 Git 操作,几乎只往 Git 数据库中 添加 数据。 你很难使用 Git 从数据库中删除数据,也就是说 Git 几乎不会执行任何可能导致文件不可恢复的操作。 同别的 VCS 一样,未提交更新时有可能丢失或弄乱修改的内容。
即使是删除数据,也只是将当前数据从当前分支中移除,而不是真正意义上的将文件删掉,在Git的其他分支,依然可以找回文件。
三种状态
Git 有三种状态,你的文件可能处于其中之一: 已提交(committed)、已修改(modified) 和 已暂存(staged)。
committed
:已提交表示数据已经安全地保存在本地数据库中。modified
:已修改表示修改了文件,但还没保存到数据库中。staged
:已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。
这会让我们的 Git 项目拥有三个阶段:工作区、暂存区以及 Git 目录。
- 工作区:是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。
- 暂存区:是一个文件,保存了下次将要提交的文件列表信息,一般在 Git 仓库目录中。 按照 Git 的术语叫做“索引”,不过一般说法还是叫“暂存区”。
- Git 仓库目录:是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据。
基本的 Git 工作流程如下:
- 在工作区中修改文件。
- 将你想要下次提交的更改选择性地暂存,这样只会将更改的部分添加到暂存区。
- 提交更新,找到暂存区的文件,将快照永久性存储到 Git 目录。
如果 Git 目录中保存着特定版本的文件,就属于 已提交 状态。 如果文件已修改并放入暂存区,就属于 已暂存 状态。 如果自上次检出后,作了修改但还没有放到暂存区域,就是 已修改 状态。
命令行
Git的使用方式有很多种,可以使用原生的命令行模式,也可以使用 GUI 模式,这些 GUI 软件也能提供多种功能。
学习过程中,应该先学会命令行,GUI是对命令行的封装,会了命令行,GUI也就自然学会了。
安装
按照官网的教程即可。
macOS建议通过homebrew安装
1 | brew install git |
初次运行 Git 前的配置
Git 自带一个 git config
的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置:
/etc/gitconfig
文件: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行git config
时带上--system
选项,那么它就会读写该文件中的配置变量。 (由于它是系统配置文件,因此你需要管理员或超级用户权限来修改它。)~/.gitconfig
或~/.config/git/config
文件:只针对当前用户。 你可以传递--global
选项让 Git 读写此文件,这会对你系统上 所有 的仓库生效。- 当前使用仓库的 Git 目录中的
config
文件(即.git/config
):针对该仓库。 你可以传递--local
选项让 Git 强制读写此文件,虽然默认情况下用的就是它。 (当然,你需要进入某个 Git 仓库中才能让该选项生效。)
每一个级别会覆盖上一级别的配置,所以 .git/config
的配置变量会覆盖 /etc/gitconfig
中的配置变量。
通过以下命令查看所有的配置以及它们所在的文件:
1 | git config --list --show-origin |
用户信息
安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:
1 | git config --global user.name "John Doe" |
如果使用了 --global
选项,那么该命令只需要运行一次。
检查配置信息
获取所有配置
1 | git config --list |
如果有重复的变量名,这种情况下,Git 会使用它找到的每一个变量的最后一个配置。也就是后面的覆盖前面的。
也可以获取某个配置
1 | git config user.name |
获取帮助
1 | git --help |
以及二级命令的帮助
1 | git init --help |