一文读懂Git版本控制【全流程详解版】

01-Git分布式版本控制软件

版本控制经历的阶段：
1- 使用文件进行存储，会有很多文件
2- 本地化，始终保留最新的版本，其他进入历史文件区
3- 集中式版本控制，最典型的就是SVN

4-分布式版本控制

分布式与集中式的区别：分布式在中心及每个终端均有所有版本，而集中式只在中心存储所有版本，每个终端只有一个版本。

02-安装Git

安装过程参考相关博客，不再赘述。官网链接Git

需要注意：Git安装好了只是在本地电脑进行版本控制，通常中心仓库则需要远程推送，一般为Github，Gitee，Gitlab。

安装成功的检查方式是右键出现相应的git bash项且使用git --version可查看git版本。

git的配置文件有三种：

1. 项目配置文件
   git config --local user.name ‘xxx’
   git config --local user.email ‘xxx’
2. 全局配置文件
   git config --global user.name ‘xxx’
   git config --global user.email ‘xxx’
3. 系统配置文件
   git config --system user.name ‘xxx’
   git config --system user.email ‘xxx’
   对于系统配置文件来说如果更改需要root权限

03-Git引入

以下首先是一个人写代码无协作情况：
创建一个文件夹，后续所有项目代码均存储在该文件夹中。

Git管理文件夹的基本流程为：进入要管理的文件夹->初始化->管理->生成版本

• 需要管理的文件夹中右键选择git bash
• 使用命令git init进行初始化，完成后其中生成的.git文件夹会管理所有的版本
• 使用命令git status检测当前文件夹里的文件状态(管理起来的变绿，未管理为红色)，若有文件修改，用git status可以检测到
• git add ‘要管理的文件名‘ ，管理单个文件
• git add . 管理所有的文件
• git commit –m “提交说明语句” ，创建版本
• git log，查看版本记录

可能需要注意的点：
第一次运行的时候可能会报错，因为要设置配置信息，配置邮箱和用户名
git config --global user.email “xxx”
git config --global user.name “xxx”
配置好了就不会出错了，配置仅需一次即可。

git在管理文件的时候有时候需要忽略一些文件
vim编辑.gitignore文件，例如：

• a.h b.h则代表让git不检测它们
• *.h代表任意以.h结尾的文件都不管
• 也可以将.gitignore文件本身添加进去
• files/ 代表将files下的文件忽略
• !a.h 代表除a.h之外

一般可以在github中搜gitignore复制对应编程语言的文件夹进行配置忽略文件

04-Git三大区域及命令图览

回滚使用场景：
假设自己开发了第1个版本，紧接着又开发了新的第2个版本，加上新功能之后程序有改动，则重新提交后可通过git log查看记录。由于又有了新的想法，加上全新的功能之后重新提交新的第3个版本。
但由于某些不可控原因，第3个版本的功能需要下架cut掉，这时候就需要回滚。命令如下：
git reset --hard 版本号
再使用git log查看记录发现第3个版本的提交记录不见了，使用git reflog可查看第3个版本，同样使用git reset --hard 版本号可以返回第3个版本。

注意：

• git checkout ‘版本提交ID’ 相当于切换分支临时查看，不会改变分支历史，切换之前也应当提交当前代码再切换，否则当前代码将丢失，如果不想提交，可使用git stash将更改暂存，回来之后再使用git stash pop恢复相应更改；
• git reset --hard ‘版本提交ID’ 是永久性地更改分支到指定提交，清除之后的提交和未提交的更改，谨慎使用。

05-分支及工作流

分支，顾名思义，有点像树枝上的分叉。不同人开发不同的版块，开发完之后再合并。

git merge ‘要被合并的分支’ ，合并分支，需要注意的是要切换到主分支再使用该命令将从分支合并到当前主分支上。

工作流：一般情况下开发的放dev分支上，稳定运行版放到master分支上。

紧急修复线上bug的思路

假设现在开发的C3已经正式上线正常运行了，接下来计划开发C4功能，但是C4功能的开发预计需要2个月，开发过程中发现主分支master上出现了bug。那么此时需要保留此分支，创建C5分支紧急修复让程序功能不影响正常使用。等开发完后合并到主分支，一般主分支叫master，当然主支和分支都可以重新命名，如上述C4起名dev为开发分支，C5起名bug为修复bug分支。

默认主干线为master，每个分支的意义在于代码相互隔离。

紧急修复线上bug的具体过程

git branch dev 创建分支dev
git checkout dev 切换到dev分支
这时候出现bug需要紧急修复，切换回master分支创建新的分支
git checkout master 切换回master分支
git branch bug 在master分支下创建新的bug分支
git checkout bug 切换到bug分支

这样就实现了分支与分支之间的代码隔离，一般认为master为线上正式运行的版本

git merge bug 当bug修复完了就可将其合并到master分支上了，需要注意的是当前的位置为master分支，merge后面跟的是被合并的分支。
git branch –d bug bug分支合并完了就可以删掉它了

再次回到dev分支继续开发。假设现在dev分支也开发完了，那么回到master分支再进行合并，但是理论上会出现冲突(conflict)，出现冲突的时候手动解决冲突，再次合并。

06-线上托管

说白了就是将本地的版本托管放到了线上，通常有GitHub，Gitee，Gitlab。Gitlab可以自己公司搭建，相当于是软件，公司需要服务器。
git remote add origin 远程仓库地址
给远程仓库起别名，这里一般起的别名就叫origin，其实就相当于是代表相应的地址

git push –u origin 分支
向远程推送代码，-u代表的是默认为origin的地址

git clone 远程仓库地址
若是向从云端拉下来代码到本地则需要用该条指令，一般是空文件夹的情况(其内部已实现git remote add origin 远程仓库地址)

07-两地代码同步

在公司进行开发
git checkout dev 切换到dev分支进行开发
git merge master 将master分支合并到dev分支(仅一次)，紧接着开始开发和修改代码
git add .
git commit –m ‘work in company ver1‘
git push origin dev
到此为止，在公司的开发就完成了，且已经将代码推送至云端仓库

回到家中继续写代码
git checkout dev 切换到dev分支进行开发
git pull origin dev 将云端的代码拉下来
在家里继续开发或修改代码
git add .
git commit –m ‘work at home ver1’
git push origin dev
整个开发过程完毕，接下来需要进行上线

git checkout master
git merge dev
git push origin master
将dev分支合并到master分支进行上线

git checkout dev
git merge master
git push dev
把dev分支也推动到云端仓库

假设现在在公司写了一部分代码但是晚上走的时候忘记提交了，但在家又继续开发其他功能，这时候就需要考虑两个版本的合并问题。
在家写完代码并提交到远程，第2天到公司，将远程的代码拉下来，这时候就会发现，如果是公司本地版本没有的但是现在有了就正常合并，但如果某个文件公司的版本上有一部分，远程的版本有另外一部分，这时候提示信息会显示有文件合并出现冲突，打开文件会发现两段不同的地方都被融入了，这时候就需要手动去解决冲突。

说明：
git pull origin dev相当于两句指令：git fetch origin dev + git merge origin/dev

• git fetch origin dev：从名为origin的远程仓库中拉取dev分支的更新，这个命令会将远程仓库中的最新代码下载到本地仓库中，但不会自动将代码合并到你的当前工作分支；
• git merge origin/dev：将远程仓库中的dev分支合并到当前工作分支中，这个命令会将远程仓库中的代码与你本地的代码合并，产生一个新的合并提交。
• 故git pull origin dev等价于上述两个命令的组合，可以将远程仓库中的更新代码拉取到本地仓库，并自动合并到当前分支中。

08-Rebase变基

rebase中文意思“变基“，主要的本质作用是帮助代码的git提交记录变得简洁，分为三种情况案例。

应用场景一

第一种，也是最简单的，假设在公司做开发，在某个分支开发有若干个版本，中间的若干个版本对于其他人来说是没有意义的，且提交的记录非常多，rebase可以将多个提交记录整合成一个记录。示例过程如下：

mkdir pro_rebase 创建一个新的目录
cd pro_rebase/ 切换到新目录下
ls 查看相应目录下的文件
git init 对新建的文件夹进行初始化
touch 1.py 创建一个新文件
git status 查看文件状态
git add . 将待提交文件放到暂存区
git commit –m ‘v1’ 先提交相应的版本
git log 查看提交记录
ls 查看路径下的文件
git log 查看提交记录
touch 2.py 再创建一个新文件
git add . 将文件提交到暂存区
git commit –m ‘v2’ 提交第2个版本
touch 3.py 再创建一个新文件
git add . 将文件放至暂存区
git commit –m ‘v3’ 提交第3个版本
touch 4.py 再次创建新文件
git add . 将文件放至暂存区
git commit –m ‘v4’ 提交第4个版本
ls 查看文件列表
git log 查看提交记录

接下来就可以通过rebase命令来整合几条提交的记录
git rebase –i 版本号v2
这条指令表示的是将提交记录从版本号v2到当前的版本号全部合并(因为当前的版本号为v4)
还有一种方式
git rebase –i HEAD~3
这条指令表示的是将离当前最近的3条记录合并起来。(HEAD后面的符号是波浪号)

注意：使用git rebase命令修改提交历史时可能会破坏已经存在的分支和合并记录，操作之前务必备份好代码。

应用场景二

如果想要将某个分叉强插到主分支中，也可以使用rebase。开发过程中如果添加分支进行开发，后续再想要进行合并的话就会出现分叉，如果不想要分叉，即可将分叉强插到主分支中，从而使得归并记录变成1条，此时的提交记录就没有那么详细了，这算是一个弊端。接下来通过实例进行说明：
git log 发现已经现有两条提交记录
git branch dev
git checkout dev
touch dev.py
git add .
git commit –m ‘dev branch’

git log会发现此时多了一条分支branch

touch master.py
git checkout master
git add .
git commit –m ‘master function’
git log可以看到master分支上也多了相应的提交记录

按照之前的做法，可以直接将dev分支的代码合并到master分支上
git branch
git merge dev 将dev合并到master分支，在文件中写入记录名‘merge dev to master‘，键入:wq保存退出。
git log可以看到在当前的master分支上有刚刚合并的‘merge dev to master‘，有’master function’，有’dev branch’。可以看到整个记录也是清晰地以线性的形式进行展现，实际上还可以以图形化的方式进行展现
git log –-graph 显示的东西更清晰，但详细信息还是有点多，可以再进行简化一下
git log –graph –pretty=format:”%h %s” 这句指令的意思是将以图形化的方式展示提交历史记录，每个提交显示它的简短哈希值和简述信息。这样会让显示的消息更加简洁。

以上是使用merge的方法进行合并的，但是使用rebase也可以。

git branch
git checkout dev
git merge master
ls

接下来在dev分支上继续进行开发
touch dev1.py
git add .
git commit –m ‘dev branch commit 1’
切换回master分支继续进行开发
git checkout master
touch master1.py
git add .
git commit –m ‘master 111’
接下来使用rebase的方法对两条分支进行合并，先切回到dev分支

git checkout dev相当于是第一步
git rebase master将master变基，意思是将master变为基本的树干，把其他的合并过来
git checkout master将分支切换回master
git merge dev执行这条命令之后就会出现是一条线性的记录了
git log –graph –pretty=format:”%h %s” 用该条指令可以进行验证

应用场景三

回归到三端，家 公司 云端，当本地代码有更新同时拉下来的云端代码也有更新的时候，这时候拉下来实际上是执行了无形的合并，当二者不冲突的时候自动合并，当有冲突的时候解决冲突后进行合并。这个过程会产生分叉，那么如何让它不产生分叉呢？
不执行git pull命令，先执行git fetch命令
原来是使用git merge，现在就不使用git merge了，因为这样的话就跟git pull一样了。这次使用git rebase指令。假设本地的分支为dev，云端的为origin，则指令为git rebase origin/dev，这样的话就不会产生分叉了
即指令的转变为：
从git pull origin dev到git fetch origin dev + git rebase origin/dev

注意事项：
在执行git rebase的时候有可能产生冲突，去解决冲突，一般会有提示。解决完冲突之后继续执行git rebase –- continue

09-多人协同开发GitFlow工作流

思路

组长创建dev分支，将代码从master分支拉下来，master分支为线上稳定版本，dev为开发分支。每个成员有自己的分支，且分支是从dev拆出来的。每个人在自己的分支上开发及提交。有一天功能开发完了，需要组长审核，组长review(代码检查)，通过了才能合并，组长检查完，正式的流程应该还有预发布分支，即release分支，测试或写文档，包括修复一些小bug，修复完成后才能正式上线。
修复完正式上线就可以将功能A分支删除了(一般以功能为分支名的话不能进行重复使用，留着没用)
上述过程对于功能B分支也是同样如此。
以上就是正规的gitflow工作流，当然实际情况下可能有的环节会被省去。
同样地，假设功能A和功能B分支在开发的过程中出现bug了，建立相应的bug分支。

创建初始项目和版本

cd cooperate_file/ 切换到指定的目录下
ls 查看文件列表详情
touch app.py 创建新文件
git init 对文件夹进行初始化
git add . 将文件夹中的文件都添加至暂存区
git commit –m ‘project basic function’ 再将其推送到github，进入到GitHub官网的仓库，点击new repository生成新的仓库，若需要别人协作则可点击settings里的collaborators进行邀请，这样的方法一般适用于个人项目。

公司一般先创建组织再进行管理。
在GitHub上先创建组织，完了之后再创建仓库进行邀请成员，实际上在git中版本为一长串的那个编码，但正常来说版本类似于V1.2这样的形式。
一般基本版本号用tag进行控制
git tag –a V1 –m ‘第1个版本‘ 这条指令会在当前分支的最新提交上打上要给名为V1的tag，并且附上一条标签信息’第1个版本’。
git log
git push origin –tags
同样地，将tag也可以推送到云端，这时候就可以通过简单的版本号进行管理了。

邀请成员参与开发

组长需要先创建一个dev分支
git checkout –b dev 创建dev分支并切换到dev分支
git branch
git push origin gev 将dev分支推送到远程

邀请成员，member，对方同意即成功。

组织默认只读不可提交，项目也可加入成员并设置写的权限，当成员加入之后需组长为其创建分支
cd 总目录
ls
git checkout dev
git checkout –b ddz
git branch
紧接着成员接管开始开发，开发完需要组长进行review。

代码Review

应该做review，组长来做，用pull request或merge request来实现
先做配置
settings—branches—add rule—dev中选中require pull request reviews before merging
接下来成员找组长合并，提交一个pull request，选择哪个分支合并到哪个分支
e.g: base:dev<-compare:ddz，同时可以加个标题，如“***功能完成“，组长端review，同意即合并。开发完之后可删除该分支，最新的代码已在dev分支。组长仍需拉最新的可在本地同步。

测试上线

在dev分支上创建release分支，测试看是否有问题，一般不增加新功能，只修复小bug，测试人员同样提交pull request，组长确认之后可合并到master，不同release分支可用指令进行切换
git branch –d release
git pull origin master
git tag –a V2.0 –m ‘第2版上线’
git push origin –tags

10-给开源项目贡献代码

1. 先fork，这个项目会到自己的项目库中
2. 在自己的仓库中修改代码，按照之前的流程进行开发提交等
3. 给源代码作者提交修复bug的申请，即new pull request，作者以同样的方式进行审核，通过即会合并到开源代码中。