分布式文件管理系统 Git

---

1 Git简介

1.1 Git概述

• Git是什么？
  • Git是目前世界上最先进的分布式版本控制系统（没有之一）。
• 哪些GIT网站？
  • 全球最大的开源项目网站。https://github.com/
  • 中国最大的开源项目网站。https://gitee.com/

1.2 Git的诞生

1991年创建的 Linux 服务器系统软件初期主要靠全世界的志愿者参与壮大，在2002年之前，世界各地为Linux编写代码，通过diff的方式将源代码文件发给Linus(Linux创作者)，后由Linus本人通过手工方式合并代码！

为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

到了2002年，Linux系统已经发展了十年，代码库之大让Linus很难继续通过手工方式管理，于是Linus选择了一个商业的版本控制系统BitKeeper，BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

2005年，开发Samba的Andrew试图破解BitKeeper的协议，被BitMover公司发现，于是BitMover公司收回了Linux社区的免费使用权。

于是Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

历史就是这么偶然！

1.3 集中式 & 分布式

Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和 分布式版本控制系统有什么区别呢？

1.3.1 集中式

集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟。

1.3.2 分布式

分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

当然，Git的优势不单是不必联网这么简单，之后我们还能看到Git极其强大的分支管理，把SVN等远远抛在了后面。

CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于CVS自身设计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。

除了免费的外，还有收费的集中式版本控制系统，比如IBM的ClearCase（以前是Rational公司的，被IBM收购了），特点是安装比Windows还大，运行比蜗牛还慢，能用ClearCase的一般是世界500强，他们有个共同的特点是财大气粗，或者人傻钱多。

微软自己也有一个集中式版本控制系统叫VSS，集成在Visual Studio中。由于其反人类的设计，连微软自己都不好意思用了。

分布式版本控制系统除了Git以及促使Git诞生的BitKeeper外，还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点，但最快、最简单也最流行的依然是Git！

1.4 版本控制工具说明

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。

而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

2 Git 安装与设置

2.1 下载

下载链接： https://git-scm.com/downloads

2.2 安装

2.3 设置全局身份

打开 Git Bash

出现以下黑窗口表示安装成功
因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。

$ git config --global user.name "Your Name"

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

3 Git 初始化

3.1 创建版本库

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。所以，创建一个版本库非常简单，首先，选择一个合适的地方，创建一个空目录！

3.2 创建仓库目录

$ mkdir E:/Dev_project/Java/Git/repository

#以上的设置之后相当于在git下创建了一个repository的目录
#接下来我们要把这个目录变成一个版本库

3.3 打开目录

cd E/Dev_project/Java/Git/repository

3.4 初始化版本库

$ git init
Initialized empty Git repository in E:/Dev_project/Java/Git/repository/.git

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），仔细观察可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改个个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。

4 添加文件

4.1 相关命令

git add readme.txt      添加一个文件 
git add file2.txt file3.txt   添加多个文件
git commit -m "提交文件的注释信息"   提交文件到版本库
git status   查看当个库的状态
git diff  查看修改的内容

4.2 操作步骤

4.2.1 创建文件

现在我们编写一个readme.txt文件，内容如下：
哎呦，你干嘛;
一定要放到E:\Dev_project\Java\Git\repository目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
把一个文件放到Git仓库只需要两步。

1. 4.2.2 用命令git add告诉Git，把文件添加到暂存区(staged)

$ git add readme.txt
执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

2. 4.2.3 用命令git commit告诉Git，把文件提交到仓库

$ git commit -m "创建一个新文件"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 1 insertions(+)
 create mode 100644 readme.txt

简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会提示，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；21insertions：插入了一行内容（readme.txt有一行内容）。

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

4.2.2 修改文件再查看

我们已经成功地添加并提交了一个readme.txt文件，现在，是时候继续工作了，于是，我们继续修改readme.txt文件，改成如下内容：
哎呦，你干嘛;
只因，你太美;
现在，运行git status命令看看结果：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

4.2.3 查看修改了什么内容

虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用git diff这个命令看看：

$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index fc1daf6..b603da1 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,2 @@
-哎呦，你干嘛
\ No newline at end of file
+哎呦，你干嘛
+只因，你太美
\ No newline at end of file

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第二行添加了一个 “只因，你太美;”。
知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add：
$ git add readme.txt
同样没有任何输出。在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：
$ git status
On branch master
Changes to be committed:
(use “git reset HEAD …” to unstage)
modified: readme.txt
git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：
$ git commit -m “添加 只因，你太美;”
[master e475afc] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
提交后，我们再用git status命令看看仓库的当前状态：
$ git status
On branch master
nothing to commit, working tree clean
Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。

4.3 小结

添加文件到Git仓库，分两步：
使用命令git add ，注意，可反复多次使用，添加多个文件；
使用命令git commit -m ，完成。
要随时掌握工作区的状态，使用git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容

5 工作区 & 暂存区

5.1 工作区 (Working Directory)

就是repository文件夹内的目录。

5.2 版本库 (Repository)

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

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

分支和HEAD的概念后面讲。
前面讲把文件往Git版本库里添加的时候，是分两步执行的：

1. 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
2. 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为创建Git版本库时，Git自动创建了唯一的一个master分支，所以，现在，git commit就是往master分支上提交更改。

可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
现在，再练习一遍，先对readme.txt做个修改，比如加上一行内容：

哎呦，你干嘛
只因，你太美
唱，跳，rap，篮球，music

然后，在工作区新增一个LICENSE文本文件(内容不限)

先用git status 查看状态

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        LICENSE.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。

现在，使用两次命令git add，把readme.txt和LICENSE.txt都添加后，用git status再查看一下：

Patrick_Star@DESKTOP-I451M6J MINGW64 /e/Dev_project/Java/Git/repository (master)
$ git add readme.txt

Patrick_Star@DESKTOP-I451M6J MINGW64 /e/Dev_project/Java/Git/repository (master)
$ git add LICENSE.txt

Patrick_Star@DESKTOP-I451M6J MINGW64 /e/Dev_project/Java/Git/repository (master)
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   LICENSE.txt
        modified:   readme.txt

现在暂存区的状态变为下图所示：

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

$ git commit -m "添加 唱跳rap篮球music 和 LICENSE.txt"
[master 46cff4f] 添加 唱跳rap篮球music 和 LICENSE.txt
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 LICENSE.txt

一旦提交后，如果没有对工作区做任何修改，那么工作区就是干净的

$ git status
On branch master
nothing to commit, working tree clean

现在版本库变成这样，暂存区没有任何内容

5.3 小结

暂存区是Git非常重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底干了什么。
没弄明白暂存区是怎么回事的，请向上滚动页面，再看一次。

6 版本回退

6.1 准备工作

• 准备一个文件

• 修改三次

• 提交三次

6.2 相关命令

• git log 查看当前分支的版本提交记录
  

• git log --pretty=oneline 一个行显示
  

• git reset --hard HEAD^ 回退到上一个版本
  

• git reset --hard cb5f63 回退到指定的版本号
  

7 撤销修改

7.1 情况1：数据只存在工作区

• git checkout filename.txt 丢弃工作区修改

7.2 情况2：数据使用add添加到暂存区

1. 先从暂存区里面移除相应的文件
   git rm --cache filename.txt

2. 再使用情况1的方式丢弃
   git checkout – filename.txt 丢弃工作区修改

7.3 情况3：数据使用add添加到暂存区并commit到版本库

• 使用上一讲-版本回退的方式

8 删除文件

• 先删除
  git rm -rf filename.txt

• 再提交
  git commit -m “备注”
  

9 创建与合并分支

9.1 相关命令

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

9.1.2 git branch dev 创建叫dev的分支，不切换

9.1.3 git checkout dev 切换到dev的分支

9.1.4 git branch 查看所有分支

9.1.5 git branch -d issue001 删除issue001分支

9.1.6 git merge dev 合并分支

9.2 合并的冲突问题

10 远程仓库使用 [10.3开始即可]

10.1 下载线上项目

clone 克隆命令 下载项目

示例：
git clone https连接地址

10.2 修改电脑上默认gitee账号密码

10.3 SSH方式访问远程仓库

10.3.1 配置SSH秘钥

10.3.2 在本地生成SSH认证证书

ssh-keygen -t rsa -C "邮箱地址"

注意：
邮箱一般使用平台注册邮箱

• 查看公钥（也可以去文件夹中查看）：
  cat ~/.ssh/id_rsa.pub
  

10.3.3 在gitee平台配置公钥

标题使用邮箱地址即可，粘贴公钥并确定，输入密码确认即添加成功！

10.4 上传本地项目到远程仓库

10.4.1 创建远程仓库

10.4.2 初始化本地仓库

git init 初始化本地仓库

10.4.3 在本地仓库添加文件

• 创建或者拷贝文件

10.4.4 将文件添加到缓存区

• git add 文件名称

10.4.5 将文件提交到本地仓库

• git commit 文件名称

10.4.6 将本地仓库和远程仓库进行关联

• git remote add origin 仓库地址

10.4.7 先拉取远程仓库文件

• git pull origin master

10.4.8 将本地仓库推送到指定远程仓库分支上

• git push -u origin master
  注意注意注意
  当此步骤出错error: failed to push some refs to '地址'时，主要原因是因为在gitee创建新库的时候使用了模板，gitee中有 .ignore文件与readme文件，本地有自己的文件，互相没有关系，所以无法拉取和推送，这时候使用git pull --rebase origin master拉取文件再次推送即可！

10.5 向远程仓库提交代码

10.5.1 修改本地仓库代码

• 对本地仓库任一文件做修改

10.5.2 将文件添加到暂存区

git add 文件

10.5.3 将文件提交到本地仓库

git commit -m "备注"

10.5.4 将本地仓库中文件推送到远程仓库

git push

10.5.5 拉取远程仓库的代码

git pull
**注意：**每次提交代码之前，不是先add也不是commit，而是先进行pull操作

10.6 版本冲突

git是团队工具，版本冲突一般是指：

A 对某个文件进行修改，并且进行提交到了远程仓库，其他人在之前的版本上也对该文件进行修改操作。此时，文件内容出现覆盖问题，

例如： 张三 ，在文件第一行 123 将文件进行提交 张三 修改了 v1.0版本的第一行 版本号 v2.0
李四，也在文件第一行写了 456，李四也对文件进行提交 李四也修改了 v1.0版本的第一行

此时git无法判断使用哪个版本，同样的版本存在多个。git软件将问题交给了提交者。提交自己更新自己的 版本号，使用git pull 进行更新，产生冲突的文件，人为处理冲突，然后再进行提交。
注意：
在任何时候，提交代码前先pull

10.6.1 先执行git pull 命令拉取代码

当文件发生冲突时，push是无法成功的
需要使用git pull 将冲突的内容拉取本地相应的文件中

10.6.2 手动解决冲突部分

手动解决冲突，一定要进行协商。

10.6.3 将新的文件添加到缓存区

10.6.4 将修改后的文件提交本地仓库

10.6.5 将本地仓库内容进行推送

注意：
git 解决冲突，不难，但是在实际中相对繁琐。所以在开发中一般有两个解决方案：
安排开发任务的时候，尽量减少开发者融合的代码任务。或者遇到冲突时，将自己的代码备份一份。使用线上代码覆盖自己的代码。将备份代码粘贴，提交。
每个开发者自己创建一个分支，在自己的分支开发，然后进行分支的合并。但是，最后合并相对比较麻烦。

11 Git可视化工具

11.1 git的可视化工具分类

1. Github for Desktop 支持多个系统
2. Source tree 支持多个系统
3. TortoiseGit
   https://www.cnblogs.com/xiuxingzhe/p/9312929.html
4. 源于TortoiseSVN，只支持windows操作系统。在windows操作系统下，对git管理文件有图标进行标注。对于一些简单的git操作相当便利。
5. IDEA

11.2 IDEA配置git

11.3 忽略文件

在开发中，往往会产生很多编译后运执行文件，或者缓存文件也可能有本地的配置文件。
如果不进行处理，每次git在同步文件，就会一直提示要进行提交。循环冲突。基于这样的情况，git软件提供一个名字.gitignore，这个文件表示需要忽略的文件，在git本地仓库中，git不进行管理的问题。

注意：
添加到忽略文件，git忽略对文件管理

pull

---