What you do is create a third branch off master, cherry pick the commits from the feature branch, and merge in the third branch. So much easier.
That is absolutely not what rebasing does. Rebasing rewrites the commit history, cherry picking commits then doing a normal merge does not rewrite any history.
I’m sorry but that’s incorrect. “Rewriting the commit history” is not possible in git, since commits are immutable. What rebase actually does is reapply each commit between upstream and head on top of upstream, and then reset the current branch to the last commit applied (This is by default, assuming no interactive rebase and other advanced uses). But don’t take my word for it, just read the manual. https://git-scm.com/docs/git-rebase
If your cherry-pick doesn’t run into conflicts why would your merge? You don’t need to merge to master until you’re done but you should merge from master to your feature branch regularly to keep it updated.
