最近要带一批实习生，由于之前本身 Git 提交也不是很规范，这次促使团队需要制定一些代码的规范，目前在编写团队的 Git 代码管理规范，想问一下大家平时都是怎么管理的。
- 分支的建立维护
- tag 的建立
- commit message 的填写格式
……
请大家在以上几个方面谈一谈自己平时工作中的做法以及效果。
大家可以畅所欲言，自由扩展其他方面。
本贴最后更新于 1990 天前，其中的信息可能已经物是人非
相关帖子
-
- 其他回帖
-
someone27889 • • 1 • 1 评论 via macOS
因为管理了好多项目,所以这个方面还是研究过一下子 ,主要使用了 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 更新了该回帖你先别求我。。我看看其他人的建议。分给你说不定别人都不屑回答了 -
Ahian • • 1 • 1 赞同 • 1 评论 via macOS
加一段我写的 gitlab hooks 的脚本，主要是校验 commit msg
msg=`git show $newrev -s --format=%B` if [[ $msg =~ ^(feat|fix|test|refactor|docs|style|chroe).*:.*$ ]]; then echo "【commit message 通过检查】!" else echo "【commit message 不符合规范】" echo "【缺少关键字: [feat,fix,docs,style,refactor,test,chore]】" echo "【格式：<类型>(<影响范围>): <简要概述>】" echo "【eg: feat(user): add the user login】" echo "【eg: fix(影响范围):#禅道编号 】" echo "【修改已提交message命令：git --amend -m <new message>】" exit 1 break fiGood。taoism-o • -
oathsign • • 1
如果题主的库是放在 Github 上的，最好的办法就是符合 Github 的提交规范。例如首字母大写，标题用祈使句，内容和标题隔行写等等这些。因为你符合了这些规范不仅仅发邮件的时候内容清晰 ，而且会有意想不到的福利。例如可以用#+issue 的编号来标记并关闭相关的 issue😋 总之，规范要统一，要重视，更要专业。最讨厌一个项目几千个提交日志全是 commit it！ 还不如不写
- 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于