You can use squash independent from merge. It is done via simple interactive rebase and can be used at any time at one's convenience. However, it is important to remember not to squash someone's else commits as it changes the SHAs of the object.
I'd be happy to do a session for anyone who needs a bit of education around these technologies, but I am fairly sure there's plenty of materials like that on the net. Cos On Tue, Jul 28, 2015 at 08:34PM, Pavel Tupitsyn wrote: > As said above, squash should be used when merging to master (git merge > branchName --squash "Message"; there are checkboxes in Idea, too). > This way there is a single commit with a meaningful message in master, and > it does not matter what happened in the personal branch. > > I think this is the simplest workflow. > > Thanks, > > On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <[email protected]> wrote: > > > On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote: > > > > I hope so, it'd be horrible to do that on master! > > > > > > Exactly! > > > But I do not see much sense in enforcing any kind of policy in personal > > > branches. Sometimes rebase may be better, sometimes I may want to use > > merge > > > so I see when and which changes came from master branch, etc. > > > Only the implementer cares about the look of history in his branch, so it > > > is up to him. > > > > You can do with your personal branch whatever you pleased with, of course. > > However, if you make 112 intermediate commits while working on something, > > there's no need to unleash it on everyone; also it is of little interest to > > anyone to see how many times you merged from the master to your local > > branch. > > > > In this respect, hygiene of the personal branches are of little concern to > > anyone, until one starts contaminating the shared history. Does it make > > sense? > > > > > > Also what will happen if someone will do merge but other rebase? > > > > > > Nothing will happen, we are talking about personal branches, they end up > > > being removed. And resulting work is squashed into a patch. > > > > Actually, I didn't say anything on how the content of the change is > > delivered > > to the master. If you want to do it with patches - sure; but I think it'd > > be > > better to do keep using git facilities for that and simply merge dev -> > > master > > when you're ready. > > > > Cos > > > > > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov < > > [email protected]> > > > wrote: > > > > > > > One more. Could I use rebase in my branch if I already use merge on > > this > > > > branch before? > > > > > > > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > I can start user rebase at any moment? Or I should wait for day X ? > > > > > Or we will start vote? > > > > > > > > > > Also what will happen if someone will do merge but other rebase? > > > > > > > > > > -- > > > > > Alexey Kuznetsov > > > > > GridGain Systems > > > > > www.gridgain.com > > > > > > > > > > > > > > > > > > > > > -- > > > > Alexey Kuznetsov > > > > GridGain Systems > > > > www.gridgain.com > > > > > > > > > > > > > > > > -- > > > -- > > > Pavel Tupitsyn > > > GridGain Systems, Inc. > > > www.gridgain.com > > > > > > -- > -- > Pavel Tupitsyn > GridGain Systems, Inc. > www.gridgain.com
