git 版本控制的基本流程

git介绍：Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

git 版本控制的基本流程:

1.初始化仓库:
使用 git init 命令在本地创建一个新的 Git 仓库。
或者 git clone 从远程仓库克隆一个现有的仓库到本地。

2.添加文件到暂存区:
使用 git add <file> 命令将文件添加到暂存区。
可以使用 git add . 将所有修改过的文件一次性添加。

3.提交更改:
使用 git commit -m "提交说明" 将暂存区的更改提交到本地仓库。
提交时需要添加简要的提交说明,描述这次提交做了哪些更改。

4.查看状态:
使用 git status 命令查看当前工作区和暂存区的文件状态。
可以了解哪些文件被修改了,哪些文件已经添加到暂存区等。

5.查看提交历史:
使用 git log 命令查看提交历史。
可以看到之前的每次提交的 commit 信息、作者、提交时间等。

6.推送到远程仓库:
使用 git push 命令将本地仓库的更改推送到远程仓库。
如果是首次推送,需要用 git push -u origin master 关联本地分支和远程分支。

7.拉取远程更改:
使用 git pull 命令从远程仓库拉取最新的更改到本地。
如果本地和远程有冲突,需要手动解决冲突。

git在生产中的版本控制流程

那么git是如何在生产中进行版本控制的？

首先在整个git管理的项目中会分为四个分支：dev（开发分支）、test（测试分支）、pre（预生产分支）、master（生产分支）
会在开发过程中出现若干个feature_XXX分支并行开发，若干个hotfix_XXX分支进行热修复

feature_XXX（个人开发分支）
hotfix_XXX（热修复分支）

程序员在开发一个新功能的时候，需要从master分支中拉取并创建一个新的分支，命名方式为feature_XXX，并在这个分支中开发新的功能。

当该功能开发完成后，会从这个feature_XXX分支merge到dev分支中进行自测。

自测通过后再将自己的feature_XXX分支merge到test分支中交给测试同学进行提测。

当测试通过后，将自己的feature_XXX分支merge到master分支中，再从master分支merge到pre分支，并将这个分支的代码部署发布实测，如果实测没有问题，再将master分支的代码部署发布出去。

当发现bug的时候，需要从master分支拉取并创建一个新的分支，命名方式为hotfix_XXX。

hotfix_XXX分支中的bug修复完毕后在pre中部署上线，如果实测没有问题，再将pre分支merge到master当中发布，完成bug的修复。

在开发与测试环节中为什么我的自测没有问题了，还要从feature_XXX分支merge到test分支呢？
原因：如果组内并行开发其他功能的程序员并没有完成自测，此时提测可能会出现过多的问题，同样的，提测之后也不能从test分支merge到pre分支，因为会有其他程序员提测，这时从test分支进行merge会出现许多问题。

另外需要注意的是所有的特性分支，不允许push，能push的分支只有feature分支。merge是需要审批的，方便代码reivew。