Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.

why would rebasing a feature branch change main?

the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.

The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G', that would be what @andrew@lemmy.stuart.fun meant.

Just remember to not combine it with force push or you're in for some chaos (rewriting history team members have already fetched is a big no-no).

I wouldn't recommend it. The Git documentation itself doesn't recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.

What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.

Well, and what is the "proper history"? If your answer is "chronological", then why so?
For the rare times that it matters when exactly a commit was created, they've got a timestamp. But otherwise, the "proper history" is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.

When you're working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you've done your commits really quickly or over the course of weeks, that really shouldn't matter.

What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won't be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.

The commits aren't duplicated, but applied to the main branch. Since git has commit ids, they won't be re-rebased either.

Kind of. Both merge and rebase result in the branches "synced up" but they do it in different ways.

Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).

Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.

It's really hard to create an analogy for this.

It inserts the master changes before the task branch ones.