V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
JCZ2MkKb5S8ZX9pq
V2EX  ›  git

大家 commit 的颗粒度是怎样的?

  •  
  •   JCZ2MkKb5S8ZX9pq · 2019-11-26 12:26:06 +08:00 · 10420 次点击
    这是一个创建于 1822 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 简单来说就是稍微改点就 commit。
    • 还是改到一定程度,阶段性 commit。

    • 理论上是不是应该是 branch 出来改,阶段性改完再 merge 回 master。
      到时候可以删掉过程分支,这样 master 看上去漂亮点。
      但说实话,实际操作的时候,我习惯还没这么好……

    • 比如经常改一些注释说明,过一会儿又想起来了稍微改点,就频繁 commit 了。
    • 或者有些时候直接在 ide 里改参数测试,退到命令行毕竟有点麻烦,于是参数变了,要不要 commit 进去。
    • 类似这样的细节问题挺多的,想问问看大家的习惯是什么样的?
    54 条回复    2019-11-28 20:33:16 +08:00
    zqx
        1
    zqx  
       2019-11-26 13:03:08 +08:00 via Android
    一个 issue 对应一个 commit
    sourcetree 的 rebase 好用,可视化的合并提交记录
    Rwing
        2
    Rwing  
       2019-11-26 13:09:28 +08:00
    用一行文字能说清
    seki
        3
    seki  
       2019-11-26 13:13:14 +08:00   ❤️ 2
    改一点就 commit 一个,merge 的时候 squash 就行

    可以参考 git-flow

    可以 rebase 自行合并。没有保存价值的不用 commit 进去
    woodensail
        4
    woodensail  
       2019-11-26 13:13:58 +08:00
    功能开发时是拉分支,一天提一次,开发完合并回去。
    测试时就是改一点提交一次,要是不提交,其他人一发布,自己的改动就没了。
    araaaa
        5
    araaaa  
       2019-11-26 13:17:00 +08:00
    改动量较多就 commit,或者自己要做代码测试也 commit 一次
    StarUDream
        6
    StarUDream  
       2019-11-26 13:19:44 +08:00
    在自己 fork 分支基本写点功能就会 commit,最后合到主分支会 rebase。
    shenyuzhi
        7
    shenyuzhi  
       2019-11-26 13:23:44 +08:00
    改动一点就 commit 一次。最后 squash 就行了。
    Justin13
        8
    Justin13  
       2019-11-26 13:23:58 +08:00 via Android
    功能完备的情况下尽量频繁,如果对 commit 历史有洁癖,再用 rebase 处理。
    Jasonwxy
        9
    Jasonwxy  
       2019-11-26 13:53:36 +08:00
    我目前的习惯是一个需求拉一个分支,开发完后,commit,如果之后要基于此 commit 修改的,用 fixup,最后再 rebase autosquash,如果这个分支上有一些跟此需求无关,但是想修改的(比如 lint,style ),会另起一条 commit。最后要合的时候需求一个 commit,其他的看情况。
    cco
        10
    cco  
       2019-11-26 13:54:29 +08:00
    一个 bug 一个 commit
    pkookp8
        11
    pkookp8  
       2019-11-26 13:55:45 +08:00 via Android
    改一点,保证代码可用就 ci 一次,如果不能保证但是改动量已经很大了,也 ci 一次
    wiken
        12
    wiken  
       2019-11-26 14:03:28 +08:00   ❤️ 1
    新功能拉新分支做,昨晚 merge 回主线,commit 随意,下班前必 commit
    wiken
        13
    wiken  
       2019-11-26 14:03:45 +08:00
    做完...
    realpg
        14
    realpg  
       2019-11-26 14:13:09 +08:00
    自己的开发 branch 随时随地 commit,哪怕删无用空格。
    然后功能级,或者几句话描述得清楚跟其他无关的节点,合并到二级开发 branch
    xuanbg
        15
    xuanbg  
       2019-11-26 14:18:28 +08:00
    一事一提
    kaiser1992
        16
    kaiser1992  
       2019-11-26 14:18:47 +08:00
    git merge --squash branch_xx
    iIli1iIliIllLiL
        17
    iIli1iIliIllLiL  
       2019-11-26 14:36:51 +08:00
    也可以各个 developer fork 主仓库代码一份到自己的仓库,在自己仓库里面随便 commit,最后大的 issue 完成后提一个 pull request 到主仓库中。
    yammy
        18
    yammy  
       2019-11-26 14:38:16 +08:00
    看什么情况啊,如果是日常,肯定现在自己分支上分小功能提交,然后每个大功能 merge 主分支。如果是提测改 bug 的时候,测试需要看到实时效果,这个时候可能需要 merge 和构建得更频繁一些~
    wu67
        19
    wu67  
       2019-11-26 14:47:18 +08:00
    一个功能点 commit 一次, 尽可能的避免不要某功能了但是一删删一个功能这种情况...阶段 commit 最起码不影响程序正常跑起来
    或者一个 bug 一个 commit.
    但是一个 issue 就不一定了. 我现在这个项目, 都没人管理分配任务, 都是知道需求后, 自己建个功能开发 issue, 那就涵盖了一个开发周期的功能点了, 这时候一 issue 一 commit 肯定不合适
    FrankHB
        20
    FrankHB  
       2019-11-26 15:21:44 +08:00
    理想情况下,一个 feature 的固定改动能分隔依赖保持原子性且逻辑上含义明确的,那就应该切得越细越好。
    不过有些太大的长期性 repo,实际有被 VCS (不一定是 git,有几个 VCS 之间同步的需求)性能太差而倒逼的情况,为了 commit 数不爆炸,就压缩 commit 了,十几个甚至几十个逻辑上的更改合并成一个(甚至把小的 feature branch 也直接压扁了),然后另外附加 log 描述局部改动。这样虽然工作量更大,但溯源起来反而更简单了。(想想 mozilla-central 的性能,那整个就是呵呵……)
    相对来说,维持粒度的手工操作是很头疼但不是影响很大的问题,最大的问题是手工维护的工作量太大这件事……根本上来讲,VCS 要是不懂程序的语义(只会基于文本 diff ),这个问题是无解的,凉拌吧。
    FrankHB
        21
    FrankHB  
       2019-11-26 15:30:41 +08:00
    对于不那么大的多数 repo,我还就是“理论上是不是应该是 branch 出来改,阶段性改完再 merge 回 master”这样做的。这个做法最大的问题是自己有强迫症能统一就好说,跟别人协作的时候就未必那么痛快了。
    “经常改一些注释说明,过一会儿又想起来了稍微改点,就频繁 commit 了”,这种情况(特别是同一个文件原地更新)属于同一个 feature 没做完,squash commit 是应该的。而且至少 git 做这个很容易(像 hg 这种历史不容篡改强迫症嘛……不过好歹有 mq )。实际上更坑的经常是 push 太早了得 --force ……
    测试用参数一般属于每用户配置,公开的 repo 不 commit,直接 ignore 排除掉。当然,如果你就是为了保存自己的配置才开的 repo 自然另当别论,取决于你愿意什么改动能在之后找得到。
    另外,有的 repo 维护者会要求 squash/merge 优先,这个情况一般自然客随主便。
    Exin
        22
    Exin  
       2019-11-26 16:56:50 +08:00
    通常是与我的任务规划粒度对应的,
    每个任务细分为 n 个步骤的话,每个步骤对应一次 commit
    如果一个 commit 太大了,可能是因为规划任务的时候低估了这种工作,要引起注意
    最后再逐个 commit 地 review,会比较方便
    azhangbing
        23
    azhangbing  
       2019-11-26 17:08:56 +08:00 via iPhone
    按功能点 模块细分
    coder2019
        24
    coder2019  
       2019-11-26 17:19:47 +08:00
    一个功能、一个模块或一个 bug commit 一次
    jeffh
        25
    jeffh  
       2019-11-26 19:24:39 +08:00
    改一点 commit 一下,merge 前先 rebase -i squash,再合并
    zunceng
        26
    zunceng  
       2019-11-26 19:59:46 +08:00
    开发的时候 一天一个
    修 bug 一个 bug 一个
    qwerthhusn
        27
    qwerthhusn  
       2019-11-26 20:09:07 +08:00
    个人改一点 commit 一点,然后完整后,再 reset --soft,再重新 add-commit-push

    我之前公司刚开始用 Git 的时候,很多人(包括我)压根不会,最后导致提交 graph 图跟北京地铁图一样
    petelin
        28
    petelin  
       2019-11-26 22:15:19 +08:00 via iPhone
    squash
    @qwerthhusn 你自己的 branch 乱搞都没事合并到 master 的时候 压缩成一个就行了 怎么感觉你描述的还是错误的
    yilingersier
        29
    yilingersier  
       2019-11-26 22:42:10 +08:00
    不仅要 commit,还得 push 啊,这段时间公司电脑升级版本外加装个苹果管理软件 JAMF,格完系统,看着自带 dark 模式电脑正暗暗自喜的时候,心里咯噔一下,卧槽,我特么这个礼拜的代码都在本地 branch 上了
    zclHIT
        30
    zclHIT  
       2019-11-26 23:55:37 +08:00
    小步提交,日常采用 master 单分支开发,上线拉 release 分支部署 UAT 和 prod,好处就是不管哪天要上线,我的整套 pipeline 都是绿的,随时都能交付
    ericgui
        31
    ericgui  
       2019-11-27 05:31:58 +08:00
    @zclHIT 为啥不用 tag ?而要用 release branch ?求指教
    realpg
        32
    realpg  
       2019-11-27 06:50:24 +08:00 via Android
    @ericgui 大概是不熟练
    puncsky
        33
    puncsky  
       2019-11-27 06:56:15 +08:00
    谷歌鼓励每个改动尽量小。百行以内是“小”,三百行以内是“中”,一千行以内是“大”,超过一千行是“超 tm 大”。

    https://guigu.io/notes/192-google-software-engineering#%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5
    orzorzorzorz
        34
    orzorzorzorz  
       2019-11-27 07:22:25 +08:00 via Android
    做完一件事就体提交一次,一件大事也可以拆成很多小事不是?
    ericgui
        35
    ericgui  
       2019-11-27 07:46:26 +08:00 via Android
    @realpg 不懂你啥意思?
    weixiangzhe
        36
    weixiangzhe  
       2019-11-27 08:08:26 +08:00 via Android
    用 rebase 都不是事,我是没事就 commit,之后看着多久 rebase 一把
    Originalee
        37
    Originalee  
       2019-11-27 08:41:02 +08:00
    改动尽量小,等出问题的时候好找
    zzugyl
        38
    zzugyl  
       2019-11-27 09:05:42 +08:00
    一个 feature 或者一个 bug,commit 一次。
    但是有时候改动很大,也很苦恼。
    11ssss
        39
    11ssss  
       2019-11-27 10:03:29 +08:00
    小阶段性 保证出问题能够随意回滚
    massacreformash
        40
    massacreformash  
       2019-11-27 11:18:21 +08:00
    平时开发:
    需求:用户故事级或任务拆分后的任务级
    基础组件:
    functional 级

    测试:
    单一 bug 级
    zclHIT
        41
    zclHIT  
       2019-11-27 12:41:48 +08:00
    @ericgui 谈不上指教,因为在两次迭代之前,可能会基于上次的 release 进行 hotfix,所以需要 release 分支
    littlewing
        42
    littlewing  
       2019-11-27 12:44:29 +08:00
    新开一个自己的 br,随便 commit,然后 rebase
    zclHIT
        43
    zclHIT  
       2019-11-27 12:46:39 +08:00
    @realpg 如果单 master 分支,打 tag 的方式,在 sprint1 我完成了功能 A,做了 sprint2 的时候做了功能 B 做了一半,还没有到 sprint2 release 阶段但是需要尽快 hotfix 功能 A 的话,怎么办呢 0.0 求指教。。。
    zunceng
        44
    zunceng  
       2019-11-27 13:03:19 +08:00
    @FrankHB 我觉得你可以试试 这个工具的 workflow https://www.phacility.com/phabricator/
    可以先发一个 pre-commit review ,过程中可以修改更新,完成后合并成一个 Diff 提交到 repo 中
    zclHIT
        45
    zclHIT  
       2019-11-27 13:05:39 +08:00
    @ericgui 更正。。。/ ***两次迭代之间*** /
    ericgui
        46
    ericgui  
       2019-11-27 13:29:14 +08:00
    @zclHIT 不是不推荐做 rebase 吗
    yuankui
        47
    yuankui  
       2019-11-27 13:58:21 +08:00
    有空就 commit
    LoNeFong
        48
    LoNeFong  
       2019-11-27 16:01:50 +08:00
    git rebase -i
    AstroProfundis
        49
    AstroProfundis  
       2019-11-27 16:08:17 +08:00
    一个任务 /功能 / issue 开一个分支,然后每改一个小点就 commit 一次,尽量让一个 commit 只做一件事情,形成一个可能有多个 commits 的分支
    这样的好处是 rebase 的时候处理冲突要容易很多,因为每个 commit 改的内容少写 commit log 也基本一句话完事,并且 review 也方便一些
    然后 pr 回 master, 在合并的时候如果不希望 commit 记录太乱可以 squash
    hantsy
        50
    hantsy  
       2019-11-27 16:18:20 +08:00
    本地 Commit 几次,有什么遗漏, 下次 Commit 的时候 --amend。
    已经提交的在合并到 Master 之前,rebase -i upstream/master
    GopherTT
        51
    GopherTT  
       2019-11-27 16:19:54 +08:00
    想想 review 的时候如何不难受 你就怎么 commit
    rizon
        52
    rizon  
       2019-11-27 16:38:58 +08:00
    回想了一下自己 commit 的几个场景
    1、临时做一些测试性的代码,不是测试用例,是那种要大范围临时改代码,这时候我就会把代码 commit 之后随便改着测试完事后一个 revert 撤销掉。当然也可以用 stash 代替。
    2、需要拉其他人的代码就得先 commit 再 pull,不想用 stash 或自动本地 merge 是为了预防把我代码覆盖掉
    3、每天下班前提交一次,就算功能没写完只要能正常编译通过不影响其他人用就行了。
    4、感觉这段写的很好,以防丢失 commit 之后赶紧 push 一下会比较心安。
    5、这段还没 commit 的代码想要重写一下,先 commit 之后再改
    wangyzj
        53
    wangyzj  
       2019-11-28 00:42:37 +08:00
    一个功能一个 commit 或者一个 bug 一个 commit
    FrankHB
        54
    FrankHB  
       2019-11-28 20:33:16 +08:00
    @zunceng Phabricator 我一直有计划要上的,主要是看 BitBucket 都要下线 hg 了,找公用的 hosting site 还不如自己内部直接维护全套的。不过这玩意儿整个部署起来还是麻烦,而且也没法解决 VCS 内部不能感知 diff 语义的更根本的问题。可能总有一天这部分也得自己造轮子了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5763 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 01:52 · PVG 09:52 · LAX 17:52 · JFK 20:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.