版本控制

Git是一个分布式版本控制软件

什么是版本控制呢？

一个论文的例子：

这是最开始没有版本控制用文件夹做文件管理的状况。

再然后进入了本地版本控制的时代，这个时候你就不会像上面一样看到那么多文件了，你只会看到一个文件。而你之前版本的文件被版本控制软件给保存到了某个地方。

再然后，如果是一个团队做多人协作的开发，上面这种本地版本控制也就不适用了，因为每个人电脑上版本都不一样，这个时候就出现了集中式版本控制软件，最有代表的就是SVN.

但是问题又来了，如果这个时候A和B断网了，连接不到中心服务器，或者这个中心服务器挂了，那相当于就没办法做版本控制了。
所以就进入了现在的分布式版本控制软件时代。

那这个分布式的和上面集中式的区别在哪儿呢？
对于集中式版本控制软件来说，如果一个人去中心服务器拿代码，那么他实际上只拿到了一个版本的代码，也就是说是只有V3没有V1、V2的，而分布式的话你是可以拿到整个V1、V2、V3的。
即使中心服务器挂了，每个人也可以在自己的电脑上实现版本控制，之后再推送到中心服务器上。

为什么要做版本控制呢？

可以回退到之前的版本
比如假如新加的功能有问题或者是不喜欢，这个时候就能方便快速地回退到之前的版本
TODO

怎么做版本控制？

做版本控制其实就是用Git管理项目所在的文件夹
步骤：

进入需要被管理的文件夹
对文件夹初始化（初始化做了什么？）
文件夹中会出现.git的隐藏文件
管理目录下的文件状态
使用命令 git status来查看当前文件夹的状态，是否有文件untracked
管理指定文件
使用命令 git add 文件名来将untracked的文件提交到暂存区或者使用 git add . 来将所有untracked文件提交到暂存区
生成版本
使用命令 git commit -m '' 来将暂存区的文件生成一个版本
查看版本记录
使用命令 git log 查看所有版本

Git的三大区域

工作区、暂存区、版本库

版本控制之快速回滚

git reset --hard 长长的版本号。
那如果在我回滚之后，我又想回到没有回滚之前的那个版本怎么做呢？
先使用 git reflog 查看到全部的记录
然后再使用 git reset --hard 版本号回到对应的版本

分支

在查看版本记录的时候，多个版本之间是用指针来建立联系的。
其实在下一版本中只会保存修改过的代码，而没修改过的代码下一版本会用指针指向上一版本。
这几个就相当于我们的主干。
那如果假设我们正在开发v4版本，开发了一半，这个时候V3版本出现了Bug，需要马上去修复Bug，那我们正在开发的V4版本怎么办呢？
这个时候就需要分支这个概念，每一个分支都是一个隔离的环境，可以在上面做自己的事情，而不影响主干。
使用 git branch 查看当前分支
使用 git branch dev 创建dev分支
使用 git checkout dev 切换到dev分支，在上面完成开发之后，git checkout main切换到主分支，并不会对主分支造成任何影响。
一般认为main分支为线上的代码，其他分支用来开发自己负责的功能，修复bug什么的。
使用git merge bug完成bug分支与主分支的合并
使用完的分支如果不需要了，使用 git branch -d bug 删掉bug分支
然后继续转回dev分支开发商城功能，完成之后与主分支合并，这个时候会产生一个冲突。因为开dev分支的时候是没有修复bug的，而现在的主分支bug已经被修复了，如果合并就会产生冲突。
这个时候需要手动解决一下冲突，再提交代码。

工作流

最简单的工作流
主分支上只保留稳定运行的线上版本，而开发是在dev分支上做的，还有各种测试版本都在dev上做。

GitHub

什么是GitHub

GitHub就像是百度云，只不过我们是在上面存放代码。之前我们的操作都是在我们的本地电脑上，GitHub是一个云端的仓库可以存储我们的代码。
个人和小公司一般直接使用GitHUb的仓库，大公司可能会通过GitLab搭建自己的仓库

如何使用GitHub

注册账号
创建仓库
把本地代码推送到远程仓库
使用命令 git remote add origin https://github.com/Lyle-Lyle/dbHot.git 给仓库起别名，别名只用添加一次就行了
git branch -M main
git push -u origin main 向远程仓库推送代码
把dev分支也推送到远程仓库 git push -u origin dev
把代码从仓库拉下来（所有的分支都included了）
git clone 远程仓库的地址

在公司开始工作了

现在我已经在公司坐好了，并且已经把代码从远程仓库拉下来了，那接下来就是开始写代码了。
首先是把main分支给合并到dev分支来，这样dev分支就和main分支的代码一样了。

我又回到家了，想继续写代码

回到家，使用 git pull origin dev 把今天在dev分支上写的最新的代码拉到本地。

开发完毕，需要上线了

把dev分支合并到main就行了，再推送到远程仓库。

发生意外，在公司忘记推送代码，就回家了

如果我回家了发现自己没有推送代码，而我又在家开发了一些功能并推送到远程仓库，那么第二天从远程仓库拉取代码的时候可能会发生冲突，需要手动解决

补充

git pull origin dev 可以拆分为两个命令 git fetch origin dev 先把代码拉到本地版本库再用 git merge origin/dev 合并

rebase（没太懂）

用于把多个提交记录整合成一个

假如你正在开发一个功能，你可能每天开发一些之后都会提交一下，这样到最后完成的时候，你会有多个提交记录，但对于老板或者别人来说，中间的这些提交记录是没太大意义的，其他人可能只想看到
第一次和最后一次的记录。
使用命令 git rebase -i HEAD~3 表示从当前往前的3条记录合并为1条

注意：
合并记录最好不要包含已经提交到远程仓库的记录。

用于合并分支

git log --graph
git rebase

多人协同开发之gitflow工作流

现在还是线上代码就是main，然后平常的开发工作都在dev分支上做，但是每个人或一个小团队都会有一个分支，并且都是从dev分支再分出来的，

创建第一版项目并打上Tag

创建第一个main版本并推送到远程仓库，这个时候项目还只有自己一个人
Tag是对那个长长的哈希值的一个简写一个标记

Git和Github