-Re: Avoiding trivial merges: using rebase properly
Sean Mackrory 2013-05-03, 20:56
+1 - I'm a big fan of `git pull --rebase` for just fetching remote changes
and moving my local commits ahead of them.
On Fri, May 3, 2013 at 1:41 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> 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
> 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
> 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
> 'anti-pattern' in action.
> Take care,