+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: > 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 > >
