最近要带一批实习生，由于之前本身 Git 提交也不是很规范，这次促使团队需要制定一些代码的规范，目前在编写团队的 Git 代码管理规范，想问一下大家平时都是怎么管理的。
- 分支的建立维护
- tag 的建立
- commit message 的填写格式
……
请大家在以上几个方面谈一谈自己平时工作中的做法以及效果。
大家可以畅所欲言，自由扩展其他方面。
本贴最后更新于 1784 天前，其中的信息可能已经物是人非
相关帖子
-
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 • - 其他回帖
-
ZephyrJung • • 1
我们用 git 没那么多乱七八糟的，master 用于发布，分支用于开发，分支名不限制，但是依我的习惯的话要以开发的目标作为分支名，后缀开发者或者时间之类的，commit message 格式也没限制过，但是尽量保证一次 commit 是完整的
我还喜欢用 gitemoji 来标记本次提交的标记，可以参考 symphony 的提交记录，我就是从这里学的
其实比较重要的就是要让开发者知道每次拉分支的时候，从 master 拉去最新的代码再创建 -
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 • -
git flow 想要严格遵守不是特别容易.这玩意还是有学习成本的.
我前段时间在公司推过这个规范,但基本没人关心怎么提交代码.
现在用起来的基本只有 master,feature,develop.
剩下分支种类,只要我不和他们说,他们就不用.
补充:
如果没有把 ci 用起来的话,分支合来合去,心里会很没底.1 回复目前的话我是参照 Git flow 简化了一下，到时候跟其他同事讨论讨论，再发出去给大家吧 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于