团队开发者git仓库工作手册
团队开发者git仓库工作手册
本文因为学校软件工程课程需要团队合作，所以就涉及到多人维护gitee仓库，作为整个小组的组长，需要制作整个工作流程的一个具体指南和规则，所以有了本文。
具体的git工作流程在git工作流程-CSDN博客中。
1. 分支说明
我们的远程仓库设置有三个主分支：
- master 分支：稳定版本，用于正式发布环境，只能通过合并 release 分支更新
- develop 分支：最新开发版本，开发人员基于此分支进行持续开发
- release 分支：测试版本，测试人员基于 develop 分支创建
2. 开发流程
2.1 功能开发分支规范
我们规定，开发者每次开发一个新功能，需要在远程仓库中以develop分支为起点创建一个新分支，新分支的命名规则如下：
分支命名规则：feature/username_yyyyMMdd_feature-name
示例：
feature/zhangsan_20241021_user-login
feature/lisi_20241022_payment-integration
操作步骤：（具体操作看文章开头的链接）
# 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>
示例：
git commit -m "feat: 添加用户注册功能"
git commit -m "fix: 修复登录页面样式错位问题"
git commit -m "docs: 更新项目安装说明"
git commit -m "refactor: 重构用户服务类结构"
详细格式（可选）：
<type>(<scope>): <description><body><footer>
示例：
git commit -m "feat(auth): 实现微信登录功能- 集成微信开放平台SDK
- 添加登录回调处理
- 完善错误处理机制Closes #123"
应用建议：
# 推荐做法：
git commit -m "feat: 实现购物车添加商品功能"
git commit -m "fix: 修复订单金额计算错误"# 不推荐做法：
git commit -m "更新代码"
git commit -m "修复bug"
git commit -m "又改了一点"
3. 合并流程
总结：
开发人员觉得可以进行合并的时候，本人建议：
- 为了防止在你合并之前，develop分支已经有人修改了，你合并可能会发生冲突，所以我建议你先把远程仓库中的develop分支中的内容进行拉取，然后在本地仓库中，将develop分支中的内容合并到你创建的新分支中。
- 如果有冲突内容，就现在你的分支处理好。
- 如果冲突内容你一个人无法解决，则联系相应的开发人员，两个人联系并处理好冲突内容。
- 如果有冲突内容，就现在你的分支处理好。
- 完成上一步后，就是将你创建的feature分支合并到远程仓库中的develop分支中：
- 先在gitee新建一个PullRequest，在PullRequest中说清楚：你做了什么事情？做这件事情的目的是什么？然后详细描述你具体干了什么，比如：
- 新建文件：新建的这个文件是干什么用的？这个文件里是什么功能？实现的具体的思路是什么？
- 修改文件：修改了文件什么地方？为什么要修改？修改前后的区别是什么？思路是什么？
- 删除文件：删除了什么文件？为什么要删除这个文件？
- 当开发人员提交PullRequest后，管理人员需要在1天时间内审查完成，并完成合并，如果有问题，立刻和提交PullRequest的人员交流并处理。
- 先在gitee新建一个PullRequest，在PullRequest中说清楚：你做了什么事情？做这件事情的目的是什么？然后详细描述你具体干了什么，比如：
下面是详细流程：
3.1 预合并准备
在发起 Pull Request 前：（我还没完全写完）
# 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 描述模板：
## 变更类型
- [ ] 新增功能
- [ ] 修复问题
- [ ] 优化调整
- [ ] 其他## 功能描述
（简要说明这个 PR 的目的）## 修改内容
- 新增文件：xxx（说明用途和功能）
- 修改文件：xxx（说明修改原因和前后区别）
- 删除文件：xxx（说明删除原因）## 实现思路
（描述具体的实现方案和技术选择）## 测试情况
- [ ] 已自测
- [ ] 影响范围评估
- [ ] 测试结果：（简要说明）## 关联事项
（关联的需求或问题编号）
3.3 代码审查要求
审查人需在 1 个工作日内 完成审查，关注：
- 代码风格统一性
- 逻辑正确性
- 是否包含调试代码或敏感信息
- 必要的文档更新
- 测试覆盖情况
4. 测试与发布流程
4.1 测试分支管理
分支命名规则：release/version_publishTime
示例：
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
- 小版本合并到develop分支
- 大版本合并到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. 常用命令参考
# 查看分支情况
git branch -av# 查看远程分支
git branch -r# 删除已合并的本地分支
git branch --merged | grep feature | xargs git branch -d# 删除远程分支（谨慎使用）
git push origin --delete feature/branch-name