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
|