V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
gowl
V2EX  ›  问与答

使用 git 的时候,大家喜欢用很多小 commit 还是用很少的大 commit?

  •  
  •   gowl · 2023-02-21 23:28:03 +08:00 · 3148 次点击
    这是一个创建于 401 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我自己喜欢用很多细小的 commit ,但我注意到一些天才型的工程师喜欢用大 commit:)

    36 条回复    2023-02-22 11:30:55 +08:00
    wangkun025
        1
    wangkun025  
       2023-02-21 23:30:02 +08:00   ❤️ 2
    也许,他们是合并过的 commit
    ql562482472
        2
    ql562482472  
       2023-02-21 23:30:30 +08:00   ❤️ 2
    squash !
    dzdh
        3
    dzdh  
       2023-02-21 23:33:21 +08:00   ❤️ 1
    我习惯切个新分支,在这个分支上很多小 commit ,然后切成一个大 commit 重新切个分支然后在 merge 到主干分支。
    gowl
        4
    gowl  
    OP
       2023-02-21 23:34:05 +08:00
    追一个问题:如果是自己的项目,有必要以丢失信息为代价去 squash 么?
    gowl
        5
    gowl  
    OP
       2023-02-21 23:35:11 +08:00
    @dzdh 你会保留所有的“试验性”分支么?
    silentsky
        6
    silentsky  
       2023-02-21 23:36:38 +08:00 via Android   ❤️ 1
    我喜欢大 commit ,一般都是一个需求一个 commit
    renmu
        7
    renmu  
       2023-02-21 23:38:38 +08:00 via Android   ❤️ 1
    我一般都是下班前一个 commit (笑
    silentsky
        8
    silentsky  
       2023-02-21 23:40:02 +08:00 via Android   ❤️ 1
    搞那么多 commit ,冲突合并都费劲
    zjp
        9
    zjp  
       2023-02-21 23:41:41 +08:00 via Android   ❤️ 1
    开发分支完成一版就提交,还会有一些小修复的提交
    合并主干时用 squash ,基本一个需求一个提交
    typing
        10
    typing  
       2023-02-22 00:09:08 +08:00 via iPhone   ❤️ 1
    随心所欲 commit 。我一般把 commit 当“保存”用。

    但 PR 之前:fixup 所有临时 commit ,reset ,add -p ,以基本逻辑为单位 commit ,写正经的 commit message
    biabia123456
        11
    biabia123456  
       2023-02-22 00:11:13 +08:00
    @typing #10 你可以试试 rebase 没必要 reset 万一操作失误就尴尬了
    lslqtz
        12
    lslqtz  
       2023-02-22 00:32:49 +08:00
    分支上小 commit, 最后整合成大 commit 合并到主线
    darkengine
        13
    darkengine  
       2023-02-22 00:44:27 +08:00
    @silentsky 大 commit 处理冲突才是噩梦
    IvanLi127
        14
    IvanLi127  
       2023-02-22 01:03:24 +08:00 via Android
    用小的,当然也不会太小,大概一个功能点一个。
    前段时间喜欢把几个合成一组组比较独立的功能块,不过现在都 mr 到主干,也懒得再合了。。
    我感觉人不是很多的情况下细点就细点。大的 commit ,回撤还麻烦
    IvanLi127
        15
    IvanLi127  
       2023-02-22 01:05:24 +08:00 via Android
    @silentsky 反对,如果 commit 多会导致合并时一直冲突,那是项目设计有问题,任务分配也有问题,技术和非技术上都有问题才会这样。
    silentsky
        16
    silentsky  
       2023-02-22 01:20:32 +08:00 via Android
    @IvanLi127 我指的是 rebase
    hst001
        17
    hst001  
       2023-02-22 01:31:39 +08:00   ❤️ 1
    大小都有,看情况,原则是如果要对 commit 执行 git revert 时尽量安全,或者影响尽可能少
    hackpro
        18
    hackpro  
       2023-02-22 01:37:46 +08:00 via iPhone
    @typing #10 问个弱智的问题
    已经 commit 的 lig history 还能修改吗?
    msg7086
        19
    msg7086  
       2023-02-22 04:20:51 +08:00
    「有必要以丢失信息为代价去 squash 么」

    丢失信息要看丢失的是有效信息还是无效信息。
    比如你做一个网页表单,每加一个文本框就提交一次,一个页面 20 个框交了 20 个 commit ,这就是无效信息。这种 squash 了一点都不心疼。
    但是如果你做一个功能,要改数据库结构要改页面,那你数据库结构交一次,页面交一次,就很合适。
    msg7086
        20
    msg7086  
       2023-02-22 04:22:29 +08:00
    @hackpro Git 你可以当作一个数据库,里面任何一个东西都可以修改(除了 hash 和签名,这个是算出来的)。
    yikyo
        21
    yikyo  
       2023-02-22 04:27:45 +08:00 via iPhone   ❤️ 1
    一定是小的,代码有问题需要排查回滚定位,用 git 二分查哪次递交的问题,你用大 commit 就做不来

    大 commit 合到主分支的这种情况不算
    zhenjiachen
        22
    zhenjiachen  
       2023-02-22 07:29:06 +08:00 via iPhone
    同意用 mr 后 squash 成为一个大的 commit ,使用 mr 的合并并且 squash ,squash 后还可以在 mr 中看到一个个小的 commit 。这样主分支很清爽,也能通过 commit 看到是哪个 mr 的提交
    billzhuang
        23
    billzhuang  
       2023-02-22 07:59:24 +08:00 via iPhone   ❤️ 1
    小步 commit ,merge 时 squash 。

    一个 feature 一个 commit ,要不然就拆 feature 。
    IvanLi127
        24
    IvanLi127  
       2023-02-22 08:14:39 +08:00 via Android
    @silentsky rebase 会这样就不合理啊,除非做的比较低层,性能要求不足以很好地让源代码工程化,不然不至于疯狂冲突
    charlie21
        25
    charlie21  
       2023-02-22 08:22:14 +08:00   ❤️ 1
    有一些 commit 是做在 git repo 里,有一些 commit 是做在自己心里

    如果是为了给别人看到,只在 “专门邀功请赏” 色彩的地方做 commit 。之前在自己心里的 commit 直接写在纯私人工作日志里了

    -

    哈哈。工作日志是啥?就是上一次能 1 小时解决问题这一次用 1 分钟能解决的原因和背后的秘密的所在 / 保存的地方
    julyclyde
        26
    julyclyde  
       2023-02-22 08:36:04 +08:00
    phabricator
    就是会把多个 commit 合并为一个,再增加上它自己的附属信息,然后再合并给主分支

    在小分支上的多个 commit 的历史其实就只能去网页(其实是另一个单独保存 review 的 repo )上看了
    dengji85
        27
    dengji85  
       2023-02-22 08:52:32 +08:00
    学到了,我一直头疼主分支提交记录太乱了了
    superliy
        28
    superliy  
       2023-02-22 09:05:27 +08:00
    我刚入行的时候带我的大姐姐说过,详细的 commit 能让领导知道你在做事
    yogogo
        29
    yogogo  
       2023-02-22 09:22:40 +08:00
    我只要修改就提 commit ,生怕老板不知道我在做事
    wlfeng
        30
    wlfeng  
       2023-02-22 09:51:45 +08:00
    开发分支写完一个功能 commit 一次,累计一堆再提交,万一哪天代码丢了或者盘坏了哭都哭不出来;整体需求开发完成后再合并到生产分支;
    zhchyu999
        31
    zhchyu999  
       2023-02-22 10:06:38 +08:00
    小 commit 快跑
    另外谁后合并谁尴尬
    baiyi
        32
    baiyi  
       2023-02-22 10:10:21 +08:00   ❤️ 2
    提交尽量保证原子性原则,也就是一次提交是尽可能少量且不可分割的整体。好处就是 code review 更加简单,代码更容易回滚,更易于追踪变化等等。——《 Pro Git 》
    合入主干可以用 squash ,这样能够保证主干 commits 信息更加清晰,有利于项目整体性进度追踪。
    Liam1997
        33
    Liam1997  
       2023-02-22 10:31:25 +08:00
    我一般是一个新的 feature 新建一个分支,为了防止后续合并解决冲突麻烦,中途会暂时 commit 一次,然后 rebase 一下最新的主分支,再 reset 一下,最后一个 feature 一个大的 commit 提交。

    如果是 bugfix 当然就是小 commit 了。
    nekoneko
        34
    nekoneko  
       2023-02-22 10:50:45 +08:00
    feature 分支多个小 commit, 合并前合成一个大 commit.
    dev 分支和 master 分支随时提交小 commit
    xiaonizi
        35
    xiaonizi  
       2023-02-22 10:57:49 +08:00 via Android
    自从上次看到运维统计月度 commit 量的截图后,我尽量分多次 commit😬
    RICKEYGONG
        36
    RICKEYGONG  
       2023-02-22 11:30:55 +08:00
    下班前必 commit
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5408 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 08:59 · PVG 16:59 · LAX 01:59 · JFK 04:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.