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

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

  •  
  •   JCZ2MkKb5S8ZX9pq · 54 天前 · 6066 次点击
    这是一个创建于 54 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 简单来说就是稍微改点就 commit。
    • 还是改到一定程度,阶段性 commit。

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

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

    可以参考 git-flow

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

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

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

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