What's your mental model for a Git commit, and a Git branch?

Once I properly learned those two concepts, understanding rebases became a lot easier.

I'll try to explain it to the best of my abilities.

• Think of a commit being a patch - a description of how to take a particular file from one state to another
• A branch is a list of patches to be applied in order, from the point where the branch was created until the last commit on the branch

When you rebase a particular branch, what you're essentially doing is taking all of the commits that are currently on your branch, checking out the other branch, and then applying each of the patches in order on that new branch.

A rebase can be cleanly applied if the premise for each commit has not changed when applied, but if the premise has changed, you get a conflict to be resolved before being able to continue the rebase.

I mentally model a rebase a bit as a fast version of how it would look like to build the branch I was on, but on top of the branch I'm rebasing on.

Same. And even if you were to fuck up, have people never heard of the reflog...?

Every job I've worked at it's been the expectation to regularly rebase your feature branch on main, to squash your commits (and then force push, obv), and for most projects to do rebase-merges of PRs rather than creating merge commits. Even the, uh, less gifted developers never had an issue with this.

I think people just hear the meme about git being hard somewhere and then use that as an excuse to never learn.

Yeah, I hate it when my repo is a chain of merge commits. I want to see actual changes to the code, not branch management history.

Yeah, our whole workflow is based on rebasing our feature branches on develop. Makes for a clean git log. :)

Don't be afraid of git reset --hard if you rebased with the button on GitHub/gitlab, though. :D

I'm guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.

I agree that these changes should be made in separate commits, for the benefit of the reviewer.

There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.