最近要带一批实习生，由于之前本身 Git 提交也不是很规范，这次促使团队需要制定一些代码的规范，目前在编写团队的 Git 代码管理规范，想问一下大家平时都是怎么管理的。
- 分支的建立维护
- tag 的建立
- commit message 的填写格式
……
请大家在以上几个方面谈一谈自己平时工作中的做法以及效果。
大家可以畅所欲言，自由扩展其他方面。
本贴最后更新于 1589 天前，其中的信息可能已经物是人非
相关帖子
-
-
someone1764 • • 1 • 4 评论
无数次跟组员说，定期 merge master，然后他们还是能把冲突的代码丢上来...
1 回复分支保护如何呢？各自建临时分支，review 以后单独一个人 merge ？一个功能一个分支，然后还是把 <<<<<<<<< 弄上来了@mymoshou 我觉得这个人可以不要了 -
someone9891 • • 1 评论捐赠者 作者
另外后续可能打算生成更新日志，commit message 如何填写能让 log 看起来顺眼点。
1 回复我们这边是这样处理，维护 dev 分支作为主分支（主分支不允许直接 push），然后每个人做的任务从主分支 branch，做完测试通过了就起 pr，reviewer review 之后 merge 到主分支，到发版本的时候就 frozen 主分支，然后从主分支 branch 出来一个 release 分支，如果这个 release 分支测试通过没有什么需要 fix 的，那就不需要 merge 回去主分支，如果有 fix，等出版本之后就需要 merge 到主分支，另外如果需要出 hot fix 就也是从主分支 branch，出了 fix 之后再 merge 回去主分支Devin • -
-
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 更新了该回帖你先别求我。。我看看其他人的建议。分给你说不定别人都不屑回答了 -
-
ZephyrJung • • 1
我们用 git 没那么多乱七八糟的，master 用于发布，分支用于开发，分支名不限制，但是依我的习惯的话要以开发的目标作为分支名，后缀开发者或者时间之类的，commit message 格式也没限制过，但是尽量保证一次 commit 是完整的
我还喜欢用 gitemoji 来标记本次提交的标记，可以参考 symphony 的提交记录，我就是从这里学的
其实比较重要的就是要让开发者知道每次拉分支的时候，从 master 拉去最新的代码再创建 -
-
git flow 想要严格遵守不是特别容易.这玩意还是有学习成本的.
我前段时间在公司推过这个规范,但基本没人关心怎么提交代码.
现在用起来的基本只有 master,feature,develop.
剩下分支种类,只要我不和他们说,他们就不用.
补充:
如果没有把 ci 用起来的话,分支合来合去,心里会很没底.1 回复目前的话我是参照 Git flow 简化了一下，到时候跟其他同事讨论讨论，再发出去给大家吧 -
-
someone9891 • • 4 评论捐赠者 作者
@participants
我参照 coding 这个流程，把其中的 master 换成 dev ，他这个持续集成的部分我集成到 test 环境，完了之后 合并到 master 大家觉得如何？1 回复有点类似 git flow@mymoshou 是有点类似，我是想在 git flow 的基础上尽量简化其实我有个疑问，测试是在 dev 上进行是吧？假如同时多个功能要测试怎么处理@mymoshou 那就合并到 dev 来啊，不然难道每个 分支还要部署一套测试吗？一般开发阶段自测，自测完了合并到 dev ，会持续集成到测试环境的。 -
-
someone9891 • • 6 评论捐赠者 作者1 回复1 操作someone9891 在 2019-12-19 10:51:07 更新了该回帖
-
-
xuanskyer • • 1 • 1 评论
这种问题其实很简单：
- 规范代码提交规范，合法性检测，不符合的代码无法提交
- 建立惩罚制度
1 回复那回想起来，主要就是因为公司没有奖励机制，所以不好建立惩罚机制导致的 -
不只是 commit message 和分支命名规范。我司的代码仓库有 PR 钩子，引入 coverity，对提交的代码用 SonarQube 进行静态分析，不符合代码质量规则的 PR 将无法合并
1 回复1 操作someone48938 在 2019-12-19 13:45:37 更新了该回帖 -
-
oathsign • • 1
如果题主的库是放在 Github 上的，最好的办法就是符合 Github 的提交规范。例如首字母大写，标题用祈使句，内容和标题隔行写等等这些。因为你符合了这些规范不仅仅发邮件的时候内容清晰 ，而且会有意想不到的福利。例如可以用#+issue 的编号来标记并关闭相关的 issue😋 总之，规范要统一，要重视，更要专业。最讨厌一个项目几千个提交日志全是 commit it！ 还不如不写
-
remixjc •
建议自己写一篇文章，制定自己的规范，让他们遵守就可以了。
大致内容如下：- 统一 GUI 工具，比如小乌龟TortoiseGit
- 分支创建与维护交给自己来管理
- 分享 git 的操作基本内容等，例如：https://www.remixjc.cn/articles/2019/12/20/1576806915902.html
- 在平时操作时有问题及时问
- 分享发现冲突与解决冲突的方法，避免强制推送导致代码覆盖，合并时一定不要忘记把别人的代码合并
-
哈哈哈。。。
我们用 svn！！！
我每次看到开发操作，切换分支，合并代码的都看着累。。。不过我们提交日志写的很好，因为我们用 jira，必须带着 jira 号跟描述。我们的每一个任务都有 jira 号，包含需求、bug、数据修复、优化等。
我以前公司也是用 git，还特意培训过，我记得一家培训的是 git flow 的，一家是培训 github 的。
2 回复 -
AkiYuo • • 3 评论
用 SVN 说明公司技术管理挺务实的，非大型分布式开发的项目根本没必要用 Git，根本就是浪费大家时间。SVN 就简单多了，只能更新解决冲突才能提交，基本杜绝了项目库被覆盖的风险。
务实个毛，明明就是历史遗留问题，，，我们一个大项目，分出各种模块，其实我觉得很适合用 git 啊，而且因为各种紧急升级、版本升级，好多的分支，导致大家切来切去的提交，都好几次提交漏了。。。写一行代码，要切 3、4 个分支提交代码，我每次给大家发注意事项都觉得累。svn 有一个持续集成的问题，我测试环境和生产环境都是自动部署就有问题了代码库被覆盖?你如果不对 git 有一定了解,想把代码弄丢且无法恢复都难... (最多就是把分支图弄得很难看)MistRay • -
-
-
Ahian • • 1 • 1 赞同 • 1 评论
加一段我写的 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 • -
-
请输入回帖内容
...
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于