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

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

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

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

  • Git

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

    166 引用 • 323 回帖 • 640 关注
  • Q&A

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

    1587 引用 • 10408 回帖 • 574 关注
31 回帖
请输入回帖内容...
  • MistRay 1 1 评论

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

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

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

  • mymoshou 1 4 评论

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

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