一个PR在merge之前commit很多次会有什么负面影响吗？

jamesthu 发表于 2021-10-09 18:54:54
就是有时候你的branch落后于master了，要rebase一下。不然有的test过不了。我其实不是很了解ci的原理。因为change set还是一样的。为啥了rebase test就能过，不reb

rebase之后，是不是其他人merge的东西就会更新到自己的local 呢？我很少用这个command。lol。

被pip应该是code review多次导致的多次commit，而不是你自己习惯多次commit的。因为个人习惯或者self review导致的多次commit，别人无权评论，只要你的多次不是特别不合理。

补充内容 (2021-10-10 10:08 +08:00):
补充一下，如果已经add 别人为reviewer以后就不要疯狂push了，因为你每次push，别人都能收到邮件，这样别人会觉得你怎么老是改来改去的。

个人鄙见。commit数量和程序员本身，task还有code本身design都有关系，有不少task是需要break为多个commit来做。不过有几种情况需要避免多个commit:
1. 没有本地跑test, lint, format check就push，回头发现自动代码测试错了，然后改又push新的commit。一般很多初级sde（尤其常见转码和初级python dev）很容易犯这种让人印象打折的错
2. Design的时候问题没有定义清楚，也没有清楚task scope，需求改来改去，这个在敏捷开发团队蛮常见，很难根除。尤其开始拓展业务为了速度可能会耦合多个业务到一个代码里面，改一个地方很多地方都需要改，所以很容易导致测试甚至业务出错，commit多也是自然的。这时候需要说服团队拿出时间进行代码解耦，解决一些tech debt
3. 和其他同事的见解不一样。这个一般也是前期沟通的问题，尽量在文档层面解决，而不是在后面才用review来讨论

oefox000000 发表于 2021-10-09 19:12:21
个人鄙见。commit数量和程序员本身，task还有code本身design都有关系，有不少task是需要break为多个commit来做。不过有几种情况需要避免多个commit:
1. 没有本地跑t

如果python，推荐pre-commit和 black可以帮你避免第一种的format commit。pycharm会比vs code更智能一些（听说学生可以申请免费用）
如果是static typing的语言，虽然损失了灵活性，debug确实更方便

squash zszszs

我看我司的大牛经常一个PR，git push 10+ 次，就不用说commit了
写code当然是怎么顺手怎么快怎么来了

每次push都要rebase一下吧，最后到github上每个PR就一个commit，多了有问题，但我也不知道啥问题，经理讲的。。。

git commit —amend —no-edit了解一下

我们项目所有的pr都是一个commit，修改都是force push。reviewable会处理好不同version的diff问题

匿名用户 发表于 2021-10-09 17:27:38
我都是10+，每改一行就commit一个，生怕没保存白改了，只要不让peer反复review我觉得就没事

push之前最好squash一下，不然太乱了