So, rebasing should never be used on any branch that has been pushed to the main repo. The only branch I regularly rebase, is my local main development branch.
However, I don’t quite understand, why a “squash merge” is possible, but a normal merge isn’t. Technically they should be the same. Chris Von: LinkinStar <linkins...@apache.org> Datum: Montag, 1. April 2024 um 06:07 An: dev@answer.apache.org <dev@answer.apache.org> Betreff: Re: Quick question about the release process Hi Willem Jiang, You are absolutely correct in what you said. Just as you said, we also do not want to use commands like "git push --force" as they can cause many issues. The solution, as you mentioned, is to use the svn-like-model to replace the current git-flow-model, which would help avoid this problem. Our team will discuss this matter and consider whether we can adopt such a development collaboration model in the future. Thanks again for your suggestions. Best regards, LinkinStar On Mon, Apr 1, 2024 at 11:37 AM Willem Jiang <willem.ji...@gmail.com> wrote: > On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <linkins...@apache.org> wrote: > > > > Hi Willem Jiang, > > > > First of all, thank you for your question. > > > > Firstly, regarding the merging of PRs, we encountered the same issue as > > tisonkun before[1]. During the merge process, we are unable to select the > > "Rebase and merge" option and are forced to choose "Squash and merge." > This > > results in the effect of merging commits that you mentioned. > > We can confirm that we cannot select the "Create a merge commit" and > > "Rebase and merge" options. Furthermore, there are *no conflicts* between > > our branch and the main branch during the merge, *as we also attempted a > > manual merge without conflicts*. Additionally, we cannot resolve this > issue > > through manual merging because we cannot push directly to the main branch > > using git commands; we can only merge the PR using the GitHub web UI. In > > conclusion, we have no other choice but to select the "Squash and merge" > > option. > > > > As the rebase merge approach could change the commit logs of the > branch which were already published. > Normally we can use force push to republish the branch, but it could > cause some trouble for the client to consume the repo. > > > > Secondly, regarding the issue you mentioned about contributors not being > > displayed in the contributors graph, we have just verified it. *All > > contributors from the latest version are shown in the contributors > graph.* > > If you did not see them, we believe this issue might be due to GitHub's > > caching, as the contributors graph is not real-time maybe. Below is the > > list of contributors, excluding members from our internal team. > > > > [x] hgaol > > [x] xpume > > [x] zahash > > [x] hbsciw > > [x] sy-records > > [x] foxzero-007 > > [x] surapuramakhil > > [x] Octobug > > > > As the PR merged, all the commits were squashed, their contribution > only shown in one merged commit. > > > > Lastly, thank you again for your question. If you have any other > > suggestions, please feel free to continue sharing and discussing. > > > > To keep the commit log with squash and merge approach, we may consider > switching the developer process to (svn-like-model) commit all the > changes to the main branch first and create the maintenance branch > after the release from main if needed. In this way all the commits > were added to the main branch as smaller pieces, we just cherry-picked > patches to fork the branch to fix the bugs. > > > > [1] https://github.com/apache/incubator-answer/pull/633 > > > > Best regards, > > LinkinStar > > > > > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@answer.apache.org > For additional commands, e-mail: dev-h...@answer.apache.org > >
