Git开发 - 技术栈

在现实中，当我们完成一个文档的初稿后，后面可能还需要对初稿进行反复修改，从而形成不同版本的文档。显然，经过反复修改，当我们发现前面某个版本的文档才是最符合预期的时候，如果我们是直接在原稿的基础上不停修改，我们是很难直接得到那个最符合预期的版本的，因此我们的做法是：每次修改得到一个新版本后，我们就将该版本保存下来，下次如果需要修改，先将该版本备份再修改。但这样又出现了另一个问题：如果版本很多，维护起来就十分困难，例如很难知道每一个版本做出了什么变化，为了解决这些问题，于是人们开发出了一系列的名为版本控制器的软件，它们可以很好地管理文档的每次修改以及版本的迭代，方便我们快速溯源某个特定的版本，而Git就是目前最主流的版本控制器，它可以管理维护所有格式的文件，对于开发者来说，它最主要用于管理维护项目中的各种代码源文件（它会清楚地记录文本文件的哪一行新增修改了什么内容，对于二进制文件如图片视频它也会记录它们大小的变化）。

Linux下Git安装

①查看是否已经安装Git

cpp 复制代码

git --version

②查看当前的Linux发行版本

cpp 复制代码

cat /etc/os-release

③Centos下Git安装与卸载

cpp 复制代码

sudo yum intstall git -y //安装
sudo yum remove git -y //卸载

④Ubuntu下Git安装与卸载

cpp 复制代码

sudo apt-get intstall git -y //安装
sudo apt-get remove git -y //卸载

Git基本指令

1.创建本地仓库

cpp 复制代码

git init

该指令用于在当前目录下的创建一个git仓库，只有在git仓库中的文件才可以被追踪管理，创建成功之后会在当前目录下生成一个隐藏的.git文件，该文件Git用于对仓库进行管理的，我们不要随意更改它，否则会破环仓库。

2.为当前仓库配置用户的名称和邮箱

cpp 复制代码

git config [--global] user.name "用户名"
git config [--global] user.email "用户邮箱"

后续仓库的管理可能需要用户的名称、邮箱，如果不进行配置可能会出错，其中 --global 是可选项。我们的配置文件分为全局的配置文件（~/.gitconfig）和本地的配置文件（.git/config），仓库管理时优先使用本地的配置文件的配置信息，如果找不到本地配置文件的配置信息，就会到全局配置文件中寻找需要的配置信息，如果也找不到就会出错或者要求用户提供相关信息。加上 --global 选项就是对全局配置文件的信息进行配置，否则就只是对当前仓库的本地配置文件进行配置。

除了全局配置外，还有系统配置文件（/etc/gitconfig），它的优先级是最低的，使用时加上 --system 选项即可，可能需要sudo 提权。总结就是：本地配置仅适用于当前仓库，优先级最高。全局配置适用于当前用户的所有 Git 仓库，优先级次于本地配置。系统配置适用于整个系统的所有用户和所有仓库，优先级最低。

3.查看配置是否生效

cpp 复制代码

git config -l //查看所有配置

git config --local --list //查看本地配置

git config --global --list //查看全局配置

git config --system --list //查看系统配置

git config -l 命令会列出所有配置项，包括系统级、全局级和本地级的配置，它会按优先级顺序列出所有配置项，不会区分来源（系统、全局或本地），例如本地和全局都配置了用户名信息，优先输出优先级更高的本地的用户名配置信息。

4.重置配置

如果用户的配置信息出错了，可以重置配置信息

cpp 复制代码

git config [--global] --unset user.name	//删除配置的用户名
git config [--global] --unset user.email //删除配置的用户邮箱

加上 --global 选项删除的是全局配置文件的位置信息。

我们前面 git init 的目录不是所谓的git仓库，它仅仅只是一个工作区，真正的git仓库是 .git 目录，也被称为版本库（版本库虽然在工作区所在目录下，但它不属于工作区），只有将工作区的文档添加到版本库中才可以对版本进行管理（注意我们不能直接将文档添加到版本库中，我们只需要将文档放入工作区，再使用add指令将其加入版本库即可）

在版本库中还存在一个git对象库，每一次我们修改工作区文档进行一次add之后，就会生成一个Blob 对象（如果有多个文件发生了修改，就会生成多个Blob 对象），它记录了本次的修改，由git对象库管理这些对象，于此同时我们的暂存区也会新增一个指针指向新增的Blob 对象。如果我们又进行commit操作，就会将暂存区的索引加入到分支当中并清除暂存区内容，并生成Tree 对象和Commit 对象（Tree 对象存储目录结构和文件引用。Commit 对象存储提交信息和树引用），此时工作区的文档就真正地提交到了本地仓库中，形成了一个新版本，可以进行版本管理了（通过HEAD指针就可以找到一个个版本，我们打开.git文件看到的index、objects、HEAD、refs/heads/master文件就分别对应暂存区、git对象库、HEAD指针、分支），HEAD指针指向最新一次commit的commit对象ID。

5.将工作区文件添加到暂存区中

cpp 复制代码

git add "xxx" //将xxx文件添加到暂存区中

git add .	//将工作区下所有文件添加到暂存区中

暂存区的意义是允许我们在提交之前对更改进行组织和选择，确保只提交我们需要的更改

6.将暂存区内容提交到本地仓库

cpp 复制代码

git commit -m "本次提交细节"

每次 git commit 创建一个版本

7.查看当前仓库的提交日志

cpp 复制代码

git log [--oneline] [--graph]

--oneline：以单行格式显示每个提交，便于快速浏览。

--graph：以图形化的方式显示提交历史，包括分支和合并。

按 q 退出日志浏览

所有对象（Blob、Tree、Commit）都存储在 .git/objects 目录下，git 对象 ID 的前两位是子目录名，剩余部分是文件名。在 git log 时日志中我们会看到一串串的长字符串，这就是 Commit 对象的ID（路径）.

我们可以通过git对象ID查看对应 git 对象的信息：

cpp 复制代码

git cat-file -p "git对象ID"

如果该git对象ID是指向 Blob 对象：我们可以查看到对应文件的修改信息

如果该git对象ID是指向 Commit 对象：我们可以查看到 commit 时的提交细节

如果该git对象ID是指向 Tree 对象：我们可以查看到 commit 时所有add操作生成的Blob 对象ID及对应文件名

8.查看工作区和暂存区状态

cpp 复制代码

git status

可以查看到哪些文件被修改、哪些文件被暂存（添加到暂存区）以及哪些文件未被版本控制，一般会显示以下内容

常用输出信息：

On branch [branch_name]：显示当前所在的分支。
Changes not staged for commit：显示工作区已修改但尚未暂存的文件。
Changes to be committed：显示已暂存的文件。
Untracked files：显示未被 Git 跟踪的文件。

9.比较文件差异

可以比较工作目录与暂存区之间的差异、暂存区与最新提交之间的差异，或者两个特定提交之间的差异。

cpp 复制代码

git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异

git diff HEAD -- [file] 命令来查看版本库和⼯作区⽂件的区别。

10.版本回退

cpp 复制代码

git reset [--soft | --mixed | --hard] [HEAD]

--soft 参数只是将版本库回退到某个指定版本，对于工作区和暂存区的内容都不变。
--mixed 为默认选项，该参数将版本库和暂存区的内容退回为指定版本，工作区文件内容保持不变。
--hard 参数将版本库、暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个选项，因为一旦工作区会回滚，我们没有提交的代码就再也找不回了，所以这个选项要慎用。

HEAD 说明：

①使用^表示
- HEAD 表当前版本
- HEAD^ 上⼀个版本
- HEAD^^ 上上⼀个版本
- 以此类推...
②使用 ~ 数字表示：
- HEAD~0 表示当前版本
- HEAD~1 上⼀个版本
- HEAD^2 上上⼀个版本
- 以此类推...

当然我们也可以直接使用commit对象的ID来替代HEAD，理论上只要我们得到了commit对象的ID，我们就可以返回到该版本上（意味着我们在退回以前的版本后，又可以退回来特定的版本），如果我们不知道某个版本的commit对象ID，可以使用以下指令查到：

cpp 复制代码

git reflog

但这种办法不是万能的，当版本过多时以前版本的commit对象ID该指令未必可以查到，因此还是要慎用 --hard选项。

Git 的提交历史是一个有向无环图（DAG），每个提交都有一个唯一的 commit ID，我们的版本回退只是将HEAD指针指向commit对象ID对应的顶点而已（例如如果我们从版本10回退到版本3，又提交新增到版本4，我们还可以通过commit ID回退到版本7（版本3顶点有2条出边，即两条分支，一条指向原来的版本4即maser主分支，一条指向现在的版本4但该分支无名字是孤立的分支，而HEAD指针就指向该孤立分支末尾，如果不回退，我们后面新增的版本都会添加到新增的版本4后面，但我们一旦切回master主分支，HEAD指针就会重新指向master主分支最新版本即版本10，由于新增分支是孤立分支没有名字，我们很难让HEAD指针再次切换回新增的版本4，尽管可以通过拿到新增版本4的Commit ID回退，但当版本很多时这种办法不实用））。

11.命令简化

一些命令的可能会比较长使用起来不方便，我们可以对命令起别名以提高效率

cpp 复制代码

git config --global alias.last 'log -1'
//将命令git log -1简化成 git last

建议初学时不要进行命令简化。

分支管理

我们前面的每一次提交都会被都会像一条时间线一样被串起来，这条分支就是master分支，即主分支，我们还可以基于某个提交点创建其它分支，让分支完成特定任务之后再合并会主分支。

1.查看当前所有分支

cpp 复制代码

git branch		//显示所有本地分支

git branch -a	//查看所有分支包括本地分支和远程分支

带 * 的分支就是 HEAD 指向的分支

2.创建分支

cpp 复制代码

git branch dev //新建分⽀dev

在当前分支（ HEAD 指向的分支，通常是 master 或其他分支）的最新提交点上创建一个新的分支 dev，初始时新建分支的工作区、暂存区和版本区与当前分支的最新提交状态是完全一致的，如果当前分支的工作区有未提交的内容分支也会复刻，这样容易导致后面合并时出现问题，因此在分支时应该保证工作区、暂存区是干净的。

如果需要可以使用 git stash 命令临时保存当前工作目录中的更改（包括已修改但未提交的文件、已暂存的文件等），同时将这些更改从工作目录中移除，使工作目录恢复到一个干净的状态（与最近一次提交的状态一致）。这在需要切换分支、解决紧急问题或执行其他需要干净工作目录的操作时非常有用，如果没有添加到暂存区文件是无法保存的。

3.切换分支

cpp 复制代码

git checkout dev//切换到分支dev上

git checkout -b dev //创建并切换到dev分支

我们在某个分支的修改是不影响其它分支的，例如我们在dev分支上进行了修改，当切回master主分支时工作区、暂存区和版本区就会更新为master分支的最新状态（工作区和暂存区未提交的内容在切换分支后仍然会保留）。

4.合并分支

存在两种模式的合并：

①快进合并（Fast-Forward）

cpp 复制代码

git merge [--ff] dev //将dev分支合并到当前分支

只有在创建分支 dev 之后，当前分支没有任何新的提交，才可以进行快进合并，其实就是将 master 和 HEAD 指针指向 dev 的最新提交点，所以合并速度非常快。

在进行快进合并时当前分支的工作区和暂存区不应有未提交的内容，应该保持和创建dev分支时一致，否则可能快速合并失败。

快进合并是默认的合并模式，因此 --ff 选项可以省略

②非快进合并（No Fast-Forward）

会强制创建一个合并提交

cpp 复制代码

git merge --no-ff -m "提交细节" dev将dev分支合并到当前分支并进行一次提交

如果合并时发生了冲突，就必须采用 No Fast-Forward 的方式合并，合并时产生冲突可能是以下原因：

如果两个分支对文件的同一行或相邻行进行了修改，Git 无法自动决定保留哪个版本，此时会标记为冲突（如果两个分支修改的是文件的不同部分，Git 可以自动合并，不会冲突。如果一个分支修改了文件，而另一个分支没有修改，合并时也不会冲突）
如果一个分支删除了文件，而另一个分支修改了该文件，合并时也会冲突

当合并发生冲突时，Git会标记发生冲突的内容，类似于下面这样：

cpp 复制代码

<<<<<<< HEAD
当前分支冲突内容
=======
分支的冲突内容
>>>>>>> dev

我们只能手动调整发生冲突的内容来解决冲突，解决完冲突之后重新进行提交操作形成一个新的提交点之后在进行非快进合并操作。

快进模式模式合并时速度虽然快，但在未来溯源时我们不知道合并的点有没有分支的参与，而非快进模式就很好的记录了合并的点有哪几个分支的参与，因此如果分支是由不同的人员完成的，这里推荐使用非快进模式进行合并一方便未来溯源。

5.删除分支

cpp 复制代码

git branch -d dev	//删除分支dev
git branch -D dev	//强制删除分支dev

分支在合并后就可以删除了避免资源占用，分支的提交记录会永久保留在主分支中，即使分支被删除，其所有更改仍可通过主分支的提交历史追溯。

在当前分支上只能删除另一个分支，不能在当前分支上删除当前分支，如果某个分支没有进行合并操作，只能使用强制删除。

因为创建、合并和删除分支非常快，所以Git鼓励我们先使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作的效果是一样的，但过程更安全。

在实际开发过程中，要求master分支上的代码是稳定可靠的，因为已经开发的产品会直接依赖于master分支上的代码，如果我们想要添加新的功能，就只能从maser上拉取一个分支，在分支上完成新功能的开发，经过测试确保稳定可靠后再合并到master分支上，从而确保master分支上的代码是稳定可靠的。

如果master分支的代码出现了问题，而现在的分支 dev1 是基于存在问题的代码开发的，此时我们需要新开一个分支 dev2 解决master 分支上的问题，解决完后将dev2 合并到master分支中，再将master合并到dev1 上进行冲突解决，最后将dev1 合并到master分支上。

远程仓库与本地仓库

我们前面所讲的都是本地仓库，如果想要实现多人协作，仅仅只有一个本地仓库是不行的，因此每个成员的电脑上都有一个自己的本地仓库，成员基于自己的本地仓库完成开发后将最新提交推送到其它成员的电脑上，这样所有人都可以看到其他成员的修改，但这种方法管理麻烦安全性不高，因此我们使用一个中央服务器管理所有代码，当要开发新功能时成员从中央服务器拉取代码进行开发，开发完成确定没有问题之后再推送到中央服务器，这样就能保证中央服务器的代码就是稳定可靠的代码，其他成员也可以通过中央服务器的最新提交看到其他成员的修改。

像上面所说的中央服务器我们完全可以自己搭建，不过也有现成的网站可以供我们直接使用，GitHub 就是用于提供 Git 仓库托管服务的，只要注册⼀个GitHub账号，就可以免费获得 Git 远程仓库，由于 GitHub 是国外的网站，速度比较慢，我们一般使用码云

一般一个仓库管理一个项目系统，码云的一般操作有：仓库创建、设置仓库介绍文档(README)、仓库成员管理及其身份设定、仓库代码问题反馈及处理、分支合并（要申请）

1.将远程仓库克隆到本地

cpp 复制代码

git clone [仓库克隆地址]

执行该命令就可以将远程仓库克隆到本地当前工作目录下，这时的仓库与我们前面所说的本地仓库没有任何区别，需要注意当前工作目录不能在本地仓库里面。