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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.