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