首相，你要明确说明一下，git是软件，是用来进行版本控制的软件，什么叫版本控制，举个例子吧，你在用word软件写论文的时候，同一篇论文你可能会保存好几个：“‘GAN网络应用初级版’”，”GAN网络应用中期版“，“GAN网络应用最终版”。 而git要做的就是类似这种不同版本之间的管理与控制

关于git的安装，这里不做赘述，网上的安装教程很多，而且很简单，这里就不做详细介绍啦。

我们使用的时候一般是使用git自带的命令git bash，二不使用windows自带的CMD，因为‘git bash’ 自带的命令行很空命令是和Linux命令都是一样的，操作非常方便。（cmd也可以用，只是没有那么方便而已）

在git bash 中，ls、cp、mkdr、vim等这些命令都有，‘而且文件还有颜色区别’，你说好不好用，只想对CMD说声say good bye

下面开始进入正题啦===============>GO

在git bash 处打开你要管理的库

打开之后直接进入当前文件夹中，然后我用git stash查看状态，显示我们并没有把它初始成一个仓库，所以git此时是对他是无法进行管理的。

我们要管理的是MyProject这个文件夹，之后所有的git操作都是在这个文件夹下进行的

1. git初始化
   git的初始化化很重要，这是使用git的第一步，你要把一个项目想要管理起来，第一步要做的就是把这个项目进行初始

git初始化命令

git init

初始化的结果如下：

从上图的初始化可以看出三点：

• 这个仓库已经被初始化成一个空的仓库，也说明此时可以进行git版本控制管理
• 初始化的仓库在·MyProject/.git·这个文件中
• （master） 就是我们当前初始化的仓库是主分支,也是当前所处分支的状态

2. 初始化init作用
   初始化成功之后，在项目文件夹下会多了一个.git 文件夹，（如果你的没有显示，是因为它被隐藏啦，自己设置一下就可以）。下面说明一下. git文件的作用：
   

• 之后所有的版本都会放到.git文件夹中
• 比拷贝省空间，第一次提交commit会都放进来，之后每一次commit只把修改的内容保存进来

在说git add 命令之前先说git status命令
(我们现在E:\00\MyProject\ 目录下创建一个git_test.py 文件)

1. git status 查看当前管理文件的状态，命令：

git status

此时查看状态显示如下图：

从上面显示的状态可以看出，此时主分支还没有任何提交（commit），untracked file就是未被跟踪 / 追踪的文件，下面篮框中的git_test.py显示为红色 说明该文件还没有被git管理起来，下面给的提示是可以用git add 进行追踪管理起来。

git status有三种状态：

• 红色：修改、创建、删除都是显示红色
• 绿色：git add 添加之后变成绿色
• 白色：git commit提交之后变成白色

2. git add添加要管理的文件，命令：

git add <file>

使用git add 把文件进行管理起来，用命令git add告诉Git，把文件添加到仓库：，之后在用git status查看状态，此时git_test.py文件显示为绿色这说明，该文件已经被git管理起来啦。之后我们如果修改了git_test.py这个文件，它又会变成红色，要管理起来还要在git add 添加一下

3. 修改文件状态会改变

下面我们把git_test.py 文件中添加一行文字如下，然后在查看添加文字之后的状态

下面提示我们已经修改啦git_test.py文件，未为提交暂存的更改（changes not stage for commit），所以下面显示该文件已经被修改（modified），所以要通过git add 再提交一次把修改之后的文件变绿，管理起来。

提示语：

提示可以使用git add file 把这个修改的红色的文件再被管理起来
(use “git add …” to update what will be committed)
提示
(use “git checkout – …” to discard changes in working directory)

如果有很多个文件都被修改了，怎么办，一个一个手动这样修改吗，shit，这样岂不是要逆天。此时可以用一个点. 代替:

git add file1  file2 ...   # 都手写上去累死你
git add .   # 明智之举

这个点表示，把当前文件夹下所有的文件他（会递归的把每一个子文件夹下的文件也同样管理起来）都统统管理起来，就是要把它们都变绿

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

git commit -m <message>

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

执行命令：`git commit -m “第一次提交到仓库” ，此时就已经把所有的文件都提交到了仓库中，显示信息如下：

• 是在主分支上的第一提交（这里看到第一次提交是我写的注释信息）
• 有一个文件被修改（是一行内容插入），就是git_test.py文件，我么在这个文件中添加了一行文字：“开发一个无人售卖商店”
• commit提交之后信息中git_test.py文件变成白色 此时说明提交成功（如果有很多文件同样都会变成白色）
  

注意：

1、提交的时候一定要加上 -m 参数和后面的说明信息，不要问为什么（这是组织下达的命令，你去执行就是啦）
2、如果再提交的时候提示你输入用户和邮箱的信息，一定要写上，这样是告诉别人这个是谁提交的，后面知道来源相关的信息，添加方式：

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

2. git log 查看提交（commit）的历史记录，命令：

git log

git log 是查看提交的历史记录信息，显示的信息如下图：

• 提交的版本号，这个版本号很有用，后面会继续介绍
• 提交的用户名和用户的邮箱信息，因为我之前是配置过的，如果你没有配置过，就需要用git config --global 进行配置（只要配置过，下次再使用git 初始化一个仓库时，就不需要进行重新配置啦，除非你想更改用户信息）

commit 提交之后，我们再来查看一下状态信息：
nothing to commit, working tree clean ，意思就是：我们当前在工作的路径下所有修改和变动的文件都已经被提交啦。（当然，如果你后面又有修改文件则要再次提交啦）

为什么Git添加文件需要add，commit一共两步呢？

add只是把所有修改的文件文件添加到仓库，而commit是把所所有的文件提交到仓库，每次commit之后都会生成一个版本号，之后只要拿到这个版本号，想回到哪一个版本都可以。

注意：

如果你提交的时候报错，看一下是不是-m 后面的message用的是单引号，然后改成双引号就可以啦，先说明我没有尝试单引号，只是有人这么说，所有最好直接用双引号，省去不必要的麻烦。

命令：

git reset --hard  版本号

先说一下版本回滚是什么意思，上面我们已经提交commit一次是一个版本，如果我们修改之后再提交commit一次，此时就是两个版本，而此时是处于最新的版本，如果我们要回到第一个版本这就叫回滚。

下面是实例说明：
我们继续修改git_test.py文件，在该文件里再添加一行文字：“开发完成进出入模块”，此时的文件已经被修改啦，内容如下：

下面就开是一系列的操作：查看转态->添加到库->提交->查看log->回滚，具体如下图：
（可以看到此是第二次提交的版本号的头指向master：HEAD->master）

用git log 可以查看到此时已经进行了两次提交，此时我们想回到第一次提交的状态应该怎么办呢？此时只要用git log查看版本号和提交时的message信息，就可以定位到第一次提交的版本号。上面蓝色框起来的就是第一次提交的版本号，下面让我们一起回滚吧：

git reset --hard 1249aeab1df156cda5d2245b073c9554f6a0a03b

如下图：可以看到，此时的HEAD已经指回到第一次的状态

下面我们再来看看git_test.py文件的内容是不是第一次提交时的内容：

哦嘛噶，真的回滚回去啦，神奇不，哈哈哈啊

上面是往前回滚
往前回滚之后，我们再查用git log 查看提交记录的时候，第二次提交的记录已经不在啦，如下图，怎么办，拿到真的是一去不复返了吗

大家不要慌，只要是真爱，我们也可以往后滚，此时用命令git reflog 就可以查看到多有的提交记录，之前回滚的记录也会出来，如下图：

此时我们我们可以看到第二次的提交记录又回来，但是我们看到的版本号变短了，其实两个是一样的，然后我么在往后滚会到第二次提交的状态（可以看出git log 相当于记录当前的版本提交信息，git reflog相当于记录了历史所有的版本提交信息）：

然后我们在看一下git_test.py文件内容有没有回到第二次提交的状态：

哈哈，果然回来啦，确认无误，是真爱！

总结上面的内容：

• 进入你想要管理的文件夹
• git init
• git status
• git add .
• git commit -m “一定要好好写”
• =========================
• git log
• git reset --hard 版本号
• git reflog
• git reset --hard 版本号

现在又开发了一个“开发商品货架模块”，然后用commit上线提交啦，如下：

紧接着又接着开发“开发货架商品识别模块 1 / 2” 但是开发一半，突然发现上面开发的“开发商品货架模块” 有bug，此时要回去修改bug，但是现在的商品识别模块只开发了一半，不能commit上线提交，怎么办 ？

此时的办法就是：把现在开发的商品
识别模块暂存在一个地方（并没有提交），用git stash。
之后就会看到修改之后并且没有提交的“开发货架商品识别模块 1/ 2” 被暂存起来了，然后我们修改bug之后再进行提交。

git stash

从下图可以看到，开发的商品模块我们并没有commit 提交，所以是飘红的，然后我们用git stash 把开发一半的商品识别模块暂存起来，之后再用git status 查看的时候已经没有啦，因为已经

git stash pop

bug修复完成之后，我们用git stash pop把暂存的“开发货架商品识别模块 1/ 2”拿回来，然后继续开发，但是拉回来之后发现出现冲突，这时就需要我们手动去进行修改啦。

注意：

• 如果是同一个文件进行修改 git stash pop拉回来之后可能会出现冲突，此时只能通过手动修改
• 如果修复的bug和暂存起来的不是同一个文件，不会出现合并的时候的冲突

• git stash：将当前工作区所修改的内容存储到“某个地方”（此时修改之后是没有git add 和git commit操作的），将工作区还原到当前版本未修改过的状态
• git stash list：查看“某个地方”存储的所有记录（暂存的记录）
• git stash clear：清空“某个地方”（清空所有的暂存）
• git stash pop：将第一个记录从“某个地方”重新拿到工作区（可能有冲突）（就是上面stast@{0}，取数字最大的那一个，数字就是暂存的编号）
• git stash apply: 编号，将指定编号的记录从“某个地方”重新拿到工作区（可能有冲突）
• git stash drop：编号，删除指定编号的记录

注意：

真正公司出现bug不会用git stash 进行解决，自己平时用可以，用的更多的是基于分支进行修改bug，下面介绍。

git branch <分支名>

相当于是两个环境，没有任何影响。下面创建完分支后，然后在切换分支的啥时候出现错误，是因为先要把当前修改的分支进行提交commit之后，才能才能正确的切换分支

git checkout <分支名>

从后面显示的dev 可以看到已经正确的从master分支切换到了dev分支上

当然还可以用git branch -b dev 创建并切换到分支，但是我现在用的版本已经没有这个-b参数啦，不知道你们的有没有，如果有的话，你可以尝试使用。

下面我们在dev中创建一个a.py 文件

可以看到在切换到master上的时候，在dev下创建的a.log文件并不在，所以两个环境是分开的。

git merge <分支名>

在那个分支，就是把这个分支名合并到当前分支。
现在我们把上面dev分支合并到master分支下，所以就可以看到master下面现在是有a.log文件的啦。

在合并的时候需要写一点类似commit -m message的message的信息，自己编辑一下就可以，如下。

所有修复bug也可以用这种方式，先创建一个bug分支修复好bug之后，再合并回到master分支上，最后把bug分支删除。

注意：

git merge 合并的时候会产生冲突，此时就要进行手动修改啦（产生冲突一般就是由于修改了同一个文件的内容，所以合并的时候就会出现冲突。）

总结上面：
当要紧急修复bug，操作流程如下：

1. 将dev 中现在正在开发的功能提交到dev

• git add .
• git commit -m “xxxxx”

2. 切换到主分支（master分支）

• git checkout master

3. 创建并切换到bug分支

• git branch bug
• git checkout bug
• 在bug分支上进行修复
• git add .
• git commit -m “xxxx”

4. 切换回master分支，合并修复的bug分支，最后删除bug分支

• git checkout master
• git merge bug
• git branch -d bug

5. 查看当前有哪些分支

• git branch 或git branch -a 或git branch --all

面试题1：加入你们公司现场代码出现bug，你应该怎么办？
答： 创建一个bug分支，在bug分支上进行修复，修复完成之后再合并到master分支上。修复完之后再回到dev继续开发

面试题2：git rebase是什么意思 / 作用？
rebase 和merge都是做合并操作的，但git rebase 将提交记录合并到一条主线，提交记录整洁。

git rebase合并也有可能会冲突，手动解决完冲突之后，再执行git rebase --skip 跳出去

用git merge master 把master合并到dev上，用Git GUI 查看合并分支如下：

用git rebase dev 把dev合并到master（兰蓝框），用Git GUI 查看合并分支如下图，可以看到用rebase合并更整洁。

（如果想保存每一次合并的记录就用merge，如果想要更整洁就用rebase）

比如我们在公司写的代码，下班之后还想回去继续写，但是我们又不想带电脑回去，住处有一台电脑，但是没有在公司写的代码，怎么办呢？

• 可以用U盘考一份回去，回去继续写
• 存到百度云，然后回去下载下来继续写
• 存到版本存储仓库

这个版本存储仓库就类似百度云网盘：

公共的版本存储仓库：

• github（国外，github上也有私有账户）
• 码云（国内：开源中国的，码云会给几个免费的私有仓库）
• 国内还有很多其他的，不做列举

自己搭建：

• gitlab

用gitlab几条命令就可以搭建一个代码存储仓库，虽然说存储在其他平台可能不太安全，但是自己搭建也有一定个弊端，首先要有一台服务器，还有要做好代码的备份和安全措施，方式黑客攻击代码泄漏。

1、注册码云账号
下面我去注册一个码云的账号试一下：

2、创建版本存储仓库

创建完成显示如下：
（test_git就相当于是一个文件夹，之后项目的代码就会推送到这个文件夹中）

之前我们已经在本地初始化一个仓库啦，现在我们来说一下具体使用和上面的一些参数：
分成两种情况：

• 一种是从头开始创建一个仓库
• 另外一种是已经有现有的仓库

很显然我们是已经创建过啦，我们只要把目前所有提交都合并master分支，然后存储到码云上即可。

git remote add origin https://gitee.com/shliang/test_git.git

作用： 添加远程仓库的地址，然后给这个远程仓库地址https://gitee.com/shliang/test_git.git起一个别名叫origin ，你如果觉得不好可以自己起。

git push origin master

推到码云自己创建的仓库的时候会要你填写在码云的用户名和登陆密码

下面是推到远程版本存储仓库成功显示信息如下

之后我们刷新一下网页，就可以看到本地仓库的master分支代码已经存储到了码云存储仓库

dev这个分支也可以推过来，我们开发的代码都放到dev这个分支上。

git push origin dev

我们创建一个家里的电脑文件夹表示在家里的电脑

cd 家里的电脑/
# 把代码从远程存储仓库下载下来
git clone https://gitee.com/shliang/test_git.git

从上面可以看到，我们已经成功把代码克隆到家里的电脑，但是我们继续开发要在dev分支上进行怎么办，此时只有master分支。

我们就可以通过以下流程进行切换到dev上进行开发：

• git branch dev： 创建一个dev分支
• git checkout dev：切换到dev分支
• git pull origin dev ：把远程存储仓库中的dev分支更新到现在的dev分支中，此时就是我们正在开发的代码啦

这个origin在我们进行git clone URL的时候，就已经默认给这个URL起了别名叫origin，所以可以直接用

这样就可以在家里的电脑进行继续在dev分支进行写代码啦：

到了公司之后在把代码从dev上拉下来继续开发，如下：

上面总结：
码云使用：

1、注册账户 + 创建项目 + 拷贝地址https://gitee.com/shliang/test_git.git
2、在公司本地代码推送远程

• cd 项目目录
• git remote add origin https://gitee.com/shliang/test_git.git
• git push origin master
• git push origin dev
• 继续写代码
• git add .
• git commit -m “提交记录”
• git push origin dev

3、到家

• 下载代码
• git clone https://gitee.com/shliang/test_git.git
• 或
• 创建目录
• cd 目录
• git init
• git remote add origin https://gitee.com/shliang/test_git.git
• git pull origin master
• 创建dev分支
• git checkout dev
• git pull origin dev
• 继续写代码
• git add .
• git commit -m “提交记录”
• git push origin dev
• …

面试题3：
问题：在公司怎么进行协同开发的呀？

答：为每个人创建一个分支

• master
• dev分支

• review分支(组长做代码的review)
• 开发员1的分支
• 开发员2的分支

每个开发员把自己分支的代码都合并到review分支，组长负责检测review分支有没有问题，没有问题之后在合并到dev

面试题4：公司是否做代码的review（回顾 / 检查）？ 谁做review？
答：组长，一般2天左右做一次review

面试题5：你有没有给开源的项目贡献过代码？

• 项目的创建者添加自己为合作者，共同开发，就可以为该项目提交代码

• 创建组织，邀请成员（可以在setting中进行设置相关权限）

面试题6：例如Django项目的创建者（此时已经和核心成员已经够了，不可能邀请你在一起开发啦），但是此时你怎么给别人贡献代码？

• fork别人的项目，这个就相当于把被人的项目复制到自己的仓库中
• 修改代码
• 创建pull request 请求，当作者看到你的代码确定有用，就会接受(confirm commit )你的pull request，之后你提交的代码就会合并到项目作者的项目中，然后你也可以在项目作者的commit中看到自己的pull request记录，这就是记录了你的贡献呀！

• 创建gitignore 文件
• 在gitignore 中填写或略的文件名（有很多.txt文件都忽略，就可以写成*.txt）
  把忽略的文件名写到gitignore 中，再次提交git status自动检测就已经没有检测到test_ignore.py文件啦，所以在提交的时候后面也不会有这个文件。
  

gitignore书写规则，github官网上就有，搜索gitignore就进去啦，默认会忽略哪些文件，按照规则写就可以。也可以在创建仓库的时候选择gitignore，就会自动创建这个文件。

用于定义不同的版本V1, V2 …， git tag

·建议：

如果英语不太好，先用码云，然后用熟了在用github，这样就可以去对应的位置找到相应的功能

作业：
模拟自己创业，协同开发

• 组长，创建仓库：合作者邀请成员
• master/dev/review
• 创建自己的分支
• • 写代码
• • 提交到自己的分支
• 切换到review分支，将个人的分支代码合并到review，如果报错：说明已经有人在这段时间先提交啦。j解决冲突：先把远程review拉下来，之后在合并到review，最后再推导远程项目仓库。
• 组成review分支：看一看，没有问题
• 在本地合并到dev分支
• 将本地dev推动到代码仓库

一定不要将公司的代码放到自己的github账户上

参考：
1、https://www.cnblogs.com/wupeiqi/p/7295372.html
2、https://www.liaoxuefeng.com/wiki/896043488029600

♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠ ⊕ ♠