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

2019-11-26 12:26:06 +08:00
 JCZ2MkKb5S8ZX9pq


10239 次点击
所在节点    git
54 条回复
zqx
2019-11-26 13:03:08 +08:00
一个 issue 对应一个 commit
sourcetree 的 rebase 好用,可视化的合并提交记录
Rwing
2019-11-26 13:09:28 +08:00
用一行文字能说清
seki
2019-11-26 13:13:14 +08:00
改一点就 commit 一个,merge 的时候 squash 就行

可以参考 git-flow

可以 rebase 自行合并。没有保存价值的不用 commit 进去
woodensail
2019-11-26 13:13:58 +08:00
功能开发时是拉分支,一天提一次,开发完合并回去。
测试时就是改一点提交一次,要是不提交,其他人一发布,自己的改动就没了。
araaaa
2019-11-26 13:17:00 +08:00
改动量较多就 commit,或者自己要做代码测试也 commit 一次
StarUDream
2019-11-26 13:19:44 +08:00
在自己 fork 分支基本写点功能就会 commit,最后合到主分支会 rebase。
shenyuzhi
2019-11-26 13:23:44 +08:00
改动一点就 commit 一次。最后 squash 就行了。
Justin13
2019-11-26 13:23:58 +08:00
功能完备的情况下尽量频繁,如果对 commit 历史有洁癖,再用 rebase 处理。
Jasonwxy
2019-11-26 13:53:36 +08:00
我目前的习惯是一个需求拉一个分支,开发完后,commit,如果之后要基于此 commit 修改的,用 fixup,最后再 rebase autosquash,如果这个分支上有一些跟此需求无关,但是想修改的(比如 lint,style ),会另起一条 commit。最后要合的时候需求一个 commit,其他的看情况。
cco
2019-11-26 13:54:29 +08:00
一个 bug 一个 commit
pkookp8
2019-11-26 13:55:45 +08:00
改一点,保证代码可用就 ci 一次,如果不能保证但是改动量已经很大了,也 ci 一次
wiken
2019-11-26 14:03:28 +08:00
新功能拉新分支做,昨晚 merge 回主线,commit 随意,下班前必 commit
wiken
2019-11-26 14:03:45 +08:00
做完...
realpg
2019-11-26 14:13:09 +08:00
自己的开发 branch 随时随地 commit,哪怕删无用空格。
然后功能级,或者几句话描述得清楚跟其他无关的节点,合并到二级开发 branch
xuanbg
2019-11-26 14:18:28 +08:00
一事一提
kaiser1992
2019-11-26 14:18:47 +08:00
git merge --squash branch_xx
iIli1iIliIllLiL
2019-11-26 14:36:51 +08:00
也可以各个 developer fork 主仓库代码一份到自己的仓库,在自己仓库里面随便 commit,最后大的 issue 完成后提一个 pull request 到主仓库中。
yammy
2019-11-26 14:38:16 +08:00
看什么情况啊,如果是日常,肯定现在自己分支上分小功能提交,然后每个大功能 merge 主分支。如果是提测改 bug 的时候,测试需要看到实时效果,这个时候可能需要 merge 和构建得更频繁一些~
wu67
2019-11-26 14:47:18 +08:00
一个功能点 commit 一次, 尽可能的避免不要某功能了但是一删删一个功能这种情况...阶段 commit 最起码不影响程序正常跑起来
或者一个 bug 一个 commit.
但是一个 issue 就不一定了. 我现在这个项目, 都没人管理分配任务, 都是知道需求后, 自己建个功能开发 issue, 那就涵盖了一个开发周期的功能点了, 这时候一 issue 一 commit 肯定不合适
FrankHB
2019-11-26 15:21:44 +08:00
理想情况下,一个 feature 的固定改动能分隔依赖保持原子性且逻辑上含义明确的,那就应该切得越细越好。
不过有些太大的长期性 repo,实际有被 VCS (不一定是 git,有几个 VCS 之间同步的需求)性能太差而倒逼的情况,为了 commit 数不爆炸,就压缩 commit 了,十几个甚至几十个逻辑上的更改合并成一个(甚至把小的 feature branch 也直接压扁了),然后另外附加 log 描述局部改动。这样虽然工作量更大,但溯源起来反而更简单了。(想想 mozilla-central 的性能,那整个就是呵呵……)
相对来说,维持粒度的手工操作是很头疼但不是影响很大的问题,最大的问题是手工维护的工作量太大这件事……根本上来讲,VCS 要是不懂程序的语义(只会基于文本 diff ),这个问题是无解的,凉拌吧。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/623219

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX