Git版本控制基本流程与生产环境应用

Git版本控制基本流程与生产环境应用

引用

CSDN

1.

https://blog.csdn.net/Jilit_jilit/article/details/139386861

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

初始化仓库

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

添加文件到暂存区

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

提交更改

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

查看状态

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

查看提交历史

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

推送到远程仓库

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

拉取远程更改

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

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

在生产环境中，Git通常会管理以下四个分支：

• dev（开发分支）
• test（测试分支）
• pre（预生产分支）
• master（生产分支）

在开发过程中，会并行创建多个feature分支和hotfix分支：

• feature_XXX（功能开发分支）
• hotfix_XXX（热修复分支）

功能开发流程

1. 程序员从master分支拉取并创建一个新的feature分支（命名方式为feature_XXX），在该分支中开发新功能。
2. 功能开发完成后，将feature分支合并到dev分支进行自测。
3. 自测通过后，将feature分支合并到test分支，由测试人员进行测试。
4. 测试通过后，将feature分支合并到master分支，再从master分支合并到pre分支进行实测。
5. 实测无误后，将master分支的代码部署发布。

Bug修复流程

1. 发现bug时，从master分支拉取并创建一个新的hotfix分支（命名方式为hotfix_XXX）。
2. bug修复完成后，在pre分支中部署上线。
3. 实测无误后，将pre分支合并到master分支并发布，完成bug修复。

分支管理策略

• 所有特性分支不允许直接推送代码，只能通过merge方式合并。
• merge操作需要经过审批，以方便代码审查。

为什么需要从feature分支merge到test分支？
原因在于：

• 如果组内并行开发其他功能的程序员没有完成自测，此时提测可能会出现过多的问题。
• 提测之后也不能从test分支merge到pre分支，因为会有其他程序员提测，这时从test分支进行merge会出现许多问题。

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