Very good explanatory article, though perhaps it may be worth to add (perhaps in future post) about using squash. As sometimes, when merging commits from feature-branch, we see several auxiliary changes like "code cleanup to make lint/stylecheck happy" - and we don't want these in the master history either as is, or rebased.
(on the other hand if feature consists of logically separated steps, it may be better to leave them separate without squashing - though perhaps this means we needed separate merges properly)
Thanks for the feedback. I'm preparing a next part which focuses on the features of interactive rebase. Squash will be part of that.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.