企业Git规范
本文介绍企业Git版本控制的逻辑,提高程序代码管理的效率
问题:1. 开发管理乱 2. 代码冲突过多 3. 代码质量过低 4. 代码管理效率不高..只会用不会管理
参考
企业Git 规范的必要性
Git企业级使用规范 - 操作流程
Git企业级使用规范 - 实际操作
1. git 管理流程参考
![](https://img2023.cnblogs.com/blog/1584733/202305/1584733-20230511094329677-538882682.png)
![](https://img2023.cnblogs.com/blog/1584733/202305/1584733-20230511100019928-782515278.jpg)
2.1 分支命名及其作用
-
master分支
主分支,代码可随时上线,属于重要分支。 -
develop分支
代码最新分支,基于master创建,属于重要分支。 -
feature分支
开发人员实际业务开发分支,即开发人员自己的分支,基于develop创建,属于子分支次要分支,编码完成后可通过pull request审计合并,审计通过后将合并至develop分支。
在合并之前要变基到develop分支上 -
release分支
预发布分支,基于develop 分支,属于重要分支。当develop分支修改完成后,develop分支将封存不再改动,然后通过基于develop 分支新建release 分支。release分支修改bug。
重要分支与develop进行合并用merge -
fix分支
修复bug分支
重要分支合并用merge,次要分支合并用rebace
3. 具体操作方法
3.1 分支介绍
master 分支 基于origin创建的
develop 分支 基于master创建的
feature/zhangsan 分支 基于develop创建的
feature/lisi 分支 基于develop创建的
3.2 张三的操作
3.2.1 普通修改代码
- 修改代码
- 提交代码修改commit and message
- 推送至自己的远程仓库feature/zhangsan
3.2.2 与develop合并
- 切换至develop分支,pull拉取最新代码
- 切换回自己的分支feature/zhangsan
- rebace变基至最新的develop分支
- 在平台上(即网页端)提交一个pull request
选择源分支feature/zhangsan 目标分支 develop 分支
3.3 李四的操作
3.3.1 普通修改代码
- 修改代码
- 将自己的代码存储变更
3.3.2 与develop合并
- 切换回develop分支,pull拉取最新代码
- 切换回自己的分支feature/lisi
- 回复存储代码(恢复储藏变更)
- rebace变基至最新的develop分支
解决冲突 - 提交commit 代码
- push推送至自己的远程仓库feature/lisi
- 在平台上(即网页端)提交一个pull request
选择源分支feature/lisi 目标分支 develop 分支 - 审核并合并
3.4 prerelease预发布操作
- 基于develop 分支新建release/1.0.1 分支
- 修改bug并commit 提交变更
- push 推送至 release/1.0.1 远程仓库
- 切换至master分支
- pull拉取更新本地master分支
- 切换回release/1.0.1分支
- 与master进行合并(merge)
- push 推送至 release/1.0.1 远程仓库
- 假设已经可以上线了,在平台上提交一个pull request
选择源分支release/1.0.1 目标分支 master 分支 - 审核并合并
3.5 release发布上线
- 在平台上(即网页端),选择统计->发行版->创建发行版
关于作者:赤诚Xie
版权声明:本博客所有文章仅用于学习、交流和研究目的,欢迎转载,但请注明原文作者及出处。
奥里给!:若您觉得文章对您有帮助,请点赞、关注支持我吧😊。
药药切克闹,👇👇👇下面三连来一套(●'◡'●)
——励志作一个用单片机梳头的乖宝宝