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