Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase.
Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.
Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.
I've used almost every source control system known to humans the past several decades and git for over a decade.
I've heard the git rebase preachers. I tried to get onboard with rebase.
All who read, avoid rebase at all costs at all times, always.
Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.
Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).
Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.)
Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.
Your preaching is contentless.