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

[JCZ2MkKb5S8ZX9pq]

• 简单来说就是稍微改点就 commit。
• 还是改到一定程度，阶段性 commit。

---

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

---

• 比如经常改一些注释说明，过一会儿又想起来了稍微改点，就频繁 commit 了。
• 或者有些时候直接在 ide 里改参数测试，退到命令行毕竟有点麻烦，于是参数变了，要不要 commit 进去。
• 类似这样的细节问题挺多的，想问问看大家的习惯是什么样的？

[zqx]

一个 issue 对应一个 commit
sourcetree 的 rebase 好用，可视化的合并提交记录

[Rwing]

用一行文字能说清

[seki]

改一点就 commit 一个，merge 的时候 squash 就行

可以参考 git-flow

可以 rebase 自行合并。没有保存价值的不用 commit 进去

[woodensail]

功能开发时是拉分支，一天提一次，开发完合并回去。
测试时就是改一点提交一次，要是不提交，其他人一发布，自己的改动就没了。

[araaaa]

改动量较多就 commit，或者自己要做代码测试也 commit 一次

[StarUDream]

在自己 fork 分支基本写点功能就会 commit，最后合到主分支会 rebase。

[shenyuzhi]

改动一点就 commit 一次。最后 squash 就行了。

[Justin13]

功能完备的情况下尽量频繁，如果对 commit 历史有洁癖，再用 rebase 处理。

[Jasonwxy]

我目前的习惯是一个需求拉一个分支，开发完后，commit，如果之后要基于此 commit 修改的，用 fixup，最后再 rebase autosquash，如果这个分支上有一些跟此需求无关，但是想修改的（比如 lint,style ），会另起一条 commit。最后要合的时候需求一个 commit，其他的看情况。

[cco]

一个 bug 一个 commit

[pkookp8]

改一点，保证代码可用就 ci 一次，如果不能保证但是改动量已经很大了，也 ci 一次

[wiken]

新功能拉新分支做,昨晚 merge 回主线,commit 随意,下班前必 commit

[wiken]

做完...

[realpg]

自己的开发 branch 随时随地 commit，哪怕删无用空格。
然后功能级，或者几句话描述得清楚跟其他无关的节点，合并到二级开发 branch

[xuanbg]

一事一提

[kaiser1992]

git merge --squash branch_xx

[iIli1iIliIllLiL]

也可以各个 developer fork 主仓库代码一份到自己的仓库，在自己仓库里面随便 commit，最后大的 issue 完成后提一个 pull request 到主仓库中。

[yammy]

看什么情况啊，如果是日常，肯定现在自己分支上分小功能提交，然后每个大功能 merge 主分支。如果是提测改 bug 的时候，测试需要看到实时效果，这个时候可能需要 merge 和构建得更频繁一些~

[wu67]

一个功能点 commit 一次, 尽可能的避免不要某功能了但是一删删一个功能这种情况...阶段 commit 最起码不影响程序正常跑起来
或者一个 bug 一个 commit.
但是一个 issue 就不一定了. 我现在这个项目, 都没人管理分配任务, 都是知道需求后, 自己建个功能开发 issue, 那就涵盖了一个开发周期的功能点了, 这时候一 issue 一 commit 肯定不合适

[FrankHB]

理想情况下，一个 feature 的固定改动能分隔依赖保持原子性且逻辑上含义明确的，那就应该切得越细越好。
不过有些太大的长期性 repo，实际有被 VCS （不一定是 git，有几个 VCS 之间同步的需求）性能太差而倒逼的情况，为了 commit 数不爆炸，就压缩 commit 了，十几个甚至几十个逻辑上的更改合并成一个（甚至把小的 feature branch 也直接压扁了），然后另外附加 log 描述局部改动。这样虽然工作量更大，但溯源起来反而更简单了。（想想 mozilla-central 的性能，那整个就是呵呵……）
相对来说，维持粒度的手工操作是很头疼但不是影响很大的问题，最大的问题是手工维护的工作量太大这件事……根本上来讲，VCS 要是不懂程序的语义（只会基于文本 diff ），这个问题是无解的，凉拌吧。

[FrankHB]

对于不那么大的多数 repo，我还就是“理论上是不是应该是 branch 出来改，阶段性改完再 merge 回 master”这样做的。这个做法最大的问题是自己有强迫症能统一就好说，跟别人协作的时候就未必那么痛快了。
“经常改一些注释说明，过一会儿又想起来了稍微改点，就频繁 commit 了”，这种情况（特别是同一个文件原地更新）属于同一个 feature 没做完，squash commit 是应该的。而且至少 git 做这个很容易（像 hg 这种历史不容篡改强迫症嘛……不过好歹有 mq ）。实际上更坑的经常是 push 太早了得 --force ……
测试用参数一般属于每用户配置，公开的 repo 不 commit，直接 ignore 排除掉。当然，如果你就是为了保存自己的配置才开的 repo 自然另当别论，取决于你愿意什么改动能在之后找得到。
另外，有的 repo 维护者会要求 squash/merge 优先，这个情况一般自然客随主便。

[Exin]

通常是与我的任务规划粒度对应的，
每个任务细分为 n 个步骤的话，每个步骤对应一次 commit
如果一个 commit 太大了，可能是因为规划任务的时候低估了这种工作，要引起注意
最后再逐个 commit 地 review，会比较方便

[azhangbing]

按功能点 模块细分

[coder2019]

一个功能、一个模块或一个 bug commit 一次

[jeffh]

改一点 commit 一下，merge 前先 rebase -i squash，再合并

[zunceng]

开发的时候 一天一个
修 bug 一个 bug 一个

[qwerthhusn]

个人改一点 commit 一点，然后完整后，再 reset --soft，再重新 add-commit-push

我之前公司刚开始用 Git 的时候，很多人（包括我）压根不会，最后导致提交 graph 图跟北京地铁图一样

[petelin]

squash
@qwerthhusn 你自己的 branch 乱搞都没事合并到 master 的时候 压缩成一个就行了 怎么感觉你描述的还是错误的

[yilingersier]

不仅要 commit,还得 push 啊，这段时间公司电脑升级版本外加装个苹果管理软件 JAMF，格完系统，看着自带 dark 模式电脑正暗暗自喜的时候，心里咯噔一下，卧槽，我特么这个礼拜的代码都在本地 branch 上了

[zclHIT]

小步提交，日常采用 master 单分支开发，上线拉 release 分支部署 UAT 和 prod，好处就是不管哪天要上线，我的整套 pipeline 都是绿的，随时都能交付

[ericgui]

@zclHIT 为啥不用 tag ？而要用 release branch ？求指教

[realpg]

@ericgui 大概是不熟练

[puncsky]

谷歌鼓励每个改动尽量小。百行以内是“小”，三百行以内是“中”，一千行以内是“大”，超过一千行是“超 tm 大”。

https://guigu.io/notes/192-google-software-engineering#%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5

[orzorzorzorz]

做完一件事就体提交一次，一件大事也可以拆成很多小事不是？

[ericgui]

@realpg 不懂你啥意思？

[weixiangzhe]

用 rebase 都不是事，我是没事就 commit，之后看着多久 rebase 一把

[Originalee]

改动尽量小，等出问题的时候好找

[zzugyl]

一个 feature 或者一个 bug，commit 一次。
但是有时候改动很大，也很苦恼。

[11ssss]

小阶段性 保证出问题能够随意回滚

[massacreformash]

平时开发：
需求：用户故事级或任务拆分后的任务级
基础组件：
functional 级

测试：
单一 bug 级

[zclHIT]

@ericgui 谈不上指教，因为在两次迭代之前，可能会基于上次的 release 进行 hotfix，所以需要 release 分支

[littlewing]

新开一个自己的 br，随便 commit，然后 rebase

[zclHIT]

@realpg 如果单 master 分支，打 tag 的方式，在 sprint1 我完成了功能 A，做了 sprint2 的时候做了功能 B 做了一半，还没有到 sprint2 release 阶段但是需要尽快 hotfix 功能 A 的话，怎么办呢 0.0 求指教。。。

[zunceng]

@FrankHB 我觉得你可以试试 这个工具的 workflow https://www.phacility.com/phabricator/
可以先发一个 pre-commit review ，过程中可以修改更新，完成后合并成一个 Diff 提交到 repo 中

[zclHIT]

@ericgui 更正。。。/ ***两次迭代之间*** /

[ericgui]

@zclHIT 不是不推荐做 rebase 吗

[yuankui]

有空就 commit

[LoNeFong]

git rebase -i

[AstroProfundis]

一个任务 /功能 / issue 开一个分支，然后每改一个小点就 commit 一次，尽量让一个 commit 只做一件事情，形成一个可能有多个 commits 的分支
这样的好处是 rebase 的时候处理冲突要容易很多，因为每个 commit 改的内容少写 commit log 也基本一句话完事，并且 review 也方便一些
然后 pr 回 master, 在合并的时候如果不希望 commit 记录太乱可以 squash

[hantsy]

本地 Commit 几次，有什么遗漏, 下次 Commit 的时候 --amend。
已经提交的在合并到 Master 之前，rebase -i upstream/master

[GopherTT]

想想 review 的时候如何不难受 你就怎么 commit

[rizon]

回想了一下自己 commit 的几个场景
1、临时做一些测试性的代码，不是测试用例，是那种要大范围临时改代码，这时候我就会把代码 commit 之后随便改着测试完事后一个 revert 撤销掉。当然也可以用 stash 代替。
2、需要拉其他人的代码就得先 commit 再 pull，不想用 stash 或自动本地 merge 是为了预防把我代码覆盖掉
3、每天下班前提交一次，就算功能没写完只要能正常编译通过不影响其他人用就行了。
4、感觉这段写的很好，以防丢失 commit 之后赶紧 push 一下会比较心安。
5、这段还没 commit 的代码想要重写一下，先 commit 之后再改

[wangyzj]

一个功能一个 commit 或者一个 bug 一个 commit

[FrankHB]

@zunceng Phabricator 我一直有计划要上的，主要是看 BitBucket 都要下线 hg 了，找公用的 hosting site 还不如自己内部直接维护全套的。不过这玩意儿整个部署起来还是麻烦，而且也没法解决 VCS 内部不能感知 diff 语义的更根本的问题。可能总有一天这部分也得自己造轮子了。