这是一个创建于 639 天前的主题，其中的信息可能已经有所发展或是发生改变。
我自己喜欢用很多细小的 commit ，但我注意到一些天才型的工程师喜欢用大 commit：）
 |
1
wangkun025 2023-02-21 23:30:02 +08:00  2
也许，他们是合并过的 commit
|
 |
2
ql562482472 2023-02-21 23:30:30 +08:00 2
squash ！
|
 |
3
dzdh 2023-02-21 23:33:21 +08:00 1
我习惯切个新分支，在这个分支上很多小 commit ，然后切成一个大 commit 重新切个分支然后在 merge 到主干分支。
|
 |
4
gowl OP 追一个问题：如果是自己的项目，有必要以丢失信息为代价去 squash 么？
|
 |
6
silentsky 2023-02-21 23:36:38 +08:00 via Android 1
我喜欢大 commit ，一般都是一个需求一个 commit
|
 |
7
renmu 2023-02-21 23:38:38 +08:00 via Android 1
我一般都是下班前一个 commit （笑
|
|
8
silentsky 2023-02-21 23:40:02 +08:00 via Android 1
搞那么多 commit ，冲突合并都费劲
|
 |
9
zjp 2023-02-21 23:41:41 +08:00 via Android 1
开发分支完成一版就提交，还会有一些小修复的提交
合并主干时用 squash ，基本一个需求一个提交 |
 |
10
typing 2023-02-22 00:09:08 +08:00 via iPhone 1
随心所欲 commit 。我一般把 commit 当“保存”用。
但 PR 之前：fixup 所有临时 commit ，reset ，add -p ，以基本逻辑为单位 commit ，写正经的 commit message |
 |
11
biabia123456 2023-02-22 00:11:13 +08:00
@typing #10 你可以试试 rebase 没必要 reset 万一操作失误就尴尬了
|
 |
12
lslqtz 2023-02-22 00:32:49 +08:00
分支上小 commit, 最后整合成大 commit 合并到主线
|
 |
13
darkengine 2023-02-22 00:44:27 +08:00
@silentsky 大 commit 处理冲突才是噩梦
|
 |
14
IvanLi127 2023-02-22 01:03:24 +08:00 via Android
用小的，当然也不会太小，大概一个功能点一个。
前段时间喜欢把几个合成一组组比较独立的功能块，不过现在都 mr 到主干，也懒得再合了。。 我感觉人不是很多的情况下细点就细点。大的 commit ，回撤还麻烦 |
|
15
IvanLi127 2023-02-22 01:05:24 +08:00 via Android
@silentsky 反对，如果 commit 多会导致合并时一直冲突，那是项目设计有问题，任务分配也有问题，技术和非技术上都有问题才会这样。
|
 |
17
hst001 2023-02-22 01:31:39 +08:00 1
大小都有，看情况，原则是如果要对 commit 执行 git revert 时尽量安全，或者影响尽可能少
|
 |
19
msg7086 2023-02-22 04:20:51 +08:00
「有必要以丢失信息为代价去 squash 么」
丢失信息要看丢失的是有效信息还是无效信息。 比如你做一个网页表单，每加一个文本框就提交一次，一个页面 20 个框交了 20 个 commit ，这就是无效信息。这种 squash 了一点都不心疼。 但是如果你做一个功能，要改数据库结构要改页面，那你数据库结构交一次，页面交一次，就很合适。 |
 |
21
yikyo 2023-02-22 04:27:45 +08:00 via iPhone 1
一定是小的，代码有问题需要排查回滚定位，用 git 二分查哪次递交的问题，你用大 commit 就做不来
大 commit 合到主分支的这种情况不算 |
 |
22
zhenjiachen 2023-02-22 07:29:06 +08:00 via iPhone
同意用 mr 后 squash 成为一个大的 commit ，使用 mr 的合并并且 squash ，squash 后还可以在 mr 中看到一个个小的 commit 。这样主分支很清爽，也能通过 commit 看到是哪个 mr 的提交
|
 |
23
billzhuang 2023-02-22 07:59:24 +08:00 via iPhone 1
小步 commit ，merge 时 squash 。
一个 feature 一个 commit ，要不然就拆 feature 。 |
|
24
IvanLi127 2023-02-22 08:14:39 +08:00 via Android
@silentsky rebase 会这样就不合理啊，除非做的比较低层，性能要求不足以很好地让源代码工程化，不然不至于疯狂冲突
|
 |
25
charlie21 2023-02-22 08:22:14 +08:00 1
有一些 commit 是做在 git repo 里，有一些 commit 是做在自己心里
如果是为了给别人看到，只在 “专门邀功请赏” 色彩的地方做 commit 。之前在自己心里的 commit 直接写在纯私人工作日志里了 - 哈哈。工作日志是啥？就是上一次能 1 小时解决问题这一次用 1 分钟能解决的原因和背后的秘密的所在 / 保存的地方 |
 |
26
julyclyde 2023-02-22 08:36:04 +08:00
phabricator
就是会把多个 commit 合并为一个，再增加上它自己的附属信息，然后再合并给主分支 在小分支上的多个 commit 的历史其实就只能去网页（其实是另一个单独保存 review 的 repo ）上看了 |
 |
27
dengji85 2023-02-22 08:52:32 +08:00
学到了，我一直头疼主分支提交记录太乱了了
|
 |
28
superliy 2023-02-22 09:05:27 +08:00
我刚入行的时候带我的大姐姐说过，详细的 commit 能让领导知道你在做事
|
 |
29
yogogo 2023-02-22 09:22:40 +08:00
我只要修改就提 commit ，生怕老板不知道我在做事
|
 |
30
wlfeng 2023-02-22 09:51:45 +08:00
开发分支写完一个功能 commit 一次，累计一堆再提交，万一哪天代码丢了或者盘坏了哭都哭不出来；整体需求开发完成后再合并到生产分支；
|
 |
31
zhchyu999 2023-02-22 10:06:38 +08:00
小 commit 快跑
另外谁后合并谁尴尬 |
 |
32
baiyi 2023-02-22 10:10:21 +08:00 2
提交尽量保证原子性原则，也就是一次提交是尽可能少量且不可分割的整体。好处就是 code review 更加简单，代码更容易回滚，更易于追踪变化等等。——《 Pro Git 》
合入主干可以用 squash ，这样能够保证主干 commits 信息更加清晰，有利于项目整体性进度追踪。 |
 |
33
Liam1997 2023-02-22 10:31:25 +08:00
我一般是一个新的 feature 新建一个分支，为了防止后续合并解决冲突麻烦，中途会暂时 commit 一次，然后 rebase 一下最新的主分支，再 reset 一下，最后一个 feature 一个大的 commit 提交。
如果是 bugfix 当然就是小 commit 了。 |
 |
34
nekoneko 2023-02-22 10:50:45 +08:00
feature 分支多个小 commit, 合并前合成一个大 commit.
dev 分支和 master 分支随时提交小 commit |
 |
35
xiaonizi 2023-02-22 10:57:49 +08:00 via Android
自从上次看到运维统计月度 commit 量的截图后，我尽量分多次 commit😬
|
 |
36
RICKEYGONG 2023-02-22 11:30:55 +08:00
下班前必 commit
|
Select Language