最近要带一批实习生，由于之前本身 Git 提交也不是很规范，这次促使团队需要制定一些代码的规范，目前在编写团队的 Git 代码管理规范，想问一下大家平时都是怎么管理的。
- 分支的建立维护
- tag 的建立
- commit message 的填写格式
……
请大家在以上几个方面谈一谈自己平时工作中的做法以及效果。
大家可以畅所欲言，自由扩展其他方面。
本贴最后更新于 1598 天前，其中的信息可能已经物是人非
相关帖子
- 其他回帖
-
someone27889 • • 1 • 1 评论
因为管理了好多项目,所以这个方面还是研究过一下子 ,主要使用了 GitFlow 规范
分支分为
新功能分支(feature),
修复分支(fix),
补丁分支(hotfix),
版本分支(release),
主分支(master),
开发分支(dev)具体提交格式为
<type>[optional scope]: <description> [optional body] [optional footer]* feat 新功能（feature）表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应） * fix 表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应） * docs 文档（documentation） * style (格式化, 缺失分号等; 不包括生产代码变动) * refactor (重构代码) * perf (性能优化) * test (添加缺失的测试, 重构测试, 不包括生产代码变动) * chore (更新grunt任务等; 不包括生产代码变动)scope：一个可选的修改范围，用于标识此次提交主要涉及到代码中哪个模块。 description：简明扼要描述本次提交的内容，首字母无需大写，结尾不需要使用 `.`。 optional body：详细描述本次提交，比如此次变更的动机，如需换行，则使用 `|`。 optional footer：描述与之关联的 issue 或 break change。commit Message 为 :
fix(module:baseuser): fix username field error BREAKING CHANGE: xxxxxxfeature(module:auth): add oauth2 module BREAKING CHANGE: 原登陆方式发生改变,现在提供jar oauth.auth(username,password):true|false每次写新特性的时候要在 dev 拉一下最新代码然后 迁出 特性分支 比如要增加一个 用户的新增功能 分支名称可以为 feature/userAdd
然后开发完了推上去给 dev 分支合并,合并完了跑 ci 测试,ci 测试没问题,可以合并到 master
当 master 改动较多的时候就可以 发布一个 release 版本 从 master/dev 迁出 然后打 tag ,写 CHANGELOG.md(应该有工具能生成), 发布到 gitlab/github,然后然后然后合并到 master资料转自:https://semlinker.com/ng-verson-manage/
如果多人开发,那么请配置 validate-commit 来确保所有人提交格式符合 GitFlow 规范:https://blog.eiyouhe.com/articles/2019/08/19/1566176660956.html?utm_source=hacpai.com#b3_solo_h1_7
另外 CHANGELOG 也有 Cli,可以试试:https://blog.eiyouhe.com/articles/2019/08/19/1566176660956.html#b3_solo_h2_12所以 100 分给我吧,我求求你了
3 操作someone27889 在 2019-12-18 09:04:50 更新了该回帖someone27889 在 2019-12-18 09:03:48 更新了该回帖someone27889 在 2019-12-18 09:00:23 更新了该回帖你先别求我。。我看看其他人的建议。分给你说不定别人都不屑回答了 -
someone9891 • • 4 评论捐赠者 作者
@participants
我参照 coding 这个流程，把其中的 master 换成 dev ，他这个持续集成的部分我集成到 test 环境，完了之后 合并到 master 大家觉得如何？1 回复有点类似 git flow@mymoshou 是有点类似，我是想在 git flow 的基础上尽量简化其实我有个疑问，测试是在 dev 上进行是吧？假如同时多个功能要测试怎么处理@mymoshou 那就合并到 dev 来啊，不然难道每个 分支还要部署一套测试吗？一般开发阶段自测，自测完了合并到 dev ，会持续集成到测试环境的。 -
git flow 想要严格遵守不是特别容易.这玩意还是有学习成本的.
我前段时间在公司推过这个规范,但基本没人关心怎么提交代码.
现在用起来的基本只有 master,feature,develop.
剩下分支种类,只要我不和他们说,他们就不用.
补充:
如果没有把 ci 用起来的话,分支合来合去,心里会很没底.1 回复目前的话我是参照 Git flow 简化了一下，到时候跟其他同事讨论讨论，再发出去给大家吧 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于