+1, although we use "git fetch origin && git rebase -p origin/branchname" to avoid the nasty behaviour of 'git pull --rebase' where it rewrite all commits of a merged branch on the current branch instead of just redoing the merge commit. Looking back at a 18 month old part of the history and seeing (feature branch x was merged here) is far more helpful than finding a bunch of duplicate commits IMHO

yes, using rebase to avoid spurious merge commits is also a useful practice, but I was referring to "git rebase -i" (interactive), which can be used to remove commits, splitting/squashing commits, editing commits etc.

Sometimes you just don't have time to do clean commits (by committing only relevant changes with "git add -p"), or you fix something later which was logically part of a previous commit.

Being able to curate the commit history or your local clone, besides pure aesthetics, allows you to present a given contribution to other team members so that they can better understand what you wanted to do and perhaps review the commits.