[speedupmate]

this is a narrow view based on someones versioning habits , the point of rebase can also be a solid linear history that allows multiple teams to fork and pull request features between forks. If developer chooses to play merging inside his own repo, fine but as soon as you have large teams working on their own you will end up in merging hell between developers and teams.

say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there's team c, d , e .... n giving non conflicting input to your codebase.

the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.

in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can't merge any more cause of other developers conflicts.

Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.