If you like keeping a cleaner history you can rebase the branch onto master prior to doing the merge. It depends on how vital the independent branch history is.
If you don't do a rebase it often makes sense to merge master into the branch first. This allows you to resolve and test conflicts, get a stable state, then have a flawless merge to master. Logically it sounds about the same, but in some pipelines it works better.
I always prefer rebasing the feature branch first, then merging. It allows for a simpler linear repo history (this is if I'm the only one working on it).
I also like to clean it up with some commit squashing with: git rebase -i HEAD~n.
git rebase -i HEAD~n
Couldn't agree with you more!
In the future, there will be another article regarding rebasing that will cover its positive and negative points compared to merging.
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.