这是一个创建于 1859 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 简单来说就是稍微改点就 commit。
- 还是改到一定程度，阶段性 commit。
- 理论上是不是应该是 branch 出来改，阶段性改完再 merge 回 master。
到时候可以删掉过程分支，这样 master 看上去漂亮点。
但说实话，实际操作的时候，我习惯还没这么好……
- 比如经常改一些注释说明，过一会儿又想起来了稍微改点，就频繁 commit 了。
- 或者有些时候直接在 ide 里改参数测试，退到命令行毕竟有点麻烦，于是参数变了，要不要 commit 进去。
- 类似这样的细节问题挺多的，想问问看大家的习惯是什么样的？
 |
1
zqx 2019-11-26 13:03:08 +08:00 via Android
一个 issue 对应一个 commit
sourcetree 的 rebase 好用，可视化的合并提交记录 |
 |
2
Rwing 2019-11-26 13:09:28 +08:00
用一行文字能说清
|
 |
3
seki 2019-11-26 13:13:14 +08:00  2
改一点就 commit 一个，merge 的时候 squash 就行
可以参考 git-flow 可以 rebase 自行合并。没有保存价值的不用 commit 进去 |
 |
4
woodensail 2019-11-26 13:13:58 +08:00
功能开发时是拉分支，一天提一次，开发完合并回去。
测试时就是改一点提交一次，要是不提交，其他人一发布，自己的改动就没了。 |
 |
5
araaaa 2019-11-26 13:17:00 +08:00
改动量较多就 commit，或者自己要做代码测试也 commit 一次
|
 |
6
StarUDream 2019-11-26 13:19:44 +08:00
在自己 fork 分支基本写点功能就会 commit，最后合到主分支会 rebase。
|
 |
7
shenyuzhi 2019-11-26 13:23:44 +08:00
改动一点就 commit 一次。最后 squash 就行了。
|
 |
8
Justin13 2019-11-26 13:23:58 +08:00 via Android
功能完备的情况下尽量频繁，如果对 commit 历史有洁癖，再用 rebase 处理。
|
 |
9
Jasonwxy 2019-11-26 13:53:36 +08:00
我目前的习惯是一个需求拉一个分支，开发完后，commit，如果之后要基于此 commit 修改的，用 fixup，最后再 rebase autosquash，如果这个分支上有一些跟此需求无关，但是想修改的（比如 lint,style ），会另起一条 commit。最后要合的时候需求一个 commit，其他的看情况。
|
 |
10
cco 2019-11-26 13:54:29 +08:00
一个 bug 一个 commit
|
 |
11
pkookp8 2019-11-26 13:55:45 +08:00 via Android
改一点，保证代码可用就 ci 一次，如果不能保证但是改动量已经很大了，也 ci 一次
|
 |
12
wiken 2019-11-26 14:03:28 +08:00 1
新功能拉新分支做,昨晚 merge 回主线,commit 随意,下班前必 commit
|
|
13
wiken 2019-11-26 14:03:45 +08:00
做完...
|
 |
14
realpg 2019-11-26 14:13:09 +08:00
自己的开发 branch 随时随地 commit，哪怕删无用空格。
然后功能级，或者几句话描述得清楚跟其他无关的节点，合并到二级开发 branch |
 |
15
xuanbg 2019-11-26 14:18:28 +08:00
一事一提
|
 |
16
kaiser1992 2019-11-26 14:18:47 +08:00
git merge --squash branch_xx
|
 |
17
iIli1iIliIllLiL 2019-11-26 14:36:51 +08:00
也可以各个 developer fork 主仓库代码一份到自己的仓库，在自己仓库里面随便 commit，最后大的 issue 完成后提一个 pull request 到主仓库中。
|
 |
18
yammy 2019-11-26 14:38:16 +08:00
看什么情况啊，如果是日常，肯定现在自己分支上分小功能提交，然后每个大功能 merge 主分支。如果是提测改 bug 的时候，测试需要看到实时效果，这个时候可能需要 merge 和构建得更频繁一些~
|
 |
19
wu67 2019-11-26 14:47:18 +08:00
一个功能点 commit 一次, 尽可能的避免不要某功能了但是一删删一个功能这种情况...阶段 commit 最起码不影响程序正常跑起来
或者一个 bug 一个 commit. 但是一个 issue 就不一定了. 我现在这个项目, 都没人管理分配任务, 都是知道需求后, 自己建个功能开发 issue, 那就涵盖了一个开发周期的功能点了, 这时候一 issue 一 commit 肯定不合适 |
 |
20
FrankHB 2019-11-26 15:21:44 +08:00
理想情况下，一个 feature 的固定改动能分隔依赖保持原子性且逻辑上含义明确的，那就应该切得越细越好。
不过有些太大的长期性 repo，实际有被 VCS （不一定是 git，有几个 VCS 之间同步的需求）性能太差而倒逼的情况，为了 commit 数不爆炸，就压缩 commit 了，十几个甚至几十个逻辑上的更改合并成一个（甚至把小的 feature branch 也直接压扁了），然后另外附加 log 描述局部改动。这样虽然工作量更大，但溯源起来反而更简单了。（想想 mozilla-central 的性能，那整个就是呵呵……） 相对来说，维持粒度的手工操作是很头疼但不是影响很大的问题，最大的问题是手工维护的工作量太大这件事……根本上来讲，VCS 要是不懂程序的语义（只会基于文本 diff ），这个问题是无解的，凉拌吧。 |
|
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 优先，这个情况一般自然客随主便。 |
 |
22
Exin 2019-11-26 16:56:50 +08:00
通常是与我的任务规划粒度对应的，
每个任务细分为 n 个步骤的话，每个步骤对应一次 commit 如果一个 commit 太大了，可能是因为规划任务的时候低估了这种工作，要引起注意 最后再逐个 commit 地 review，会比较方便 |
 |
23
azhangbing 2019-11-26 17:08:56 +08:00 via iPhone
按功能点 模块细分
|
 |
24
coder2019 2019-11-26 17:19:47 +08:00
一个功能、一个模块或一个 bug commit 一次
|
 |
25
jeffh 2019-11-26 19:24:39 +08:00
改一点 commit 一下，merge 前先 rebase -i squash，再合并
|
 |
26
zunceng 2019-11-26 19:59:46 +08:00
开发的时候 一天一个
修 bug 一个 bug 一个 |
 |
27
qwerthhusn 2019-11-26 20:09:07 +08:00
个人改一点 commit 一点，然后完整后，再 reset --soft，再重新 add-commit-push
我之前公司刚开始用 Git 的时候，很多人（包括我）压根不会，最后导致提交 graph 图跟北京地铁图一样 |
 |
28
petelin 2019-11-26 22:15:19 +08:00 via iPhone
squash
@qwerthhusn 你自己的 branch 乱搞都没事合并到 master 的时候 压缩成一个就行了 怎么感觉你描述的还是错误的 |
 |
29
yilingersier 2019-11-26 22:42:10 +08:00
不仅要 commit,还得 push 啊，这段时间公司电脑升级版本外加装个苹果管理软件 JAMF，格完系统，看着自带 dark 模式电脑正暗暗自喜的时候，心里咯噔一下，卧槽，我特么这个礼拜的代码都在本地 branch 上了
|
 |
30
zclHIT 2019-11-26 23:55:37 +08:00
小步提交，日常采用 master 单分支开发，上线拉 release 分支部署 UAT 和 prod，好处就是不管哪天要上线，我的整套 pipeline 都是绿的，随时都能交付
|
 |
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 |
 |
34
orzorzorzorz 2019-11-27 07:22:25 +08:00 via Android
做完一件事就体提交一次，一件大事也可以拆成很多小事不是？
|
 |
36
weixiangzhe 2019-11-27 08:08:26 +08:00 via Android
用 rebase 都不是事，我是没事就 commit，之后看着多久 rebase 一把
|
 |
37
Originalee 2019-11-27 08:41:02 +08:00
改动尽量小，等出问题的时候好找
|
 |
38
zzugyl 2019-11-27 09:05:42 +08:00
一个 feature 或者一个 bug，commit 一次。
但是有时候改动很大，也很苦恼。 |
 |
39
11ssss 2019-11-27 10:03:29 +08:00
小阶段性 保证出问题能够随意回滚
|
 |
40
massacreformash 2019-11-27 11:18:21 +08:00
平时开发：
需求：用户故事级或任务拆分后的任务级 基础组件： functional 级 测试： 单一 bug 级 |
|
41
zclHIT 2019-11-27 12:41:48 +08:00
@ericgui 谈不上指教，因为在两次迭代之前，可能会基于上次的 release 进行 hotfix，所以需要 release 分支
|
 |
42
littlewing 2019-11-27 12:44:29 +08:00
新开一个自己的 br，随便 commit，然后 rebase
|
|
43
zclHIT 2019-11-27 12:46:39 +08:00
@realpg 如果单 master 分支，打 tag 的方式，在 sprint1 我完成了功能 A，做了 sprint2 的时候做了功能 B 做了一半，还没有到 sprint2 release 阶段但是需要尽快 hotfix 功能 A 的话，怎么办呢 0.0 求指教。。。
|
|
44
zunceng 2019-11-27 13:03:19 +08:00
@FrankHB 我觉得你可以试试 这个工具的 workflow https://www.phacility.com/phabricator/
可以先发一个 pre-commit review ，过程中可以修改更新，完成后合并成一个 Diff 提交到 repo 中 |
 |
47
yuankui 2019-11-27 13:58:21 +08:00
有空就 commit
|
 |
48
LoNeFong 2019-11-27 16:01:50 +08:00
git rebase -i
|
 |
49
AstroProfundis 2019-11-27 16:08:17 +08:00
一个任务 /功能 / issue 开一个分支，然后每改一个小点就 commit 一次，尽量让一个 commit 只做一件事情，形成一个可能有多个 commits 的分支
这样的好处是 rebase 的时候处理冲突要容易很多，因为每个 commit 改的内容少写 commit log 也基本一句话完事，并且 review 也方便一些 然后 pr 回 master, 在合并的时候如果不希望 commit 记录太乱可以 squash |
 |
50
hantsy 2019-11-27 16:18:20 +08:00
本地 Commit 几次，有什么遗漏, 下次 Commit 的时候 --amend。
已经提交的在合并到 Master 之前，rebase -i upstream/master |
 |
51
GopherTT 2019-11-27 16:19:54 +08:00
想想 review 的时候如何不难受 你就怎么 commit
|
 |
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 之后再改 |
 |
53
wangyzj 2019-11-28 00:42:37 +08:00
一个功能一个 commit 或者一个 bug 一个 commit
|
Select Language