实验室培训（一）—— 版本管理工具git

1、什么Git

Git是分布式的版本管理工具，在实际项目管理中起到非常重要的作用。
思考1：什么是版本管理工具？为什么要使用版本管理工具？
答：了解版本控制。

2、版本控制

版本控制（Revision control）是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。
举一个文件迭代的例子：
在这个过程中，我们从第一次修改到最后一次修改中衍生了很多个版本，造成文件冗余的情况，让我们自己管理起来非常地麻烦琐碎，那可能有同学会觉得：为什么要搞这么多个版本？每次最新的版本把上一次的版本覆盖不就好了嘛？这样不就只有一个版本了嘛!

那这里就会有一个问题，大家想，假设在工作中，你先做了一个方案A给老板，然后老板说不行，这个方案不太好，要你重新做一个方案，然后你第二天又做了个方案B（在方案A文件上直接修改），再拿给老板看，然后老板他脑子瓦特了，他变卦了，他说：诶，我昨晚想了一晚，我觉得方案A其实还不错，要不就用方案A吧。你：老板。。。方案A没了，昨晚我改成方案B了。其实说白了就是对原来做过的事情要备份，说不定哪天就用上了。

回到版本控制这个话题，上面说到备份是必须的，也就是每一次的版本都需要保留下来方便以后查看复盘，但如果像上图那样，每天看着都吐了呀。而git就能很好地帮我们解决了这个问题，怎么说呢，通常对我们来说，我们只想看到最新版本，旧的版本一般都是因为存在各种问题而被淘汰的，git就可以很方便地帮助我们解决这个问题。下图简述了版本迭代、版本回退
思考2：git就只有这么点用处吗？就只是协助我提交新版本，还能查看旧版本（相当于自动备份）？
答：如果文件仅对于自己使用来说，确实git的优势要被“抹杀”不少，但其实git最主要的亮点在于管理多人协同操作

3、多人协同开发

举一个收集资料的例子：（可能不是很准确，但是有内味儿就行了）
假如，快放寒假了，班长要收集所有同学的寒假去向，有三种收集方案：
1、班长把文件发群上，每个同学填好后私发给班长整理
2、班长把文件发群上，①前面填好的同学填好后发群上，尔后面的同学接着最新的那份继续填，①②过程不断重复。
3、班长发个腾讯文档，大家一起填。

很明显，
第一种，累死班长，
第二种对比第三种，
第二种要等上一个人填完，后面的人才能接着填，过程不仅会浪费时间，还可能有各种文件内容冲突情况。
第三种大家可以一起填，快的话可能两分钟就全部填好了。

为什么要第三种方案可以一起填，其实就是因为第三种方案可以多人同时操作同一份文件。

同理，在我们实际开发项目中，一个项目不可能从头到尾都只是你一个人在做开发，这样累死倒是好说，怕是一个人做不完做不好又没工资那不惨了啊哈哈哈，所以肯定是多个人同时在这个项目，共同去维护项目的版本。这时，如果还是把文件放在自己本地就不妥啦，因为这样的话你的小伙伴不知道你具体做了什么，又修改了什么。比如你和队员A、队员B合作写一份开幕式致辞，你写开场白，队员A写中间部分，队员B写结尾。你们各司其职，都把自己的部分写好了，但是彼此都不知道另外两个家伙写了什么，那这时是不是就需要一个平台帮助我们去维护我们写好的东西，并对小伙伴可见，难不成你还想把你的内容给其他两个人都发一份？那如果不是两个，是十个人呢？这就头大了，所以就引申了Git托管平台，比较常用的有两个（可自行百度了解）
1、github
2、gitee

这两个平台主要作用就是：
1、代码托管（不仅限于代码，学习笔记、各种文件都可以往上面放，开源共享）
2、研发协作（多人协同开发）

4、真刀真枪干

1、先把git安装好
Windows系统Git安装教程（详解Git安装过程）
2、注册一个gitee账号
3、学习命令之前，要先了解Git的工作区、暂存区、版本库、远程仓库。
因为git命令几乎都是把代码文件在这几个地方来回地交换。
一、概念
1、四个工作区域
Git本地有四个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)、git仓库(Remote Directory)。文件在这四个区域之间的转换关系如下：
Workspace： 工作区，就是你平时存放项目代码的地方

Index / Stage： 暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息

Repository： 仓库区（或版本库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本

Remote： 远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

二、整体工作流程

1、弄好本地仓库

① 新建一个文件夹
② 新建一个文件，随便写点东西
③ 新建一个仓库（本地仓库）
git init
命令执行后就会看到多一个.git
④ 如果是第一次使用git，需先做好Git的配置，这里大家需要配置的是注册gitee的用户名和邮箱，以后每一次将代码提交到远程仓库（gitee）都需要用到。（已配置过可以跳过这步）
git config --global user.name "xxxxx"#用户名
git config --global user.email [email protected] #邮箱
执行以上两条命令后，可执行git config --list查看配置信息，可以按空格键一直往下查看，到最后出现END，按q退出！

⑤ git status命令表示：文件，文件夹在工作区，暂存区的状态

⑥ 把文件提交到暂存区，再一次查看文件的状态
git add xxx——把工作区的xxx文件添加到暂存区
git add .——把工作区的所有文件添加到暂存区

⑦ （可选择性忽略，如果操作了，后面记得再add回暂存区）既然可以把文件从工作区添加到暂存区，那当然也可以
将文件从暂存区移除
git reset HEAD -- ./filename——移除暂存区某个文件
git reset HEAD -- .——移除暂存区的所有文件
⑧ 提交到仓库区，再查看文件的状态
git commit -m "xxxxxx"——将暂存区的文件提交到仓库区，-m后面的内容是提交描述

至此，本地仓库的工作区就已经完成一大部分了，其实就是把从工作区添加到暂存区，暂存区再提交到仓库区，我在写的过程中间也伴随着一些回退的操作供大家学习，下面我们再看看如何完成远程仓库的工作，最后呢，就是关联本地仓库和远程仓库，把本地仓库的文件推送（push）到我们的远程仓库，这部分内容还是很简单的，大家耐心一点就ok啦。

2、创建远程仓库
很简单，没什么好说的，我就顺着过程截下图吧
至此，远程仓库也已经创建好了。

3、关联、推送
回到刚刚的git命令窗口，文件已经commit了。
① 本地仓库需先关联远程仓库
为什么要关联？很好理解，本地仓库要把代码push给远程仓库，起码要知道远程仓库到底在那里，也就是远程仓库的地址
git remote add origin xxxx——xxxx代码远程仓库的地址，origin是为关联的这个远程仓库起的别名，一般为origin，如果你用其他别名，注意push的时候也对应就好。

② 推送
git push -u origin master意思是将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了

③ 观察远程仓库情况（刷新一下网页）
确实没有问题，哎呦还不错。

至此，重点才刚刚开始。。。。
因为上面这些操作自己一个人玩没什么问题，但是如果是多人协作开发，可能就不太好了，主要是不规范的问题。

=========================更新 11.03=========================
继续。

上次说到为什么如果是多人协作开发，上面的操作可能就不太好，主要是不规范的问题。下面和大家讲一下分支，在描述一个场景中出现的问题，大家就会知道我们为什么要使用分支了（分支的作用）。

主分支：master。如果小伙伴有留意的话，你就会注意到上面的git命令实践中我有特意标识过这个master，说明是主分支，但并没有解释什么是主分支。
在主分支上的版本：通常是正式对外发布的、可正常使用的版本。(就是很重要的版本)
比如上面我和大家一起成功推送了文件到gitee，这就是第一个版本V1，且该版本默认在master上，请看下图。
这时如果我们修改一下文件内容，再次推送，就会有一个新版本，就是V2了。
点击“2次提交”可看到
当我们是一个人自己开发项目、整理笔记的时候，完全没有问题，整个仓库负责人是我们自己，唯一使用权也是我们自己，我们说这最新版本好用就是好用，直接对外发布即可。

but，实际情况通常不是这样的，通常是项目多人维护开发，我们只是一个打工人，上有领导，下有。。。，如果我们每次开发新功能，修改完文件后都直接把文件push到master，你以为你的代码万无一失，简直perfect，但实际代码可能漏洞百出，而这时你又把这个代码给push到master分支，这时很多用户以为你们团队发布了新版本，疯狂抢先下载安装，然后发现这版本什么玩意儿，发现出问题了，你说你的领导会不会骂死你啊哈哈哈哈。

所以在实际的工作流程中，我们不会轻易地去修改更新master分支，这样风险太大，这时（终于说到了），我们就会使用到分支，我们每个开发者都应该基于master分支，分一个自己属于的dev分支出来，独立在自己的分支上做开发，开发完成后，再合并到master主分支上

1、基于master分支：通常情况，当然是要基于最新版本去开发啦。
2、合并到master主分支上：Pull Request，只是发起合并请求，但你的领导不一定同意合并，可能他觉得你代码不规范、代码逻辑还可以进一步优化等原因，拒绝合并你的代码，你就只好乖乖重做啦。

来了来了，实践出真知

1、基于master分支
方法①：git clone xxxxxx——xxxxxx 指的是仓库地址，如果你本地从没有拿到过该项目的文件或代码，第一次先把项目文件或代码克隆下来。
方法②：git pull—— 本地仓库曾关联过该仓库（git remote add origin xxxxxxxxxxxxxx），可直接把最新的master分支的文件或代码pull（拉取）下来。

先展示git pull（该命令是紧跟更新前的那次push）
诶，只是显示一句话，Already up to date，其实意思就是表明当前本地的文件已经是最新的了，就是和master分支上最新版本的文件是一模一样的意思。确实也是如此，因为我们不久前才push上去，没有其他人push过，所以本地和远程肯定是一致的，那就没什么好pull的了对吧。

所以我还是从头演示一下吧，假设本地一开始没有的情况。

① 新建一个文件夹

② git clone xxxxxx

找到链接地址
克隆下来
③ 可以用git status查看一下文件在各区的状态，那是相当地干净，因为我们只是克隆了一份，啥也还没做，这时本地仓库的状态就和我们之前push时的状态没什么区别。
④ 第③点说了这时本地仓库的状态就和我们之前push时的状态没什么区别，这个意味着什么，是不是就意味我们现在修改好文件，然后add、commit、最后push上去就好了? 是的没错，但是这样的话我们就还是会直接push到master主分支，这显然不是我们希望看到的。所以我们应该基于master分支分一个分支出来。我这里直接在gitee上操作，新建一个远程分支(分支分为：远程分支、本地分支)，命名为hzh/dev。

⑤ 点击分支
⑥ 新建分支 hzh/dev
刷新网页可看到我们确实是多了一个分支
接下来要怎么怎么做呢?其实已经很清晰了对吧，之前不是说不要直接push到master分支嘛，那我们push到自己的分支总可以吧，然后最后在通过Pull Request向master分支发起合并请求就可以啦（领导通不通过就再说呗），我们打工人的工作就完成啦！下面赶紧操作试一试

⑦ 首先还是任意修改一下文件的内容

⑧ 开始一顿git开头的命令操作
至此，我们就已经把成功文件push到hzh/dev了，不信我们就来看看gitee有没有什么变化（还是记得刷新一下网页）
⑨ 先看master分支
⑩ 再看hzh/dev分支
以上过程，可称为“本地分支push推送到远程指定分支”，最后一步，合并分支到master，之前就提到过不是直接合并，只是发起一个请求，最后同不同意合并你大佬说了算。

⑩+① 过程很简单，就跟我们向老师请个假一样简单，我顺便截个图吧

创建 Pull Request
点击合并分支后，页面下面还有个接受Pull Request，搞定！（这步忘了截图）

⑩+② 再看看此时的master分支，可看到合并了hzh/dev分支后，master分支的代码也更新了！
以上，实际项目多人协作开发的1.0版本git使用讲解使用就结束了，其实非常非常的简单对吧，git命令使用就那几条，整体思路也很清晰，流程图如下：

既然上面说到有1.0版本，肯定是还有一个2.0版本，没错，下面这个流程图，就是2.0版本，这个流程也是我目前常用的一个流程。
看起来好像夸张的样子，其实并没有，就是2.0版本就是比1.0版本多个一些本地分支的操作，而这部分本地分支是非必要的，但还是那句话，规范的问题。

===========以下部分实验室小伙伴可选择性学习，个人建议学习============

关于本地分支的操作
上面一直在提到分支这个概念，而且也实际操作了一下，但我们一直操作的都是远程分支，而且还是在gitee平台上通过网页操作，新建分支，查看分支的情况这些。并没有通过git命令的方式去操作，我个人觉得远程分支，通过平台操作没问题，因为更直观，图形化谁不爱对吧。但是操作本地分支，学习几个git分支命令还是很有必要。废话不多说，先学几个分支命令再看看结合实际流程2.0版本。

① 查看本地分支
git branch

② 查看所有分支（包括本地和远程分支）
git branch -a
③ 创建分支
本地不存在dev分支
git branch dev
（创建并切换）
git checkout -b dev

远程存在dev分支
git branch dev origin/dev
（创建并切换）
git checkout -b dev origin/dev

④ 从当前所在的分支切换到dev分支
git checkout dev

⑤ 删除本地分支

删除本地分支
git branch -d dev

删除远程分支
删除远程dev分支（第二个命令表示：推送一个空的分支到远程dev分支）
git branch -r -d origin/dev
git push origin :dev

如果要删除master分支，需要在gitserver上将master设置为默认分支的选项取消（选择其他分支作为默认分支）
git branch -r -d origin/master
git push origin :master

⑥ 将dev本地分支的内容合并到本地master分支（需要先切换到master分支）
git merge dev

好了，关于分支命令基本是已经学完了，我们先聊聊为什么要本地为什么也要建立分支，远程分支其实是为了不直接操作master主分支，在多人协作的情况，每个人先独立于自己的分支进行文件的修改或开发，那本地分支又是为什么？如果说远程分支是因为多人协作，那本地分支大概是因为功能划分。我就直接描述2.0版本的情况吧，在2.0版本的流程中，当我们把远程分支clone或pull下来后（通常默认是clone或pull master分支），我们不会在当前本地的主分支（通常默认还是master分支）直接进行开发，而是新建一个功能分支,通常命名为features/xxx，在这个分支进行开发，开发完成后，再把该功能分支合并到主分支（本地的主分支），最后在主分支上执行push推送，push推送和1.0版本是一样的，推送到非master的指定分支。

来了来了，直接截图演示！
终于，完结撒花！！！

当然，这并不是关于git学习的全部，如果要讲全部我直接放个视频链接就好啦嘻嘻，我肯定是没B站大佬们讲得好。我能做的只是结合实践使用流程的需要帮大家同时也帮我自己总结了一下。

就先这样啦~
期待后面各位小伙伴的技术分享会~
培训（二）没有头绪，还不知道和大家探讨分享些什么内容~
再会！