V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
polyang
V2EX  ›  程序员

提交代码时 git commit message 是不是写的详细点比较好?

  •  1
     
  •   polyang · 2021-08-06 09:58:45 +08:00 · 7294 次点击
    这是一个创建于 1184 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近我无意中注意到同事代码时 commit message 写的是“1”、“111”、“。。。。”这种无意义的 message,就是下面这种: 1.png 2.jpg

    进而联想到,我们在开发时,commit message 是不是写的详细一点比较好?

    72 条回复    2021-08-16 15:55:51 +08:00
    AoEiuV020
        1
    AoEiuV020  
       2021-08-06 10:00:44 +08:00   ❤️ 1
    不说多详细,起码要有一行文字看完大概知道这个 commit 是做了什么,
    Tianao
        2
    Tianao  
       2021-08-06 10:01:43 +08:00
    废话,肯定是要详细。这种写也可能是 commit 粒度太细了,没有耐心写。
    zinete
        3
    zinete  
       2021-08-06 10:05:14 +08:00
    git hooks 整个代码提交规范
    Morriaty
        4
    Morriaty  
       2021-08-06 10:06:18 +08:00   ❤️ 2
    Kusoku
        5
    Kusoku  
       2021-08-06 10:06:45 +08:00   ❤️ 1
    不用很详细,但是需要清晰和一定概括性,详细的信息应该附在代码中作为注释
    Shook
        6
    Shook  
       2021-08-06 10:07:21 +08:00   ❤️ 1
    起码要说一下这个 commit 是做什么的吧
    huangmingyou
        7
    huangmingyou  
       2021-08-06 10:07:47 +08:00   ❤️ 1
    理论上肯定要写清楚,并且作为开发规范。
    q2551430130
        8
    q2551430130  
       2021-08-06 10:08:10 +08:00
    当然
    deplivesb
        9
    deplivesb  
       2021-08-06 10:11:35 +08:00
    也不能是 800 字的作文吧,但至少要让别人能知道你这是这个 commit 干了啥
    zhangchongjie
        10
    zhangchongjie  
       2021-08-06 10:13:41 +08:00   ❤️ 1
    这是基本的东西吧,每一次提交的大概变动,先不说为了团队,自己以后 debug 的时候也好看,回滚方便
    yolee599
        11
    yolee599  
       2021-08-06 10:18:18 +08:00   ❤️ 18
    我一般都是建好仓库后建一个模板文件:.gitmessage,然后执行 git config commit.template .gitmessage,之后提交的时候执行 git commit 就会自动引用模板,在相应的位置填写信息就可以了,禁止使用 git commit -m 。模板参照这个: https://github.com/angular/angular/blob/master/CONTRIBUTING.md
    polyang
        12
    polyang  
    OP
       2021-08-06 10:21:00 +08:00
    @yolee599 感谢,我去看看
    ch2
        13
    ch2  
       2021-08-06 10:26:19 +08:00
    一句话说清楚
    chengxynds
        14
    chengxynds  
       2021-08-06 10:38:47 +08:00
    知道干了啥就行 业务+动作
    xwayway
        15
    xwayway  
       2021-08-06 10:42:30 +08:00
    我们 commit message 有需求的一般需要贴上 jira 链接,然后大致写下实现了什么。如果是修改 bug,要说下改动点,影响范围什么的
    gowk
        16
    gowk  
       2021-08-06 10:47:01 +08:00
    pengtdyd
        17
    pengtdyd  
       2021-08-06 10:53:54 +08:00
    @yolee599 Angular 扎心了,用的人少,却因为 git commit 规范被提及。
    whorusq
        18
    whorusq  
       2021-08-06 11:03:25 +08:00
    [bug 号|需求号|其它] 模块名 > 功能名:然后简单描述本次提交做了什么工作
    我们一般这么写,仅供参考
    0312birdzhang
        19
    0312birdzhang  
       2021-08-06 11:28:13 +08:00
    看一下 linux 的提交记录,详细到飞起
    violetlai
        20
    violetlai  
       2021-08-06 11:45:44 +08:00
    IDE 基本都有 git commite template 插件吧 照着模版填就好了
    jdhao
        21
    jdhao  
       2021-08-06 11:49:54 +08:00 via Android
    不说要写的超级详细,起码写一下做了什么更改,为啥更改。

    不写 commit 信息的都是草台班子
    auh
        22
    auh  
       2021-08-06 11:56:22 +08:00
    提交文本。一般就是,新增,修复,重构开头。然后,简单,描述一下涉及的业务功能,架构功能,修复的 bug 。等。大概知道干啥了就行。文字不要超过 20 个字。超过部分,可以作为详细解析,比如想要分享一下自己是如何思考和解决的。相当于一个详细解释。供大家没事干的时候欣赏。哈哈哈
    locoz
        23
    locoz  
       2021-08-06 12:07:59 +08:00 via Android   ❤️ 1
    大致做了啥总得用一句话描述一下吧…这 111 是真离谱,测试的时候这么搞一下还行,后面强制提交覆盖掉或者直接在另一个分支上搞都没啥影响,主要内容还这么搞就是单纯的不负责任了。
    zenwong
        24
    zenwong  
       2021-08-06 12:54:14 +08:00
    git cz
    maninfog
        25
    maninfog  
       2021-08-06 12:55:36 +08:00 via iPhone   ❤️ 1
    你这个同事有点离谱
    ysicing
        26
    ysicing  
       2021-08-06 13:03:06 +08:00
    详细点好,可以试试 @mritd 大佬写的工具 https://github.com/mritd/gitflow-toolkit
    monospace
        27
    monospace  
       2021-08-06 13:03:36 +08:00   ❤️ 1
    在我的团队要是有人写这种毫无意义的 commit message 的话,直接滚蛋!
    mritd
        28
    mritd  
       2021-08-06 13:06:16 +08:00
    @ysicing #26 还有点小 bug,终端提示有时候按快了就会没一行... 虽然不影响使用但是挺烦的,现在也没找到啥好用的终端库
    codehz
        29
    codehz  
       2021-08-06 13:07:29 +08:00
    建议本地随意写,push 之前 rebase 一下再修改,避免无意义的 commit 和反复的修改。。
    jonathanchoo
        30
    jonathanchoo  
       2021-08-06 13:53:34 +08:00
    自己分支无所谓吧,提 mr 的时候描述详细一点,然后压缩一下提交记录
    passerbytiny
        31
    passerbytiny  
       2021-08-06 14:04:57 +08:00 via Android   ❤️ 1
    git commit message 是有通用约定的(当然这是国际而非国内开发届的约定)的最小规范的:第一行写不超过 80 个字符宽度的标题,空一行从第三行开始写详细或附加内容,后者是可选的。至于具体怎么写,就没限制了,说人话就行。

    至于“1”、“111”、这样的提交信息,只有刚从 SVN 或者其他 VCS 转过来的新手才会提交,而允许这种提交信息存在的团队也必然是新手团队——成熟的团队这种提交压根不会被合并到主分支。
    noqwerty
        32
    noqwerty  
       2021-08-06 14:10:39 +08:00 via Android
    直接全局用 commitizen
    baiyi
        33
    baiyi  
       2021-08-06 14:13:47 +08:00
    最好是一行就能概括,这说明这个 commit 只做了一件事。如果有补充说明,可以换行写长篇的补充,这样的好处是在概览的时候,只看到有用的概括信息,然后详细的信息在 commit message 中也能看到。
    erwin985211
        34
    erwin985211  
       2021-08-06 14:14:39 +08:00
    别说别人最起码自己能知道这次改了啥。
    ThanksSirAlex
        35
    ThanksSirAlex  
       2021-08-06 14:27:03 +08:00
    开源项目写详细一点,公司内部无所谓了,反正没人看
    ckdxc
        36
    ckdxc  
       2021-08-06 14:28:13 +08:00
    @codehz 我一直都是 用的那个 interactive rebase 那个, 但是万一操作的是 公共分支, 然后 push -f 好危险, 有啥办法安全操作不, 我都是 rebase | push -f 自己的分支
    boris93
        37
    boris93  
       2021-08-06 14:31:07 +08:00 via iPhone
    第一行作为标题,一句话概括干了啥
    空一行,第三行开始可以写详细的描述,非必需
    xz410236056
        38
    xz410236056  
       2021-08-06 14:33:06 +08:00
    哪怕什么都不写呢。。。这 1111 是什么鬼
    codehz
        39
    codehz  
       2021-08-06 14:34:56 +08:00
    @ckdxc 本地单独开分支搞啊,反正分支不要钱
    weiwenhao
        40
    weiwenhao  
       2021-08-06 14:41:31 +08:00   ❤️ 1
    git commit -m 'feat(工单 /功能 /可选): xxx' # 功能迭代
    git commit -m 'fix: xxx' # bug 修复
    git commit -m 'refactor: xxx' # 重构
    git commit -m 'chore: xxx' # 杂事

    https://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
    我现在就遵守这个,每一行 commit 都认真写, 至于其他人怎么写我就不管了。
    clockwork1122
        41
    clockwork1122  
       2021-08-06 14:49:48 +08:00
    @yolee599 我马一下
    pkoukk
        42
    pkoukk  
       2021-08-06 14:55:06 +08:00
    自己开发的时候瞎写,merge 进 master 之前 suqash,然后才会好好写。
    commit 就是个 crtl+s,不能每次都写一大段吧
    SimleCp
        43
    SimleCp  
       2021-08-06 15:02:15 +08:00
    写清楚点方便你自己看.
    Sain
        44
    Sain  
       2021-08-06 15:23:36 +08:00
    一个功能一次 commit,merge 之前 suqash 写
    no1xsyzy
        45
    no1xsyzy  
       2021-08-06 15:31:16 +08:00
    {feat,fix,refactor,style}(模块): xxx
    实在想写不说不爽的时候再空一行添加更多文字
    如果在一个 commit 内存在多种更改,则「首行」的定义可以宽限到多行。

    @passerbytiny JB 家的约定是首行 120 字(
    no1xsyzy
        46
    no1xsyzy  
       2021-08-06 15:33:15 +08:00
    不过我考虑了一下,commit msg 应当服务于 rebase -i 和 cherry pick,可以直接看出到底干了啥。
    ypzhou
        47
    ypzhou  
       2021-08-06 15:37:44 +08:00
    你去看看 github 看看排名前几的提交不就知道了
    suotm
        48
    suotm  
       2021-08-06 15:38:31 +08:00
    111 就太离谱了!
    wolfie
        49
    wolfie  
       2021-08-06 15:40:57 +08:00   ❤️ 1
    之前有同事 自己开发一个项目时候 就这么提交。
    后来改代码,经常跨模块改串了,后来回滚都不知道怎么回滚。
    bug 指数级增长。
    www5070504
        50
    www5070504  
       2021-08-06 16:00:40 +08:00
    这种不好好写 commit 信息的 早晚有一天恶心到自己或者恶心到别人
    kafkaonsea
        51
    kafkaonsea  
       2021-08-06 16:03:56 +08:00
    小公司只能靠自觉共识约束了

    大公司可以搞 CI 流水线,不符合格式规范的 git commit,流水线失败,不允许合入 master
    rekulas
        52
    rekulas  
       2021-08-06 16:08:47 +08:00
    之前在外企呆过,都是规范格式,描述有误被打回 pr 的大有人在,现在养成了习惯尽可能一句话描述清楚改动
    养成这习惯很有好处,有一次调试一个 bug 追踪到了 4 年前,根据详细的 commit 描述 1 小时就定位到了,如果 msg 乱写我估计 1 天都未必能找到
    hzz2
        53
    hzz2  
       2021-08-06 16:25:36 +08:00
    leader 管起来 制定规范 https://segmentfault.com/a/1190000009048911
    QHKZ
        54
    QHKZ  
       2021-08-06 16:42:16 +08:00   ❤️ 1
    我写这段代码的时候,只有上帝和我知道。现在,只有上帝知道了。
    commit 的作用是不用去看代码,也能知道代码发生了什么变动。
    贴一段 linux 内核的最新 commit:
    https://github.com/torvalds/linux/commit/e04480920d1eec9c061841399aa6f35b6f987d8b
    -----
    Bluetooth: defer cleanup of resources in hci_unregister_dev()
    syzbot is hitting might_sleep() warning at hci_sock_dev_event() due to
    calling lock_sock() with rw spinlock held [1].

    It seems that history of this locking problem is a trial and error.

    Commit b40df57 ("[PATCH] bluetooth: fix socket locking in
    hci_sock_dev_event()") in 2.6.21-rc4 changed bh_lock_sock() to
    lock_sock() as an attempt to fix lockdep warning.

    Then, commit 4ce61d1 ("[BLUETOOTH]: Fix locking in
    hci_sock_dev_event().") in 2.6.22-rc2 changed lock_sock() to
    local_bh_disable() + bh_lock_sock_nested() as an attempt to fix the
    sleep in atomic context warning.

    Then, commit 4b5dd69 ("Bluetooth: Remove local_bh_disable() from
    hci_sock.c") in 3.3-rc1 removed local_bh_disable().

    Then, commit e305509 ("Bluetooth: use correct lock to prevent UAF
    of hdev object") in 5.13-rc5 again changed bh_lock_sock_nested() to
    lock_sock() as an attempt to fix CVE-2021-3573.

    This difficulty comes from current implementation that
    hci_sock_dev_event(HCI_DEV_UNREG) is responsible for dropping all
    references from sockets because hci_unregister_dev() immediately
    reclaims resources as soon as returning from
    hci_sock_dev_event(HCI_DEV_UNREG).

    But the history suggests that hci_sock_dev_event(HCI_DEV_UNREG) was not
    doing what it should do.

    Therefore, instead of trying to detach sockets from device, let's accept
    not detaching sockets from device at hci_sock_dev_event(HCI_DEV_UNREG),
    by moving actual cleanup of resources from hci_unregister_dev() to
    hci_cleanup_dev() which is called by bt_host_release() when all
    references to this unregistered device (which is a kobject) are gone.

    Since hci_sock_dev_event(HCI_DEV_UNREG) no longer resets
    hci_pi(sk)->hdev, we need to check whether this device was unregistered
    and return an error based on HCI_UNREGISTER flag. There might be subtle
    behavioral difference in "monitor the hdev" functionality; please report
    if you found something went wrong due to this patch.

    Link: https://syzkaller.appspot.com/bug?extid=a5df189917e79d5e59c9 [1]
    Reported-by: syzbot <[email protected]>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Fixes: e305509 ("Bluetooth: use correct lock to prevent UAF of hdev object")
    Acked-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    master
    @torvalds
    Tetsuo Handa authored and torvalds committed 13 hours ago
    1 parent 0b53abf commit e04480920d1eec9c061841399aa6f35b6f987d8b
    echoechoin
        55
    echoechoin  
       2021-08-06 17:00:46 +08:00
    我们公司是 添加一个 hook 限制一下字数
    chjieza
        56
    chjieza  
       2021-08-06 17:17:13 +08:00
    上 husky,在 git 钩子加验证就完了,对应 jira 的 feat 或者 fix
    ErenJaeger
        57
    ErenJaeger  
       2021-08-06 18:18:03 +08:00
    卧槽,写这 111 不得被打一顿?
    我看约定俗成的规范是

    type: title
    blank line
    body
    jaredyam
        58
    jaredyam  
       2021-08-06 20:46:16 +08:00
    和写 docstring 差不多。最好先用较少的字符进行内容梗概,也即比较短的一行。如果觉得有需要详细说明的地方,隔一行,再另起一行,详细说明。如:
    ------------------------------
    这是常见的 commit 写法

    我要开始详细说明了……
    hallDrawnel
        59
    hallDrawnel  
       2021-08-06 21:37:43 +08:00
    1111 这不得打一顿?后面的人看了全不知道你干了啥呀。我们对 mater 的所有合并都会发通知到开发群里,群里所有人都能看见你在 commit message 上写了啥。commit message 要求用 commitizen 。
    Huelse
        60
    Huelse  
       2021-08-06 21:51:17 +08:00
    你同事这个过分了,好歹说一下干了啥,中文写都可以
    JerryCha
        61
    JerryCha  
       2021-08-06 22:40:17 +08:00
    我们跟包了一层 Jira 的系统关联的,不带上编号不能推送到 remote 仓库
    jiyinyiyong
        62
    jiyinyiyong  
       2021-08-06 23:04:59 +08:00   ❤️ 1
    leader: 来, 我看看你们这周都干了什么.
    你: 我给项目 AAA 加了一个菜单, 对接了后端的 BBB 功能,
    然后在 Webpack 配置做了一些优化, 编译时间少了 2.2s 多一点.
    leader: 打的不错, 继续努力. (转过头) 那你呢?
    你同事: 我 "1" 了一下, 然后 "111" 了一下.
    leader: 说人话!
    你同事: "。。。。"
    leader: 你礼貌吗? 难道要我一行一行去代码里看你都搞了什么!
    ztcaoll222
        63
    ztcaoll222  
       2021-08-07 01:19:14 +08:00
    commit 基本一句话,但是 pr 会写得详细一点
    molvqingtai
        64
    molvqingtai  
       2021-08-07 02:43:52 +08:00 via Android
    你需要 commitlint
    crclz
        65
    crclz  
       2021-08-07 09:35:41 +08:00
    commit message 至少要能够保证:你自己过一周看到 commit message 的时候能知道这个 commit 里面干了什么。
    villivateur
        66
    villivateur  
       2021-08-07 09:49:31 +08:00 via Android
    你这同事要是跟我合作我要把他喷死
    AmaQuinton
        67
    AmaQuinton  
       2021-08-07 11:26:54 +08:00
    写清楚一些,会省好多事
    matrix67
        68
    matrix67  
       2021-08-07 14:15:11 +08:00
    @xz410236056 #38 这个人肯定经常组队打游戏,打 1 这个习惯应该是大多数魔兽世界玩家的通病。以前打团没有现在这些插件检查,准备就绪这些都是,团长都是听到的打 1,没到的打 1 。久而久之打 1 就演变成我知道了,明白这个意思哦了。

    打开英雄联盟好友发来:1 ?(打吗)
    你:1 (打)

    选好位置:1 ?(还有人吗?开吗?)
    你:1 (没人了开)

    高层选人:1 ?(要一抢吗?)
    四楼:豹女你:1 (收到)
    选人:1 ?(锁吗)
    四楼:1 (锁)

    开始游戏了:1 ?(一级团吗)
    狂野女猎手:饰品守卫(不团做眼)
    狂野女猎手正在路上:1 ?(能抓?)

    沙漠死神标记此处危险(不能)
    疾风剑豪请求协助:1 ?(来帮)
    曙光女神正在路上(来了)
    狂野女猎手请求协助:1 ?(来龙?)
    暗夜猎手正在路上(搞起)
    狂野女猎手示意撤离:1 (足够了谢谢)
    暗夜猎手表情点赞:1 (不客气这是我该做的)
    polyang
        69
    polyang  
    OP
       2021-08-07 18:53:53 +08:00
    @villivateur 哈哈,没必要吧
    cwek
        70
    cwek  
       2021-08-07 19:09:28 +08:00
    有可能临时的 commit,然后提交时没 rebase 压缩重写 commit 。
    NetCobra
        71
    NetCobra  
       2021-08-08 03:58:35 +08:00
    写这种提交信息的基本上都不明白为什么代码要有个提交的操作。
    Cu635
        72
    Cu635  
       2021-08-16 15:55:51 +08:00
    这种同事趁早开除,未来的屎山就是它们贡献的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2675 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 12:20 · PVG 20:20 · LAX 05:20 · JFK 08:20
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.