Git 版本控制详细使用教程

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

2. git add 管理文件

在说 git add 命令之前先说 git status 命令。 (我们在 <项目路径> 目录下创建一个 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)

   如果有很多个文件都被修改了，怎么办，一个一个手动这样修改吗？此时可以用一个点 . 代替：

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

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

3. git commit 把文件提交到仓库，命令：

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

   git commit -m <message>
   

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

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

   • 是在主分支上的第一提交（这里看到第一次提交是我写的注释信息）。
   • 有一个文件被修改（是一行内容插入），就是 git_test.py 文件，我么在这个文件中添加了一行文字：'开发一个无人售卖商店'。

   commit 提交之后信息中 git_test.py 文件变成白色，此时说明提交成功（如果有很多文件同样都会变成白色）。

   

   注意：

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

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 的高级使用

1. Git 的高级使用 1

1. git reset --hard 版本号 版本回滚

命令：

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 文件的内容是不是第一次提交时的内容：

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

2. git reflog 查看所有的提交记录

上面是往前回滚 往前回滚之后，我们再查用 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 版本号

2. Git 的高级使用 2

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

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

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

1. git stash 把没有提交的代码暂存在某个地方，命令：

git stash 

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

2. git stash pop 进行把暂存的代码拿回来，命令：

git stash pop 

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

注意：

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

3. Git stash 一些其他命令的使用

• 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，下面介绍。

3. Git 高级使用 3

1. git branch 创建分支，命令:

git branch <分支名>

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

2. git checkout 切换分支，命令：

git checkout <分支名>

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

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

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

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

3. Git merge 合并分支，命令：

git merge <分支名>

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

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

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

注意：

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

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

将 dev 中现在正在开发的功能提交到 dev git add . git commit -m 'xxxxx' 切换到主分支（master 分支）git checkout master 创建并切换到 bug 分支 git branch bug git checkout bug 在 bug 分支上进行修复 git add . git commit -m 'xxxx' 切换回 master 分支，合并修复的 bug 分支，最后删除 bug 分支 git checkout master git merge bug git branch -d bug 查看当前有哪些分支 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）

四、Git 远程仓库使用

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

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

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

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

自己搭建：

• GitLab。

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

1. 在码云上创建版本存储仓库

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

   

2. 创建版本存储仓库

   

   

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

   

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

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

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

   1. git remote add 添加存储仓库地址

   git remote add origin https://gitee.com/用户名/仓库名.git 
   

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

   2. git push 把本地仓库推到远程存储仓库中

   git push origin master 
   

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

   

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

   

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

   

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

   git push origin dev 
   

   

   

   3. git clone 把代码从版本存储仓库下载下来

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

   

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

   

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

   

   4. git pull

   我们就可以通过以下流程进行切换到 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/用户名/仓库名.git
   2. 在公司本地代码推送远程 cd 项目目录 git remote add origin https://gitee.com/用户名/仓库名.git git push origin master git push origin dev 继续写代码 git add . git commit -m '提交记录' git push origin dev
   3. 到家下载代码 git clone https://gitee.com/用户名/仓库名.git 或创建目录 cd 目录 git init git remote add origin https://gitee.com/用户名/仓库名.git git pull origin master 创建 dev 分支 git checkout dev git pull origin dev 继续写代码 git add . git commit -m '提交记录' git push origin dev…

   ---

五、Git 开发规范

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

答：为每个人创建一个分支 master/dev 分支 review 分支 (组长做代码的 review) 开发员 1 的分支 开发员 2 的分支 每个开发员把自己分支的代码都合并到 review 分支，组长负责检测 review 分支有没有问题，没有问题之后在合并到 dev

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

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

• 项目的创建者添加自己为合作者，共同开发，就可以为该项目提交代码。
• 创建组织，邀请成员（可以在 setting 中进行设置相关权限）。

1. GitHub 的 fork 和 pull request

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

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

2. Git 之 gitignore

• 创建 gitignore 文件

在 gitignore 中填写或略的文件名（有很多.txt 文件都忽略，就可以写成 *.txt）

把忽略的文件名写到 gitignore 中，再次提交 git status 自动检测就已经没有检测到 test_ignore.py 文件啦，所以在提交的时候后面也不会有这个文件。

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

3. Git tag

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

·建议：

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

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

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

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

参考：

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