Git指南（一）

saluuu

已于 2024-08-22 18:38:17 修改

阅读量988

点赞数 17

文章标签： git

于 2024-08-21 12:56:42 首次发布

本文链接：https://blog.csdn.net/weixin_47488350/article/details/141390679

版权

1. 版本控制（VCS）

使用VCS你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。

使用VCS通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

1.1. 本地版本控制系统

许多人习惯备份用改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

而本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

1.2. 集中化的版本控制系统(Centralized Version Control Systems，简称 CVCS)

如何让在不同系统上的开发者协同工作？集中化的版本控制系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。

缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

1.3. 分布式版本控制系统(Distributed Version Control System，简称 DVCS)

分布式版本控制系统，像 Git、Mercurial 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来，包括完整的历史记录。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。你可以在同一个项目中，分别和不同工作小组的人相互协作。你也可以根据需要设定不同的协作流程。

2. Git是什么

Git是由Linus Torvalds于2005年创建，是一个开源的分布式版本控制系统。

2.1. 直接记录快照，而非差异比较

其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce 等等）将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异（它们通常称作 基于差异（delta-based）的版本控制）。

Git中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流。

这是 Git 与几乎所有其它版本控制系统的重要区别。

2.2. 近乎所有操作都是本地执行

要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改， Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。操作速度也会非常快。

2.3. Git 保证完整性

Git 数据库中保存的信息都是以文件内容的哈希值（SHA-1散列）来索引，而不是文件名。其次，Git在存储数据前都会检验哈希值，这就意味着若你在传送过程中丢失信息或损坏文件，Git 就能发现。

2.4. Git一般只添加数据

Git 几乎不会执行任何可能导致文件不可恢复的操作。你执行的 Git 操作，几乎只往 Git 数据库中添加数据。

2.5. 三种状态

已提交（committed）、已修改（modified）和已暂存（staged）

已修改表示修改了文件，但还没保存到数据库中。
已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
已提交表示数据已经安全地保存在本地数据库中。

如果 Git 目录中保存着特定版本的文件，就属于 已提交 状态。如果文件已修改并放入暂存区，就属于 已暂存 状态。如果自上次检出后，作了修改但还没有放到暂存区域，就是 已修改 状态。

Git三个阶段：工作区、暂存区以及 Git 目录

工作区：是对项目的某个版本独立提取出来的内容。这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。
暂存区：是一个文件，保存了下次将要提交的文件列表信息，一般在 Git 仓库目录中。按照 Git 的术语叫做“索引”，不过一般说法还是叫“暂存区”。
Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。这是 Git 中最重要的部分，从其它计算机克隆仓库时，复制的就是这里的数据。

基本的 Git 工作流程如下：

在工作区中修改文件。
将你想要下次提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区。
提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录。

3. Git安装

3.1. Linux下安装

以 Fedora 为例，如果你在使用它（或与之紧密相关的基于 RPM 的发行版，如 RHEL 或 CentOS），你可以使用 dnf：

$ sudo dnf install git-all

如果你在基于 Debian 的发行版上，如 Ubuntu，请使用 apt：

$ sudo apt install git-all

3.2. Windows下安装

下载页面的链接 https://git-scm.com/downloads

4. 初次运行 Git 前的配置

安装完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 中的配置变量。

你可以通过以下命令查看所有的配置以及它们所在的文件：

$ git config --list --show-origin

4.1. 用户信息

安装完 Git 之后，要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改：

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

再次强调，如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息。当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 --global 选项的命令来配置。

4.2. 文本编辑器

如果未配置，Git 会使用操作系统默认的文本编辑器。

如果你想使用不同的文本编辑器，例如 Emacs，可以这样做：

$ git config --global core.editor emacs

在 Windows 系统上，如果你想要使用别的文本编辑器，那么必须指定可执行文件的完整路径。它可能随你的编辑器的打包方式而不同。

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

4.3. 检查配置信息

使用 git config --list 命令来列出所有 Git 当时能找到的配置：

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

你可能会看到重复的变量名，因为 Git 会从不同的文件中读取同一个配置（例如：/etc/gitconfig 与 ~/.gitconfig）。这种情况下，Git 会使用它找到的每一个变量的最后一个配置。

你可以查询 Git 中该变量的原始值，它会告诉你哪一个配置文件最后设置了该值：

$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig	false

你可以通过输入 git config <key>：来检查 Git 的某一项配置：

$ git config user.name
John Doe

5. 获取帮助

有三种等价的方法可以找到 Git 命令的综合手册（manpage）：

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

例如，要想获得 git config 命令的手册，执行

$ git help config

此外，如果你不需要全面的手册，只需要可用选项的快速参考，那么可以用 -h 选项获得更简明的 "help"输出：

$ git add -h
usage: git add [<options>] [--] <pathspec>...

    -n, --dry-run         dry run
    -v, --verbose         be verbose

    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    --renormalize         renormalize EOL of tracked files (implies -u)
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --ignore-removal      ignore paths removed in the working tree (same as --no-all)
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run
    --chmod (+|-)x        override the executable bit of the listed files

原书链接：Git - Book (git-scm.com)

saluuu

关注

17
点赞
踩
15

收藏

觉得还不错? 一键收藏
1
评论
Git指南（一）

集中化的版本控制系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。使用VCS你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
复制链接

扫一扫