So this workflow is needed if you are working on a public, i.e. multiple devs collaborating on a single branch, scenario. But it is much better to avoid this as much as possible. Usually it is a 'scoping' issue, where you create a branch that is too broad. For example 'api-for-frontend', which is a massive thing.

But let us say you absolutely have to get multiple devs on same branch, then this workflow is totally fine. There is nothing wrong in it.

In our org we prefer to delete the branch after merge. In a way it says 'this branch is closed'. This is to encourage devs to define smaller and more logically scoped branches.

I want to take this opportunity to say that, branch is just a label on a commit, with some additional functions. Once you start focus on commits and lineage of the commits, then branches become some what irrelevant.

Is it ok to continue on a branch if you also merge back main into it?

On some repositories, sure.

But better maintained repositories don't allow merge commits (because merge commits suck), and so will have squashed (or rebased) on merge.

(If squashed) The squash will have changed commit IDs, so a long running branch rebased won't benefit from a clean shared commit history.

So it can work, but "you're gonna have a bad time."

In general, git works best if branches are thrown away as soon and as often as possible.

(Edit: Good clarification in response below, added here for consistency and accuracy.)