@
UncleCAT4 是指大四大五啦,法国的大学学制是五年的。
@
roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步,一般一个 issue 就是一个 PR ,如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……
@
Contextualist 好建议,我倒是还没太熟悉 rebase 的用法,感谢提醒。
@
tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……
@
GeruzoniAnsasu 示例这个确实不太好,不过一方面也有看团队里一个 PR 也就几个 commit ,我自然会倾向于避免上来就推几十个 commit 的巨型 PR ,所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向,尤其是发了两次包含连续四五个 Refactor 的 PR 之后。
@
Scarb 这个模版倒是不错,有时候我感觉我也有点像在往这方面靠。
@
janus77 会的,会先看 git blame 找出 commit 的历史记录,问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图,所以我才感觉如果有个 commit message 会清晰很多。