家园工作室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