so easy，一文拿下Git！

0、引言

Git? GitHub? Gitee？

我们所熟知的是GitHub和Gitee都是代码托管平台，他们前缀都是以Git开头，那么Git是什么？

在下面的文章中，我们将会详细介绍Git的基本概念，优势，如何安装并与远程仓库(GitHub、Gitee)如何建立连接，Git的工作原理及多用户协同开发、分支管理等。

1、基本概念

上面说到了GitHub和Gitee是代码托管平台，事实上Git是一个开源的分布式版本控制系统，它可以敏捷高效地处理任何或小或大的项目。为了更加方便的管理项目，通常会将项目放在GitHub或者Gitee上供用户下载、提交和维护，这两类托管平台通常存放的是开源项目；而公司级的项目通常存在在Gitlab上。

但是不管怎么样，它们的功能基本上都是一样的。

对上述不理解，没关系，我们的Git学习还没开始呢，必让你学会！

我们详细拆解下："Git是一个开源的分布式版本控制系统"这句话。

• 版本控制系统是什么？

• 既然分布式，它和传统的集中式有什么区别？

1.1 版本控制系统

我们以一个小故事开头：

大家在工作之前都有过被毕业论文折磨的经历，为了达到老师对我们的期待，我们把论文修改了一遍又一遍，随着论文修改版本的不断迭代，我们很难记得每一个版本的论文修改了那些内容，如若老师突然想让我们提交某一版本的论文，我们就需要一个个查询论文的内容，这对于我们来说是非常困难的。

而版本控制系统可以有效的帮我们解决上述遇到的问题，它的主要作用就是帮助我们保留项目中的详细的历史记录（比如你对项目的内容作了那些修改），并且能够在项目的不同的版本上进行工作，根据具体的需求，可以方便我们切换不同的项目阶段。

NOTE：版本控制其实就是控制版本，版本控制系统就是帮助我们控制或管理项目的不同版本。

1.2 集中式VS分布式

（1）集中式

传统的项目管理工具通常采用的是集中式版本控制系统，比如我们常见的SVN，它通常有以下特点：

• 需要中央服务器

集中式版本控制系统需要开发人员从中央服务器获取最新版本的项目然后在本地开发，开发完成后送给中央服务器。因此脱离服务器开发者是几乎无法工作的。

• 网络依赖

必须要联网才能工作，而且对网络的依赖性较强，如果推送的文件比较大而且网络状况欠佳，则提交文件的速度会受到很大的限制。

• 文件存储格式

按照原始文件存储，体积过大

• 分支操作

创建新的分支则所有的人都会拥有和你一样的分支，而且提交的文件会直接记录到重要版本库

（2）分布式

• 中央服务器

分布式最大的特点就是没有中央服务器，每位开发人员都各自维护着自己的开发版本，需要协同开发同一个项目时只需要互相推送、交换即可，但是为了方便代码的管理，开发人员的提交、维护等操作，通常会将代码提交到代码托管平台(Gitee、GitHub、Gitlab)。

• 网络依赖性

分布式在没有网络的情况下也可以执行commit、查看版本提交记录、以及分支操作，在有网络的情况下执行 push 到 Remote Repository。

• 存储体积小

按照原数据方式存储，体积很小

• 分支操作

分支操作不会影响其他开发人员，提交的是本地操作，需要push操作才会到主要版本库。

2、安装Git

Git可以直接从官网下载，然后按默认选项安装即可，安装完成后，安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！

安装完成后，还需要设置用户名，和用户邮箱。

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

--global命令表示在本机的所有Git仓库中，都使用该用户名的信息。

有的同学可能会有疑问，为什么要设置用户名和邮箱呢？

这是因为Git是分布式版本控制系统，所有参与到项目中的机器都会被记录到花名册中，方便查询。

3、本地仓库和远程仓库

3.1 本地仓库

安装好Git后，就可以在自己的电脑上构建一个本地仓库。

本地仓库可以认为是一个目录，该目录下的所有文件都可以被Git管理起来。

• Linux系统

在Linux系统中，选择好目录，然后进行初始化即可

$ mkdir simon
$ cd simon
$ git init

• Windows

大部分小伙伴使用的应该都是Windows系统，在Windows中构建的方式会更简单，只需要选择一个不带中文的目录，然后使用Git Bash执行git init即可。

构建完成的仓库一般都带有.git的目录，如果没有看到，可能是工具栏-->查看，看一下是否打开了隐藏的项目。

3.2 远程仓库

因为Git是一个开源的分布式版本控制系统，同一个Git仓库可以分布在不同的机器上，为了便于多用户的协同开发，提高用户间代码的交换、查看的效率。因此，我们可以找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也可以从服务器仓库中拉取别人的提交。

事实上，我们大可不必这么折腾，因为网上有几个不错的代码托管平台（如GitHub、Gitee和Gitlab），这几个网站可以很有效的提供Git仓库的托管服务，只要你注册对应网站的账号，你就可以免费的使用。

有了远程仓库，我们就可以把本地仓库的代码上传至远程仓库，别的小伙伴就可以及时看到我们的代码了

本地仓库和GitHub仓库之间的传输有两种方式。

（1）SSH加密传输

SSH是一种网络协议，可以用于计算机与服务器之间的加密传输，当一台本地计算机使用SSH协议向服务器传输数据时，即使中途被截获，传输的内容也不会泄漏。

它采用的是公钥和私钥做验证，因此，为了保证本地计算机能够安全的访问远程服务器，我们需要以下操作。

• 创建SSH Key

在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

设置后，可以在用户的主目录里找到.ssh目录，该目录里有id_rsa和id_rsa.pub两个文件，这两个就是SSH key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

• 添加SSH Key

登录GitHub或者Gitee，找到SSH Keys页面，将id_rsa.pub中的内容添加进去即可。

创建一个新的远程仓库，这个仓库可以与已有的本地仓库相关联

$ git remote add origin git@github.com:simon/learngit.git

添加后，远程仓库的默认名字是origin,

然后把本地仓库的内容推送给GitHub/Gitee仓库

$ git push origin master

git push是把本地仓库的内容推送到远程中的master分支。

（2）https传输

https传输，它使用的是443端口，可以根据仓库的权限进行读写，只要有账号密码就可进行操作。复制https形式的仓库地址到git Bash里面，然后直接用clone命令克隆到本地就好了。

但是它每次fetch和push代码都需要输入账号和密码，这也是https方式的麻烦之处。

NOTE：相较于https形式的免秘钥，我还是更喜欢SSH传输的方式，它仅需要SSH Keys授权，这个key是通过ssh key生成器生成的，然后放在github上，作为授权的证据，这样的话就不需要用户名和密码进行授权了，使用起来非常的方便。

4、工作区与暂存区

我们在开发项目时，用的的最多的命令也就是这3个：

• git add
• git commit
• git push

以前的我认为git add是保存自己所写的代码，git commit是为自己这次所写的代码进行注释，git push后，就可以成功的把我们所写的代码提交到远程仓库了。然后，就没然后了，事实上，当时的我并不了解每个命令背后的原理，我仅仅会使用，理解表面的意思而已。

但是作为每天都想博学一点点的小青年，我想把这件事和大家捋清楚。

现在，我们从Git的分区开始。

4.1 Git分区

事实上，在我们使用Git时，Git通常分为两大模块：工作区、版本库。

• 工作区

工作区就是我们本机上的Git项目的目录，即我们保存项目文件的目录。

• 版本库

在工作区中有一个隐藏的目录.git，这个不算是工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的是称为stage的暂存区。

还有Git为我们自动创建的分支master，以及指向master的一个指针HEAD，我们通常称之为本地版本库。

因此，我们先简单画一张图，理解工作区、暂存区和本地版本库之间的关系。

下面，我们以操作具体文件的形式分析每个分区的变化。

4.2 文件操作

文件从我们创建、编辑、提交等操作，Git都会帮我们记录，一共要经历3种状态：已修改（modified）、 已暂存（staged）、已提交（committed）。

• 刚刚开始时编辑文件，这个时候文件是处于 已修改（modified） 状态，文件是在工作区
• 修改完文件，我们执行git add，这个时候文件就变为 已暂存（staged）状态，文件信息进入暂存区，内容被保存到Git数据库中
• 然后我们执行git commit，文件就变为已提交（committed）状态，创建了一个提交记录保存到了本地版本库

最后当使用git push后，本地文件就会被上传到远程仓库。

有的小伙伴可能会有疑问，既然文件从编写到提交有那么多步骤，如果我的文件在其中的某一步出错了，我该如何补救呢？

通常情况下，我们的操作分为以下几种情况：

（1）对文件git add后，我又修改了这个文件，我需不需要先对第一次的文件git commit，然后在对第二次的文件执行正确的流程？

不需要，因为我们第一次对原始文件git add，该文件就被保存在暂存区了，这时我们可以对修改后的文件继续git add，然后使用git commit，将两次的操作一块提交到本地版本库。

因此，正确的操作流程应该是：第一次修改 -> git add -> 第二次修改 -> git commit

（2）对文件git add后，发现文件有问题，这时候该咋办？

当git add后，此时的文件已经在暂存区，你想重新修改，有两种办法可以帮助到你

• 重新对文件的原有内容进行修改，修改正确后git add，当第一次修改的位置和第二次修改位置相同时，git commit就是第二次的
• 使用命令git reset HEAD，就可以撤销暂存区的文件了。

（3）对文件git commit后，发现文件有问题，该怎么办

这种情况下你可以使用命令git log查询自己文件每次修改后提交的版本，然后使用命令git reset --hard 版本号回退到上一个版本即可。

若git push提交到远程仓库才发现有问题，没得商量，你的文件会被所有人看到。

（4）将文件从本地仓库的目录删除后，在.git还会存在吗？

会存在的，当我们输入git status，它会告诉我们那些文件被删除了，你如果想从版本库中删除该文件，可以使用git rm命令。

5、分支管理

分支管理？什么是分支管理？

分支管理就是使用多条分支线同时推进多个任务。

在实际的项目开发中，代码分支的的管理策略有很多种，通常情况下，常分为以下5种

• 主分支 master

提供用户使用的正式版本

• 开发分支 develop

功能最全的分支，日常开发使用的分支

• 功能分支 feature-x

开发新功能

• 预发布版本 release-s

发布定期要上线的版本

• 修复分支 hotfix-x

修复线上代码的bug

5.1 主分支master

任何代码库应该有且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。Git主分支的名字默认叫做master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

5.2 开发分支develop

日常应该在另一条分支上完成，我们把开发用的分支叫做develop分支。开发分支(develop)应该总能够获得最新开发进展的代码。如果想正式对外发布，就在master分支上，对develop分支进行merge。

常用的命令如下：

# 在master分支上创建develop分支
git checkout -b develop master

# 切换到master分支
git checkout master

# 对develop分支合并到当前master分支
git merge --no-ff develop

NOTE：

除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

• 功能（feature）分支
• 预发布（release）分支
• 修补bug（hotfix）分支

这三种分支都属于临时性需要，使用完以后，最好删除，使得代码库的常设分支始终只有master和develop。

5.3 功能分支

feature分支是为了开发某种特定功能，从develop分支上面分出来的。开发完成后，要并入develop。功能分支的名字，可以采用feature-xxx的形式命名。

# 从develop创建一个功能分支
git checkout -b feature-x develop

# 开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x

# 删除feature分支
git branch -d feature-x

5.4 预发布分支

release分支是指发布正式版本之前（即合并到master分支之前），我们可能需要有一个预发布的版本进行测试，它从develop创建的分支。预发布结束以后，必须合并进develop和master分支。它的命名，可以采用release-xxx的形式。

# 创建一个预发布分支
git checkout -b release-x develop

# 确认没有问题后，合并到master分支
git checkout master
git merge --no-ff release-x

# 对合并生成的新节点，做一个标签
git tag -a 1.2

# 再合并到develop分支
git checkout develop
git merge --no-ff release-x

# 最后，删除预发布分支
git branch -d release-x

5.5 bug修补分支

软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从master分支上面分出来的。修补结束以后，再合并进master和develop分支。它的命名，可以采用hotfix-x的形式。

# 创建一个修补bug分支
git checkout -b hotfix-x master

# 修补结束后，合并到master分支
git checkout master
git merge --no-ff hotfix-x
git tag -a 0.1

# 再合并到develop分支
git checkout develop
git merge --no-ff hotfix-x

# 删除"修补bug分支"
git branch -d hotfix-x

6、Git指令大全

本来我想一个个把指令写上去，我发现git指令太TM多了。

因此，我做了个脑图，这个脑图基本包含了git常用的所有指令，想要这份脑图的同学可以在公众号内回复git。

好了，今天的文章就结束了，我是simon郎，一个想要每天博学一点点的小青年，期待您的关注，我们下篇文章见！

巨人的肩旁