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

推荐git  rebase -i master
Interactive rebase 想留几个commit都行

这种东西就是没事找茬，当然对于这块，research team和product team标准也不一样。

jamesthu 发表于 2021-10-9 21:54
就是有时候你的branch落后于master了，要rebase一下。不然有的test过不了。我其实不是很了解ci的原理。因 ...

难道不是git pull --rebase origin master吗

用Google gerrit的表示上传N个patch都不是事

CaesarL 发表于 2021-10-10 01:36:22
我在狗家的实习staff级别的host和我说，rebase是他觉得最烂的git command。。虽然我觉得rebase然后git push force删记录老好用了。。

case by case，master用rebase保持清楚的linear history，feature branch用merge来避免force push。

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

ci是把changeset applied到对应的base commit上来跑test，你rebase了base commit就变了。

在我们公司所有remote branch都是自动跑CI的 （除非加【skip ci】在commit message里）

所以如果你们app也是个monolith的话，经常push跑ci会比较浪费钱哈哈哈哈

JEM 发表于 2021-10-09 23:12:17
有用的，你可以搜搜squash的用法，push的时候git push -f就可以

但是大多数pr都是merge到有保护的branch吧，force会被reject

个人来说不喜欢太多commits，但是如果只是因为这个被pip也有点搞笑

1.revert的时候真的很麻烦，需要每个commit去看一遍，不然容易出错
2.rebase对别人来说也是一个麻烦的事，可能需要resolve conflict多次
3.同时你自己在resolve conflicts的时候也很容易出问题（特别是的你cr以及review了很久，mainline里面已经有了很多别人的代码）， 遇到这种情况，一般来说你需要再发一次cr，对你对reviewer都是extra work

如果实在想track所有commits 并且很在意代码数量，可以考虑merge所有commits，保留每一个commit 同时最后生成一个merged commits 发出去

jsj 发表于 2021-10-10 11:09:20
但是大多数pr都是merge到有保护的branch吧，force会被reject

我意思是发pr的时候，自己那条branch的commit变成1个，push -f的是自己的那个branch，不会去动develop线