> But if we have multiple branches and we need to cherry pick the patch
> between two different branch. It could be better if the commits is
> much smaller and organized by the functions or the modification
> purposes.
Agree. But just fit for multiple branches in maintaining. So keep `squash` in
If the commits are only for fixing the PR review, I think 'sqash and
merge' is good way to go.
But if we have multiple branches and we need to cherry pick the patch
between two different branch. It could be better if the commits is
much smaller and organized by the functions or the modification
That is based on review, I think. No better way. But I need to be clear,
commits number is just couls help evaluation, not the metric, definitely not a
rule.. Such as in SkyWalking, we have committer with very little codes
contribution. Even, we may promote someone just for helping community,
Good suggestion!
We can try to use milestone to management issues and use `squash and merge`
for the pull request.
One question for `squash and merge` for the pull request. If committer find
some codes or documents are missing, but the pr has already merged, any
suggestion for this situation?
Hi, initial committer
I have known, we are going to move the repos. I think we could expect
ShardingSphere will have more and more contributors from out of initial
committer team. In our Apache releases, we need to provide CHANGELOGS, ref
SkyWalking's[1]. We should make commit logs matching
