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

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

引用

CSDN

1.

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

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（热修复分支）

功能开发流程

1. 程序员在开发一个新功能时，需要从master分支中拉取并创建一个新的分支，命名方式为feature_XXX，并在这个分支中开发新的功能。
2. 当该功能开发完成后，会从这个feature_XXX分支merge到dev分支中进行自测。
3. 自测通过后再将自己的feature_XXX分支merge到test分支中交给测试同学进行提测。
4. 当测试通过后，将自己的feature_XXX分支merge到master分支中，再从master分支merge到pre分支，并将这个分支的代码部署发布实测，如果实测没有问题，再将master分支的代码部署发布出去。

Bug修复流程

当发现bug的时候，需要从master分支拉取并创建一个新的分支，命名方式为hotfix_XXX。
hotfix_XXX分支中的bug修复完毕后在pre中部署上线，如果实测没有问题，再将pre分支merge到master当中发布，完成bug的修复。

分支管理注意事项

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

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