前言

本次笔记环境是在CentOS/Linux、Windows+IDEA环境下编写，Git版本选用2.44.0。

由于在日常的开发环境中经常使用Git，本次笔记的主要目的在于提供Git的认识、Git工作流详解与Git命令的学习，希望可以带给大家一些新的知识或是日常操作的帮助。

笔记基于《Git奇技淫巧》、《Pro Git》（这本书强烈推荐，因为Git官网就是它！）以及各类博客网站的很多博主所总结的一些Git技巧，作者也会在最后总结一份较为完整的Git命令大全用于大家日常使用。大家日常只需要使用标红的命令内容即可（因为命令太多了，且很多基本是不用的）。

最后希望大家多多关注鲸鱼的笔记，希望给大家的工作和日常学习带来帮助！！谢谢！

Git简介

Git是什么

Git（分布式版本控制系统），是目前适用范围最广也最为先进的版本控制系统（管理代码文件的仓库），在Git之前还有诸如CVS、SVN、SubVersion等集中式版本控制系统。

Git的发展史

Git诞生于2005年，其创始者是Linux的创始人Linux，在没有VCS前，代码合并基本靠手工合并，也就是将diff提交至一个代码管理者手中，代码管理者通过手动修改代码diff实现修改合并，这样的问题会大大影响团队开发效率（因为不得不有一个人要充当管理版本的）。

在2002年，Linux由于底层庞大的代码库引入BitKeeper，这是一个商业版本的VCS，在一开始BitKeeper保持免费提供服务支持，为Linux免费提供服务。后续BitKeeper收回了Linux社区的免费使用权，衍生了Git的诞生。后续Linus基于C语言，开发了第一个版本的Git，之后Git迅速成为主流分布式版本控制系统，并完全免费。

什么叫做版本控制

版本控制，言简意赅，针对一个文件的不同版本，进行类似快照的存储并支持版本变动。这样做有什么好处呢？

比如：针对同一个文件，如果你想要获取其以往版本的信息，如果是在常见的Windows系统下，就需要使用另存为（每一次备份，都去另存为一次，就会导致出现了很多冗余文件），而且，如果同一文档有多人修改，还需要考虑，谁修改了那些，如何合并这些修改，是不是想想就很困难。这时候，我们就需要使用VCS实现版本控制。VCS的主要目的是用于解决在文件书写过程中，可以记录保存点（快照），并记录修改人等信息，从而实现查看文件变化细节、谁修改的等信息，同时VCS支持文件回滚，也就是在版本变化过程中，如果出现了重大文件变化，可以使用回滚来将文件恢复到原来的样子。

分布式版本控制系统

DVCS，支持一台Server Computer与多台本地机器实现文件交互，并能够记录每台计算机的操作记录并生成唯一的版本id，在每个本地机器上存储的文件是相同的，但在显示时只显示diff文件。

分布式版本控制系统成为目前的主流VCS，因为DVCS更适合于团队协作类型的项目开发，同步开发过程中可以并行。

Git发展

Git在BitKeeper的基础上完善了：

1. 速度
2. 设计
3. 非线性开发的强力支持（也就是对于同一项目的多版本、多开发人员的并行开发支持）
4. 完全分布式
5. 具备管理超大项目的使用历程（Linux）

同时，由于Git的非线性分支管理系统，同时速度极快，因此非常适合管理大项目。

Git基础

如果已经看完了上述内容，相信大家对于Git已经了解了其出现的原因，解决什么问题，为什么生态与用户庞大等诸多原因。接下来，让我们来继续深入Git管理，看一看其内部是如何工作的：

Git直接记录快照，并非比较文件差异

Git与其他VCS的区别在于Git对待文件系统数据的方式是不同的（直接记录整个版本快照），类似CVS、SubVersion等系统，其保存的信息可以看做是一组基本文件随着时间变化逐步累计的差异信息的组合；而Git则是针对每一个版本，存储当前时间，当前文件版本信息的一组快照，针对未修改的文件，Git使用指针链接未修改的文件（这里可以理解为Git存储的是每一个版本的快照流，包括：差异变化文件-->指针指向的未修改文件）。

接下来我们使用一个存储模型来帮助大家更好地理解Git存储方式：

上图为Git的存储方式，我们可以看到，对于一个版本的修改（A1、B1等属于修改文件），Git存储的并非只有差异文件，而是将当前版本的一整组数据的快照文件都（A1 + B + C1）存储下来了，更像是将Git所管理的文件作为一组文件存储。这也使得Git对于分支的支持更好，后续在分支——Branch中，也会继续探讨当前方式对于数据存储与获取的益处。

本地操作，本地执行的分布式管理工具

Git将文件、操作记录以及文件变更记录都存储于本地计算机中，在本地的被管理文件中就可以直接看到Git的提交历史、版本变更记录、变更文件等信息，同时允许本地与远程仓库进行差异比较。这样的设计保证了即使在无网络连接或是VPN时，都可以在本地直接修改代码，然后Commit到本地仓库中保存自己的修改，后续通过Push或是Merge操作来将本地已经修改的代码文件推送至远程服务器。这也是Git分布式的体现，在集中式版本控制工具中，必须要先连接服务器才可以进行文件操作或者是可进行文件操作但无法提交修改。

Git的存储完整性

Git通过hash计算数据存储前的校验和，保证了文件的修改对Git来说，是公开透明的，即使文件传输过程中丢失或是损坏，Git也可以及时发现。 计算方式：Git基于SHA-1散列方式，计算hash，得出一个由40个16进制字符所组成的唯一字符串，也就是我们所说的索引。同时，在Git中，文件的修改是以整行计算的，我们通过平时使用就可以看出，当我们修改了一行代码中的几个位置时，Git的提交记录会显示：删除了一行、添加了一行。同时Git支持RollBack，通过记录索引，改变Head指针所指向的索引即可完成。

Git的三种状态

1. 工作目录（Working Directory）：本地文件区域，可进行修改的区域，在Git中，已修改但未commit的代码就存储在当前区域。
2. 暂存区（Stash Area）：本地临时文件区域，也可以叫做索引库。暂存区存储的是每个版本的不同文件系统，暂存区保存了下次将要提交的信息（这里和commit提交所存储的还不太一样，commit的内容会进入本地仓库，是针对仓库的操作，而暂存区则只是针对文件的存储，方便我们进行下次commit）。
3. 仓库（Repository）：可以理解为我们存储共同协作代码的位置，是存储元数据与对象数据库的地方，我们的提交等操作都是针对仓库进行的。

工作流程如下：

1. 在工作目录中修改文件
2. 暂存文件，将文件快照放入暂存区
3. 提交保存更新，找到暂存区的文件并将其快照永久记录在git的仓库中

Git入门

安装（这里直接跳过了，傻瓜式安装即可），如果有伙伴需要，后续会补充修改此部分内容

git-配置

 git config

配置优先级：

1. /etc/gitconfig文件：包含系统上的每一个用户及仓库的通用配置。可以使用带有--system的命令选项实现git config命令时，会从此文件读取配置变量。
2. ~/.gitconfig或者是~/.configgit/config文件：针对当前用户。使用带有--global命令选项执行git config命令时，git读写此文件。
3. 当前仓库Git目录中的config文件：只针对该仓库的配置信息。

优先级从下至上，越是限制范围低的配置优先级越高。

用户信息的配置：

 git config --global user.name "your name"
 git config --global user.email "yuor email"

如果只想针对某个仓库进行配置：

 git config user.name "your name"
 git config user.email "your email"

查看Git配置信息

 git config --list

此命令会检查你的配置并列出所有Git当时可以找到的配置信息（该命令下可能会出现重复的配置，因为执行该命令Git会扫描所有可发现的配置文件信息并返回。）

获取指定的配置信息

 git config <key>
 ​
 such as:
 git config user.name  #查看用户名称配置

获取帮助

 git help config  # 获取config命令执行手册
 git help <verb>
 git <verb> --help
 git help <verb>

git-操作

接下来就是使用Git时的常用操作，包括了：初始化仓库、开始或停止跟踪文件、暂存、提交更改、推送等。

初始化Git仓库

 git init

该命令会在当前执行命令文件夹下创建一个名为.git的子目录，该目录下包含了Git仓库的所有必须文件。

以上展示的文件是Git管理仓库的骨干文件，包括了Head、Index等用于Git记录版本指向指针信息的文件。

初始化之后，当前仓库下的文件还并未交于Git跟踪管理，如果想要将文件交于Git管理，则还需要一些指令操作。

 git add *.C #  将后缀为.c的所有文件添加到Git的暂存区
 git add LICESE #  补充添加文件到暂存区
 git commit -m "commit message" #  Git提交代码到本地仓库，提交信息必填

持续更新中......