Note that Benjamin W.'s answer is slightly better than what you asked for, because it also handles the case where you have any new commits on topic that aren't on main yet, in additional to your pending changes. The merge you were doing should always be fast-forward, and if you didn't have any new commits yet the rebase would be equivalent. In the case where you do have at least one new commit on topic, and also some pending changes, then merge vs rebase would differ, but I'd lean towards rebase on a personal topic branch in this case anyway.
Also note that when you rebase directly onto origin/main you don't even need a local copy of main, and this is normally true in general. Even your question could have omitted the git checkout main step since you could have performed the next command, git merge origin/main directly into topic with fast-forward. Due to this, I actually recommend deleting your local copy of main since it is pretty much always out of date. If for some reason you ever need it again you can just check it out and it will up to date at that moment.
If at this point you wish to start a new branch with a different name (instead of topic), then you could issue the following commands:
git switch -c my-new-branch # create a new branch
git branch -d topic # delete the previous topic branch
# or perhaps just rename your current branch to the new name
git branch -m my-new-branch
git branch --unset-upstream # stop tracking the previous remote branch name
Note that in your question, had you not had any new commits and landed on main with pending changes, your commands to create a new branch would be the same as above.
I would like to comment on the --autostash option to rebase. It exists exactly for your workflow, but the Git documentation warns (emphasis mine):
Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
This is something that is generally true with stashing, particularly when applying it later to a different commit than it was stashed from. Having experienced pain from this before, (and seeing others bit by it as well), over time I've come to the conclusion that it's far easier to work with commits than stashes, and much safer as well. For this reason I rarely stash anymore, and I almost exclusively use "wip" commits. If you wish to try this, the tweak to your workflow would be:
- Commit your work in progress with a message like "wip: some message here".
Now to update your branch anytime you wish:
git pull --rebase origin main # (Or alternatively, git fetch followed by git rebase origin/main)
And after the rebase:
- Either continue working and amend the wip commit when you're ready to commit, or after the rebase:
git reset HEAD~1 which will put your changes back as pending.
The biggest advantage of this compared to stashing and popping, is you have a commit you can easily go back to if something goes awry either now, or later. In general, I would also recommend committing early and often with multiple wip commits, and just squashing it all later down to a few perfect commits when you're done.
