I hope this doesn't confuse you, but I do feel compelled to add.. In both examples you mentioned, you merge onto master. You would break your teammates repos if

I hope this doesn't confuse you, but I do feel compelled to add.. In both examples you mentioned, you merge onto master. You would break your teammates repos if you rebased a topic/feature branch onto master. You ARE right, that before such a merge, it's a common practice to squash your commits on the feature branch to clean it up and then merge a single commit over to master. (To squash you use git rebase -i but you're squashing not rebasing). If you were to actually rebase this branch into Master instead of merging it, it would change the commit hashes for commits already in master, leading to awful merge conflicts the next time a teammate tried to pull down your changes. I wanted to mention this to hopefully connect the last few dots. The reason most articles don't talk about "both" these ways, is because really there is only one way, with a few different choices. Maintaining a branch: If you need to bring changes from Master into a long-running branch, you can either do so with merge or rebase. Rebase is cleaner IMO. Preparing to integrate your work into master: You can either squash some or all of your commits, or you can keep the history as-is. Integrating into master: You always do this with a merge.