-Re: Avoiding trivial merges: using rebase properly
Anatoli Fomenko 2013-05-03, 21:33
Confirmed: extremely furious.
From: Konstantin Boudnik <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, May 3, 2013 2:00 PM
Subject: Re: Avoiding trivial merges: using rebase properly
On Fri, May 03, 2013 at 01:56PM, Sean Mackrory wrote:
> +1 - I'm a big fan of `git pull --rebase` for just fetching remote changes
> and moving my local commits ahead of them.
Believe me - me too. You might ask Anatoli how furious I was at my previous company
haunting developers doing the junk merges all the time ;)
> On Fri, May 3, 2013 at 1:41 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> > Guys,
> > some might have noticed in the master's branch history this commit:
> > * commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
> > |\ Merge: 10fb276 38eafa0
> > | | Author: Konstantin Boudnik <[EMAIL PROTECTED]>
> > | | Date: Thu May 2 18:45:47 2013 -0700
> > | |
> > | | Merge remote-tracking branch 'public/master' into trunk
> > It was caused by me paying little attention while doing
> > % git fetch
> > % git merge
> > % git push
> > on top of a commit that was ready to get pushed.
> > Generally speaking "merge commits" are only good if you want to indicate
> > that
> > a feature branch's work has been completed and you are bringing it to the
> > main line (whatever it is).
> > If you are working on a branch and someone has committed something
> > irrelevant
> > to your immediate work consider avoiding merges: use git rebase instead. It
> > helps to keep the history clean and avoid clattering and confusions
> > from coming from these clearly meaningless and "parasitic" merge-commits.
> > Also, be considerate and don't rebase branches that are shared among
> > others -
> > rebases rewrite history and it might be real messy.
> > So far we were very good about it, and I want to make myself an example of
> > an
> > 'anti-pattern' in action.
> > --
> > Take care,
> > Cos