Hello Folks, IMO we can say that the squash will be the default one and in some cases the merge will be the best option but it depends on the case, like the example that @Chris gave us . What do you think?
Best regards, Bertty On Sat, Jan 15, 2022 at 9:43 PM Christofer Dutz <[email protected]> wrote: > If it's a bigger piece of work, I would vote for not being strict about > it, as with a squash merge you lose the commit comments the author did. > This sometimes has valuable information. > > Chris > > Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Alexander Alten <[email protected]> > Sent: Saturday, January 15, 2022 10:55:26 AM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS]Code merge method determination > > +1 > > > On 15. Jan 2022, at 10:48, jorge Arnulfo Quiané Ruiz < > [email protected]> wrote: > > > > +1 > > Squash Merge looks good for merging feature from branches to master > > > > On Fri, 14 Jan 2022 at 7:05 AM Joe San <[email protected]> wrote: > > > >> +1 to squash merge for merging from feature branches to master > >> > >> On Fri, Jan 14, 2022 at 6:25 AM CalvinKirs <[email protected]> wrote: > >> > >>> Hi guys, > >>> > >>> > >>> Currently, we have three ways to merge codes, we mostly use create a > >>> merge, squash merge. > >>> > >>> I suggest we use Squash Merge. > >>> > >>> As you work on a feature branch, you often create small, self-contained > >>> commits. These small commits help describe the process of building a > >>> feature but can clutter your Git history after the feature is finished. > >> As > >>> you finish features, you can combine these commits and ensure a cleaner > >>> merge history in your Git repository by using the squash and merge > >> strategy. > >>> > >>> And Create a Merge can cause our Git log to get messy and even lose > some > >>> of our git log (override). > >>> > >>> If we encounter a large PR, we should split it up instead of creating a > >>> large PR (which will result in a huge review effort, and if there are > too > >>> many issues, it will also result in a delayed merge of the PR, or even > >>> frequent code conflicts), and then use Create a merge to merge it. > >>> > >>> We can also see that most Apache projects will force the Squash Merge > >>> approach, so I hope the community can reach a consensus, and if you > have > >>> different opinions, feel free to discuss. > >>> > >>> > >>> Best wishes！ > >>> Calvin Kirs > >>> > >>> > >> > >
