A rebase creates new commits from old commits semi-automatically. Git then has no permanent record of the old commits, and even if you want to get back to them right away it requires some delicate git surgery.
This is why you can't generally share work using a rebase workflow.
It is not a big deal in practice in most every case, but in a version control system it is a little bit odd that rolling back such a fundamental operation isn't a first class feature.
> even if you want to get back to them right away it requires some delicate git surgery.
The reflog tracks rebase commit history. No surgery required.
>This is why you can't generally share work using a rebase workflow.
Rebase of public facing commits is not discouraged due to data loss. It is discouraged due to the possibility of someone creating change sets off the published work, and then the update re-writing the history to change the merge-base, requiring a re-merge of their changes.
They might be exaggerating a bit the amount of work to recover it immediately, but resetting a tag to a commit in the reflog might be considered at least a minor git surgery. And that’s assuming no public pushes have been made. Then all bets are off and it’s surgery’s time.
> and even if you want to get back to them right away it requires some delicate git surgery.
`git reflog` to get the old commit ID, and then `git reset --hard <commit>`. Seems more like "basic everyday git operations" than "some delicate git surgery".
Many past confused teammates of mine I've dropped in to help would disagree. reflog and reset, for better or worse, require what seems to be above-average comfort with git.
I don't think you can call yourself "using git" if you're not comfortable with such simple concepts. Pointing a branch to a specified ref is one of the most basic operations you can reason about when using git!
I'm perfectly aware that many people don't think when using git at all and instead merely copy'n'paste memorized commands hoping that they'll do what they want to accomplish, but this is something you should move past when you want to stop calling yourself a "junior developer". This is one of the most important and helpful tools in your field of work, you can either take advantage of it or suffer.
This is why you can't generally share work using a rebase workflow.
It is not a big deal in practice in most every case, but in a version control system it is a little bit odd that rolling back such a fundamental operation isn't a first class feature.