Published on

Git协作规范

Authors

📝 Git 协作规范文档

📌 一、分支策略

为了保证代码质量和多人协作效率,采用如下分支结构:

分支名用途
master生产环境稳定版本,仅由项目维护者合并
dev日常开发主分支,合并各功能分支
feature/xxx功能开发分支,由开发者从 dev 拉出
bugfix/xxx非紧急 bug 修复分支,从 dev 拉出
hotfix/xxx紧急修复线上问题,从 master 拉出,修复后合并回 masterdev
release/xxx预发布版本,准备上线阶段使用

🚧 二、分支命名规范

保持语义化、统一的分支命名方式:

feature/login
feature/article-edit
bugfix/form-validation
hotfix/server-crash
release/v1.2.0

🛠️ 三、开发流程

✅ 功能开发流程

  1. 从最新的 dev 分支拉出自己的功能分支:

    git checkout dev
    git pull origin dev
    git checkout -b feature/xxx
    
  2. 提交开发代码(建议提交频繁,描述清晰):

    git add .
    git commit -m "feat: 实现 xxx 功能"
    
  3. 开发过程中保持更新,避免分叉太远:

    git pull --rebase origin dev
    
  4. 功能完成后,合并回 dev

    git checkout dev
    git pull origin dev
    git merge feature/xxx
    git push origin dev
    

📦 四、提交规范

使用 Conventional Commits 格式,统一规范如下:

类型含义
feat新功能
fix修复 bug
docs文档变更
style不影响代码含义的修改(空格、格式)
refactor重构代码(非新增功能/修复 bug)
test增加测试
chore构建过程或辅助工具变更

示例:

git commit -m "feat: 添加用户登录功能"
git commit -m "fix: 修复表单提交失败的问题"

🧪 五、合并规范

  • 所有合并前必须 本地测试通过
  • 优先使用 pull --rebase 解决分叉,提交记录更干净
  • 合并分支需经过 code review(使用 Pull Request 或 Merge Request)
  • 合并到 master 需由负责人执行或审核通过后合并

📅 六、发布上线流程

  1. 确保 dev 分支功能开发完成

  2. 创建 release/vX.X.X 分支,进行最终测试

  3. 测试通过后将 release 合并到 masterdev

    git checkout master
    git merge release/vX.X.X
    git push origin master
    
    git checkout dev
    git merge release/vX.X.X
    git push origin dev
    

📎 七、其他建议

  • 一次提交尽量只做一件事
  • 避免提交格式如 fix somethingupdate 这类模糊信息
  • 多人同时开发前,定期沟通分支进度
  • 每日同步远程 dev 分支,避免长期分叉