Git 分布式版本控制工具安装与使用

暂存区给开发者提供了更细粒度的控制手段。一次修改可能包含多个不同内容的修复，暂存区分批提交可以细化提交工作。

3. 本地仓库（Local Repository）：存储在本地机器上的 Git 仓库，记录了项目的所有提交历史。可用命令有：git merge 分支名 合并其他分支的代码到当前分支、git checkout 分支名 切换到指定分支；
4. 远程仓库（Remote Repository）：位于服务器端的远程仓库，如 GitHub、国内的 Gitee（码云）和需要自己部署的 GitLab，常用命令有
   git push 本地仓库推送至远程服务器
   git clone 远程仓库克隆到本地，通常只有第一次使用
   git fetch 从远程服务器获取修改到跟踪分支，后续手动使用 git merge 合并
   git pull 从远程服务器获取修改并自动合并，即 pull=fetch+merge

相关流程可表示为下图：

本地命令

1. 状态转换

配置别名
我们要使用的有些命令较长，可以采用起别名的方法简化，新建 .bashrc 文件，写入 alias 新命令 '原长命令'，并使用 source .bashrc 编译即可，别名 alias ll='ls -al' 的示例如下：

配置用户信息
git config --global user.name 用户名 指定全局用户名
git config --global user.email 邮箱 指定全局邮箱
git config --global user.name 查看用户名
git config --list 查看所有配置

初始化仓库
要使用的目录下右键进入 Git Bash，输入命令 git init，可见生成隐藏目录 .git

5. 忽略文件
   有些文件我们不希望参与 Git 管理，可新建 .gitignore 文件，文件内写通配符或具体名称即可，如 *.a 为以 a 为扩展名结尾的文件不参与管理。

远程仓库

1. 远程操作仓库
   git clone 仓库路径 本地目录，首次使用仓库需克隆，本地目录缺省会直接使用仓库名称新建，克隆包含所有分支的完整仓库，需特定分支可用参数 -b 分支名 指定；
   git fetch origin 分支名，抓取更新文件到远程跟踪分支
   git merge，合并更新至当前所在分支
   git pull origin 分支名，拉取并合并，等于 fetch+merge
   git push origin 分支名，将本地分支上传到仓库，有则合并（本地分支落后时拒绝），无则创建
   git branch 查看分支

分支保护
master 是开发的主分支，各组件开发、功能修复等分支最后都往这个分支合并，必须对这个分支进行保护，可使用如下权限设置。

主分支的合并需要审核和测试才能进行。

远程连接
SSH 连接远程仓库需使用密钥，先使用 ssh-keygen -t rsa 生成 RSA 密钥，三次回车全选默认配置（第一次选项是换目录，换了会导致后续无法验证，要换目录验证时可用 -i 指定），图中是密钥保存位置。

Linux 可使用 cat 打开，Windows 找到对应目录自行打开，复制 id_rsa.pub 的密钥添加公钥。

使用 ssh -T [email protected] 验证连接，出现如下界面说明密钥配置成功：

git remote add origin 地址 添加远程仓库，仓库名为 origin

新建仓库
国内使用比较方便的代码平台是码云，官网为 https://gitee.com，网页右上角，头像旁按键可新建仓库。

新建后选择仓库名称和介绍

随后生成初始化 readme

解决冲突

不同开发者更改了代码的相同几行即为冲突，如二者都根据登录模块同时添加功能，第一个提交者在行末添加，第二个开发者要提交时则会报冲突。

比如两个用户分别修改如下行：

A 用户上传成功，B 用户要上传会提示错误，提示本地没有文件，本质是远程版本比本地的更新（更新基线问题），Git 会自动拒绝对更新版本的覆写。

此时需要先使用 git pull 拉取最新版本，在本地解决冲突，冲突行 Git 会标记提示，此时需要开发者自行解决，通常是挪动代码。

冲突标记包围的上方是待推送内容，下方是远程仓库拉取的最新内容，最下方的 1 是误报，删除标记整合重新提交即可。

git add 文件名
git commit -m "解决冲突：保留用户 B 前两行，下方 1 内容无差异"
git push origin master

扩展

Git 的智能合并

Git 保障合并操作安全的核心前提是合并双方拥有共同的提交基线（相同起点）。若本地分支与远程分支的基线不一致（本地落后于远程），Git 会要求先执行 git pull 同步远程最新内容，再进行本地提交和推送，这一机制能从根本上避免本地修改覆盖远程最新提交记录的风险。

需要注意的是，分支基线的同步状态依赖 Git 对提交历史的追踪：执行 git pull 后，本地分支的提交基线会与远程仓库保持一致；而本地执行 git commit 后，Git 会更新本地分支的提交历史记录，形成新的基线状态。

Git 的管理边界

Git 支持纯文本文件，可以实现冲突检测功能，但以 TSV 结构化文本为例，Git 能识别并标记文件中发生修改的行，但无法感知行内列级别的数值变化，需手动定位和解决列级差异。

同时经过测试，图像、exe 等二进制文件也可使用 Git 进行管理，但 Git 无法检测具体变化，每次更新只能全部覆盖，对二进制文件的管理效率低，开销大。

存储问题

Git 记录提交状态并可以随时恢复的功能十分强大，但保存如此多的状态是否可能导致存储压力过大。

我修改了一个 17 字节的文件，但 .git 文件夹内却有 17KB 的内容，那 100MB 的文件修改 10 次，其保存的状态文件会不会是 1000MB 呢？

这是不会发生的，Git 底层只存储变化的内容，无变化的内容复用，具体原因为：

1. 文本文件复用：Git 记录行级别差异，修改一行数据，只存储该行的修改记录加少量元数据。
2. 二进制文件压缩快照：根据哈希值判断是否修改，Git 无法识别二进制文件的具体差异，Git 会存储变化文件的压缩快照，这也是为什么使用 Git 管理二进制文件较为低效。

此外 Git 还有垃圾回收机制，和专门针对大文件的管理程序 git lfs。