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.
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.
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
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.