家园工作室Git规范及实例

2018/05/20

转自 家园项目Git规范-V2
家园工作室Git仓库-git.ncuos.com

规范制订背景

• 家园项目日渐增多，每个项目使用的Git开发方式都不一样，给跨项目合作与维护带来了一定程度上的困扰。
• 统一 Git Flow，提高开发效率，向正式互联网公司的开发模式看齐。

具体内容

• 有且仅有一个主分支，master分支
• 两种临时分支，功能（feature）分支与修补bug（fix）分支
• 如果有明确版本的项目，在发布新版本时打上相应版本tag
• 临时分支合并完成后就删除，不做保留

1. master分支

• 代码主分支
• 不允许直接推送代码到master分支，所有新功能与BUG修复均从master分支checkout新分支，完成后提PR并合入
• 确保master分支质量，不允许出现master分支无法部署的低级问题

2. feature分支

• 用于开发新功能，完成后合并回master分支
• 命名以 feature/新功能名字 为准，不使用任何无意义的单词 (示例：feature/login, feature/topic-editor)
• 一个分支只完成一个功能
• 合并前确保能正常编译或者部署

3. BUG修复分支

• 用于修复产品bug，完成后合并回master分支
• 命名以 fix/bug名称 为准，不使用任何无意义的单词 (示例：fix/topic-editor fix/login-502)
• 一个分支可修复多个BUG
• 合并前确保能正常编译或者部署

4. Tag版本标签

• 适用与当前项目按明确版本对外发布的，如App
• 发布正式版本时，需打上Tag版本号，并推送到远端

5. 文档

• 项目文档统一放置于docs文件夹
• 后端部分，需要包含部署，Api等文档
• 前端部分需要包含编译构建流程文档

6. 其它事项

• 项目中必须有.gitigore，并屏蔽编辑器自定义配置/编译文件/依赖文件等
• 不允许提交无意义的commit message，如aaa，bbb等信息
• 勤commit，修复一个bug，完成部分新功能即commit一次，不要一次提交包含多个功能或者十几个改动等

以上为规范，下面举一个实例(昨天第一次修BUG)

1.发现BUG,重新克隆一个仓库到本地;
2.在目录下打开GIT BASH, 并输入git checkout -b bug/poor_assess 创建一个新分支;
3.在新分支下对代码进行修改;
4.Git add 然后摁几下Tab, Git帮你自动定位到修改过的文件, 并回车add;
5.git commit -m "Deleted an extra label";
6.在远程仓库也建立一个bug/poor_assess分支;
7.git push origin bug/poor_assess;
8.然后在远程仓库提出一个Pull Request, 添加管理员到评审者中, 请求别人合并你的分支到Master;
9.大功告成.

以上 2018/05/20