团队开发者git仓库工作手册

本文因为学校软件工程课程需要团队合作，所以就涉及到多人维护gitee仓库，作为整个小组的组长，需要制作整个工作流程的一个具体指南和规则，所以有了本文。

具体的git工作流程在git工作流程-CSDN博客中。

1. 分支说明

我们的远程仓库设置有三个主分支：

master 分支：稳定版本，用于正式发布环境，只能通过合并 release 分支更新
develop 分支：最新开发版本，开发人员基于此分支进行持续开发
release 分支：测试版本，测试人员基于 develop 分支创建

2. 开发流程

2.1 功能开发分支规范

我们规定，开发者每次开发一个新功能，需要在远程仓库中以develop分支为起点创建一个新分支，新分支的命名规则如下：

分支命名规则 ：feature/username_yyyyMMdd_feature-name

示例：

bash 复制代码

feature/zhangsan_20241021_user-login
feature/lisi_20241022_payment-integration

操作步骤：（具体操作看文章开头的链接）

bash 复制代码

# 1. 从 develop 分支创建并切换到新分支
git checkout -b feature/zhangsan_20241021_user-login origin/develop

# 2. 推送分支到远程仓库并建立关联
git push -u origin feature/zhangsan_20241021_user-login

# 3. 日常开发提交
git add .
git commit -m "feat: 实现用户登录功能"
git push

注意：当创建的新分支已经完成其相应的任务后，或者新分支已经无用时，就尽快的将其删除掉。

2.2 提交信息规范

使用约定式提交格式：（也就是你commit的时候信息规范）

feat: 新功能
fix: 修复问题
docs: 文档更新
style: 代码格式调整
refactor: 重构代码
test: 测试相关
chore: 构建过程或辅助工具变动

示例：

复制代码

feat: 新增用户登录功能
fix: 修复登录页面的验证码错误
docs: 更新 API 接口文档

具体用法：

基本格式：

复制代码

<type>: <description>

示例：

bash 复制代码

git commit -m "feat: 添加用户注册功能"
git commit -m "fix: 修复登录页面样式错位问题"
git commit -m "docs: 更新项目安装说明"
git commit -m "refactor: 重构用户服务类结构"

详细格式（可选）：

复制代码

<type>(<scope>): <description>

<body>

<footer>

示例：

bash 复制代码

git commit -m "feat(auth): 实现微信登录功能

- 集成微信开放平台SDK
- 添加登录回调处理
- 完善错误处理机制

Closes #123"

应用建议：

bash 复制代码

# 推荐做法：
git commit -m "feat: 实现购物车添加商品功能"
git commit -m "fix: 修复订单金额计算错误"

# 不推荐做法：
git commit -m "更新代码"
git commit -m "修复bug"
git commit -m "又改了一点"

3. 合并流程

总结：

开发人员觉得可以进行合并的时候，本人建议：

为了防止在你合并之前，develop分支已经有人修改了，你合并可能会发生冲突，所以我建议你先把远程仓库中的develop分支中的内容进行拉取，然后在本地仓库中，将develop分支中的内容合并到你创建的新分支中。
- 如果有冲突内容，就现在你的分支处理好。
  - 如果冲突内容你一个人无法解决，则联系相应的开发人员，两个人联系并处理好冲突内容。
完成上一步后，就是将你创建的feature分支合并到远程仓库中的develop分支中：
1. 先在gitee新建一个PullRequest，在PullRequest中说清楚：你做了什么事情？做这件事情的目的是什么？然后详细描述你具体干了什么，比如：
  - 新建文件：新建的这个文件是干什么用的？这个文件里是什么功能？实现的具体的思路是什么？
  - 修改文件：修改了文件什么地方？为什么要修改？修改前后的区别是什么？思路是什么？
  - 删除文件：删除了什么文件？为什么要删除这个文件？
2. 当开发人员提交PullRequest后，管理人员需要在1天时间内审查完成，并完成合并，如果有问题，立刻和提交PullRequest的人员交流并处理。

下面是详细流程：

3.1 预合并准备

在发起 Pull Request 前：（我还没完全写完）

bash 复制代码

# 1. 拉取最新的 develop 分支
git fetch origin
git checkout develop
git pull origin develop

# 2. 切换回功能分支并合并 develop
git checkout feature/zhangsan_20241021_user-login
git merge develop

# 3. 解决可能的冲突，测试功能正常
# 4. 推送更新后的分支
git push

3.2 Pull Request 流程

PR 标题格式 ：【类型】功能描述 - 提交人

示例：【功能】用户登录模块 - 张三

PR 描述模板：

markdown 复制代码

## 变更类型
- [ ] 新增功能
- [ ] 修复问题
- [ ] 优化调整
- [ ] 其他

## 功能描述
（简要说明这个 PR 的目的）

## 修改内容
- 新增文件：xxx（说明用途和功能）
- 修改文件：xxx（说明修改原因和前后区别）
- 删除文件：xxx（说明删除原因）

## 实现思路
（描述具体的实现方案和技术选择）

## 测试情况
- [ ] 已自测
- [ ] 影响范围评估
- [ ] 测试结果：（简要说明）

## 关联事项
（关联的需求或问题编号）

3.3 代码审查要求

审查人需在 1 个工作日内 完成审查，关注：

4. 测试与发布流程

4.1 测试分支管理

分支命名规则 ：release/version_publishTime

示例：

bash 复制代码

release/v1.1.0_20241025
release/v1.2.0_20241108

版本号规范（语义化版本）：

v1.0.0：正式发布版本
v1.1.0：小版本（新增功能）
v1.1.1：补丁版本（修复问题）

发布周期：

每周发布小版本
每两周发布大版本

4.2 测试流程

测试负责人基于 develop 分支创建 release 分支
在 release 分支上进行测试
发现的问题在 release 分支上直接修复，或由开发人员创建分支修复
测试完成后，release 分支合并到 master 和 develop
1. 小版本合并到develop分支
2. 大版本合并到master分支

5. 紧急修复流程

分支命名规则 ：hotfix/username_yyyyMMdd_issue

示例：hotfix/zhangsan_20241021_login-bug

操作流程：

基于 master 分支创建 hotfix 分支
紧急修复问题
测试验证
合并到 master 和 develop 分支
打上版本标签

6. 团队协作规范

6.1 冲突解决

合并前必须解决所有冲突
复杂冲突需与相关开发人员共同解决
禁止强制推送主分支

6.2 代码审查责任

提交人：确保代码质量，提供清晰的 PR 描述
审查人：及时审查，提供建设性反馈
项目经理：协调资源，确保流程顺畅

6.3 沟通机制

每日站会同步进度
PR 中的问题及时在团队群内沟通
重大架构变更需团队讨论

7. 常用命令参考

bash 复制代码

# 查看分支情况
git branch -av

# 查看远程分支
git branch -r

# 删除已合并的本地分支
git branch --merged | grep feature | xargs git branch -d

# 删除远程分支（谨慎使用）
git push origin --delete feature/branch-name