大家来谈一谈 Git 提交的规范

本贴最后更新于 1832 天前,其中的信息可能已经物是人非

最近要带一批实习生,由于之前本身 Git 提交也不是很规范,这次促使团队需要制定一些代码的规范,目前在编写团队的 Git 代码管理规范,想问一下大家平时都是怎么管理的。

  1. 分支的建立维护
  2. tag 的建立
  3. commit message 的填写格式
    ……

请大家在以上几个方面谈一谈自己平时工作中的做法以及效果。
大家可以畅所欲言,自由扩展其他方面。

  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    209 引用 • 358 回帖 • 1 关注
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    8446 引用 • 38474 回帖 • 154 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • someone9891

    这个到时候要发出去大家看的,别自己搞得有问题发出去被人笑话。。

  • someone1764 1 4 评论

    无数次跟组员说,定期 merge master,然后他们还是能把冲突的代码丢上来...

    1 回复
    分支保护如何呢?
    someone9891
    各自建临时分支,review 以后单独一个人 merge ?
    someone9891
    一个功能一个分支,然后还是把 <<<<<<<<< 弄上来了
    someone1764
    @mymoshou 我觉得这个人可以不要了
    someone9891
  • 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
  • 88250 1

    用这个增加情趣 https://gitmoji.carloscuesta.me/

    1 回复
  • someone27889 1 1 评论

    因为管理了好多项目,所以这个方面还是研究过一下子 ,主要使用了 GitFlow 规范
    分支分为
    新功能分支(feature),
    修复分支(fix),
    补丁分支(hotfix),
    版本分支(release),
    主分支(master),
    开发分支(dev)

    具体提交格式为

    <type>[optional scope]: <description>
    
    [optional body]
    
    [optional footer]
    
    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 分给我吧,我求求你了trollface

    3 操作
    someone27889 在 2019-12-18 09:04:50 更新了该回帖
    someone27889 在 2019-12-18 09:03:48 更新了该回帖
    someone27889 在 2019-12-18 09:00:23 更新了该回帖
    你先别求我。。我看看其他人的建议。分给你说不定别人都不屑回答了trollface
    someone9891
  • 然后 SourceTree 这个工具自带 GitFlow

    image.png

  • ZephyrJung 1

    我们用 git 没那么多乱七八糟的,master 用于发布,分支用于开发,分支名不限制,但是依我的习惯的话要以开发的目标作为分支名,后缀开发者或者时间之类的,commit message 格式也没限制过,但是尽量保证一次 commit 是完整的
    我还喜欢用 gitemoji 来标记本次提交的标记,可以参考 symphony 的提交记录,我就是从这里学的
    其实比较重要的就是要让开发者知道每次拉分支的时候,从 master 拉去最新的代码再创建

  • fenglinbiaoxie 1

    我们都是 git flow 那一套流程,统一在 develop 分支上开发,然后推送远端,最后在合并到 master1B73BB63CA67FBD80928626612C8F0F8.png

  • MistRay 1 1 评论

    git flow 想要严格遵守不是特别容易.这玩意还是有学习成本的.
    我前段时间在公司推过这个规范,但基本没人关心怎么提交代码.
    现在用起来的基本只有 master,feature,develop.
    剩下分支种类,只要我不和他们说,他们就不用.
    补充:
    如果没有把 ci 用起来的话,分支合来合去,心里会很没底.

    1 回复
    目前的话我是参照 Git flow 简化了一下,到时候跟其他同事讨论讨论,再发出去给大家吧
    someone9891
  • fenglinbiaoxie

    确实是 git flow 学习成本太大,我们用着用着也都是老一套了5VPM62M2FGAISYSO.jpg

  • adlered

    个人开发,看得懂就行。大功能开分支,小功能直接推 master doge

  • 原来 D 佬你一直用的都是这个!!!!
    收藏了

  • someone9891 4 评论

    @participants
    image.png
    我参照 coding 这个流程,把其中的 master 换成 dev ,他这个持续集成的部分我集成到 test 环境,完了之后 合并到 master 大家觉得如何?

    1 回复
    有点类似 git flow
    someone1764
    @mymoshou 是有点类似,我是想在 git flow 的基础上尽量简化
    someone9891
    其实我有个疑问,测试是在 dev 上进行是吧?假如同时多个功能要测试怎么处理
    someone1764
    @mymoshou 那就合并到 dev 来啊,不然难道每个 分支还要部署一套测试吗?一般开发阶段自测,自测完了合并到 dev ,会持续集成到测试环境的。
    someone9891
  • 积分已经到手了.剩下的已经不重要了,嘿嘿嘿嘿trollface

    1 回复
  • someone9891 6 评论

    image.png

    1 回复
    1 操作
    someone9891 在 2019-12-19 10:51:07 更新了该回帖
    无法访问
    someone1764
    @mymoshou 可以的啊
    someone9891
    图片地址是 localhost
    88250
    @88250 我复制过来了。。。怪不得我这里可以看到
    someone9891
    @88250 可能复制了个链接
    someone9891
    现在应该是可以了
    someone9891
  • someone9891

    我新发的这个图你觉得如何呢?

  • xuanskyer 1 1 评论

    这种问题其实很简单:

    1. 规范代码提交规范,合法性检测,不符合的代码无法提交
    2. 建立惩罚制度
    1 回复
    那回想起来,主要就是因为公司没有奖励机制,所以不好建立惩罚机制导致的
    someone1764
  • 不只是 commit message 和分支命名规范。我司的代码仓库有 PR 钩子,引入 coverity,对提交的代码用 SonarQube 进行静态分析,不符合代码质量规则的 PR 将无法合并

    截屏 20191219 下午 12.58.12.png

    1 回复
    1 操作
    someone48938 在 2019-12-19 13:45:37 更新了该回帖
  • 我个人认为这东西光靠一个人根本推不动.
    之前有就有了,如果没有的话就很难在短期内建设好投入使用.

  • 这个奖惩很难搞,如果没处理好,容易把团队气氛弄得很僵.

  • dafsic

    rebase 也很关键,merge 参数--no-ff ,rebase 参数-i

    1 回复
  • 代码规范和提交流程一般在两个时间段去定比较好。

    1. 项目的流程设计时;
    2. 项目的一个阶段已经结束,并且不着急赶着下一个阶段时。

    因为这些东西实际上说复杂不复杂,如果像我们这样弄过的人很好理解,大家统一一下风格和顺序就好了
    但如果你要是需要再带点培训性质的去弄,那可能就需要耗费一定的时间和开发时间,再加上本身可能有些人就对项目手忙脚乱的。

  • oathsign 1

    如果题主的库是放在 Github 上的,最好的办法就是符合 Github 的提交规范。例如首字母大写,标题用祈使句,内容和标题隔行写等等这些。因为你符合了这些规范不仅仅发邮件的时候内容清晰 ,而且会有意想不到的福利。例如可以用#+issue 的编号来标记并关闭相关的 issue😋 总之,规范要统一,要重视,更要专业。最讨厌一个项目几千个提交日志全是 commit it! 还不如不写

  • remixjc

    建议自己写一篇文章,制定自己的规范,让他们遵守就可以了。
    大致内容如下:

    1. 统一 GUI 工具,比如小乌龟TortoiseGit
    2. 分支创建与维护交给自己来管理
    3. 分享 git 的操作基本内容等,例如:https://www.remixjc.cn/articles/2019/12/20/1576806915902.html
    4. 在平时操作时有问题及时问
    5. 分享发现冲突与解决冲突的方法,避免强制推送导致代码覆盖,合并时一定不要忘记把别人的代码合并
  • yangyujiao

    哈哈哈。。。
    我们用 svn!!!
    我每次看到开发操作,切换分支,合并代码的都看着累。。。

    不过我们提交日志写的很好,因为我们用 jira,必须带着 jira 号跟描述。我们的每一个任务都有 jira 号,包含需求、bug、数据修复、优化等。

    我以前公司也是用 git,还特意培训过,我记得一家培训的是 git flow 的,一家是培训 github 的。

    2 回复
  • AkiYuo 3 评论

    用 SVN 说明公司技术管理挺务实的,非大型分布式开发的项目根本没必要用 Git,根本就是浪费大家时间。SVN 就简单多了,只能更新解决冲突才能提交,基本杜绝了项目库被覆盖的风险。

    务实个毛,明明就是历史遗留问题,,,我们一个大项目,分出各种模块,其实我觉得很适合用 git 啊,而且因为各种紧急升级、版本升级,好多的分支,导致大家切来切去的提交,都好几次提交漏了。。。写一行代码,要切 3、4 个分支提交代码,我每次给大家发注意事项都觉得累。
    yangyujiao
    svn 有一个持续集成的问题,我测试环境和生产环境都是自动部署就有问题了
    someone9891
    代码库被覆盖?你如果不对 git 有一定了解,想把代码弄丢且无法恢复都难... (最多就是把分支图弄得很难看)
    MistRay
  • Devin

    我们也是用 jira,不过我们用的是 git,必须带 jira id 才能 push,如果你很多次 commit,有一次不带都不行

  • someone9891 1 评论

    哎呦,这个竟然还被选为优选了。。。

    大家的回答都挺有价值的。
    88250
  • 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
       fi
    
    
    Good。
    taoism-o
  • ellenbboe

    进来学习

  • 老铁,我要剽了你的头像...

请输入回帖内容 ...

推荐标签 标签

  • Ruby

    Ruby 是一种开源的面向对象程序设计的服务器端脚本语言,在 20 世纪 90 年代中期由日本的松本行弘(まつもとゆきひろ/Yukihiro Matsumoto)设计并开发。在 Ruby 社区,松本也被称为马茨(Matz)。

    7 引用 • 31 回帖 • 216 关注
  • 以太坊

    以太坊(Ethereum)并不是一个机构,而是一款能够在区块链上实现智能合约、开源的底层系统。以太坊是一个平台和一种编程语言 Solidity,使开发人员能够建立和发布下一代去中心化应用。 以太坊可以用来编程、分散、担保和交易任何事物:投票、域名、金融交易所、众筹、公司管理、合同和知识产权等等。

    34 引用 • 367 回帖 • 1 关注
  • 爬虫

    网络爬虫(Spider、Crawler),是一种按照一定的规则,自动地抓取万维网信息的程序。

    106 引用 • 275 回帖 • 1 关注
  • SOHO

    为成为自由职业者在家办公而努力吧!

    7 引用 • 55 回帖 • 5 关注
  • CodeMirror
    1 引用 • 2 回帖 • 129 关注
  • Swagger

    Swagger 是一款非常流行的 API 开发工具,它遵循 OpenAPI Specification(这是一种通用的、和编程语言无关的 API 描述规范)。Swagger 贯穿整个 API 生命周期,如 API 的设计、编写文档、测试和部署。

    26 引用 • 35 回帖 • 5 关注
  • WiFiDog

    WiFiDog 是一套开源的无线热点认证管理工具,主要功能包括:位置相关的内容递送;用户认证和授权;集中式网络监控。

    1 引用 • 7 回帖 • 591 关注
  • 旅游

    希望你我能在旅途中找到人生的下一站。

    93 引用 • 899 回帖 • 3 关注
  • FlowUs

    FlowUs.息流 个人及团队的新一代生产力工具。

    让复杂的信息管理更轻松、自由、充满创意。

    1 引用
  • Mac

    Mac 是苹果公司自 1984 年起以“Macintosh”开始开发的个人消费型计算机,如:iMac、Mac mini、Macbook Air、Macbook Pro、Macbook、Mac Pro 等计算机。

    166 引用 • 595 回帖
  • 博客

    记录并分享人生的经历。

    273 引用 • 2388 回帖 • 1 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 536 关注
  • QQ

    1999 年 2 月腾讯正式推出“腾讯 QQ”,在线用户由 1999 年的 2 人(马化腾和张志东)到现在已经发展到上亿用户了,在线人数超过一亿,是目前使用最广泛的聊天软件之一。

    45 引用 • 557 回帖 • 44 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    167 引用 • 1520 回帖 • 1 关注
  • 黑曜石

    黑曜石是一款强大的知识库工具,支持本地 Markdown 文件编辑,支持双向链接和关系图。

    A second brain, for you, forever.

    16 引用 • 130 回帖
  • Bug

    Bug 本意是指臭虫、缺陷、损坏、犯贫、窃听器、小虫等。现在人们把在程序中一些缺陷或问题统称为 bug(漏洞)。

    76 引用 • 1737 回帖
  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    343 引用 • 723 回帖
  • 又拍云

    又拍云是国内领先的 CDN 服务提供商,国家工信部认证通过的“可信云”,乌云众测平台认证的“安全云”,为移动时代的创业者提供新一代的 CDN 加速服务。

    21 引用 • 37 回帖 • 548 关注
  • LeetCode

    LeetCode(力扣)是一个全球极客挚爱的高质量技术成长平台,想要学习和提升专业能力从这里开始,充足技术干货等你来啃,轻松拿下 Dream Offer!

    209 引用 • 72 回帖
  • JWT

    JWT(JSON Web Token)是一种用于双方之间传递信息的简洁的、安全的表述性声明规范。JWT 作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以 JSON 的形式安全的传递信息。

    20 引用 • 15 回帖 • 6 关注
  • 阿里巴巴

    阿里巴巴网络技术有限公司(简称:阿里巴巴集团)是以曾担任英语教师的马云为首的 18 人,于 1999 年在中国杭州创立,他们相信互联网能够创造公平的竞争环境,让小企业通过创新与科技扩展业务,并在参与国内或全球市场竞争时处于更有利的位置。

    43 引用 • 221 回帖 • 106 关注
  • Spring

    Spring 是一个开源框架,是于 2003 年兴起的一个轻量级的 Java 开发框架,由 Rod Johnson 在其著作《Expert One-On-One J2EE Development and Design》中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许使用者选择使用哪一个组件,同时为 JavaEE 应用程序开发提供集成的框架。

    943 引用 • 1460 回帖 • 3 关注
  • 微信

    腾讯公司 2011 年 1 月 21 日推出的一款手机通讯软件。用户可以通过摇一摇、搜索号码、扫描二维码等添加好友和关注公众平台,同时可以将自己看到的精彩内容分享到微信朋友圈。

    132 引用 • 795 回帖
  • 星云链

    星云链是一个开源公链,业内简单的将其称为区块链上的谷歌。其实它不仅仅是区块链搜索引擎,一个公链的所有功能,它基本都有,比如你可以用它来开发部署你的去中心化的 APP,你可以在上面编写智能合约,发送交易等等。3 分钟快速接入星云链 (NAS) 测试网

    3 引用 • 16 回帖 • 5 关注
  • App

    App(应用程序,Application 的缩写)一般指手机软件。

    91 引用 • 384 回帖 • 2 关注
  • Node.js

    Node.js 是一个基于 Chrome JavaScript 运行时建立的平台, 用于方便地搭建响应速度快、易于扩展的网络应用。Node.js 使用事件驱动, 非阻塞 I/O 模型而得以轻量和高效。

    139 引用 • 269 回帖 • 28 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖 • 7 关注