Mercurail (and more) - how do you work with local branches / repositories or how to avoid unnecessary branches in the central repository?

Question

CVS

We work with Mercurial. There are several small projects. Each one has multiple people working on it. There is a central repository and the main branches in it: release, pre-release, test and current - everything is about the same as everyone else.
But the work is intensive and you need to exchange code often. Each developer makes local commits for himself (several per day). Plus, for code exchange, commits are made to the current branch (once or twice a day - as developers have any stable code that other participants should know about). Accordingly, the current branch can easily not be built and almost always contains errors, and stabilization is carried out in pre-releases - but this is beside the point.
This is a lyric so that you can roughly understand what it is about.
The question is that there are a lot of commits, but in reality there is only one development stream, and I don’t want to pollute the central repository with unnecessary commits and especially branches. Even branches from the current branch are rarely needed. The question is - how do you solve it yourself?
Should I dump everything into the central repository? There will be hell and horror. Especially in the current branch with which the main work is being done. And in pre-releases, it's not much better either, since the stabilization of the code is going on there and there are also quite a few commits from different developers.
Make clones of repositories, work in them, then copy the necessary revisions to a copy of the central repository to the desired common branch and push it? There will be no extra branches, but it is not convenient and information about the connection of local commits (branches) with the main branches is lost. In most manuals, this is how it is recommended to do it, but in practice the method is rather crooked. And, as I said, the most important thing is that the developer does not see which of his local branches / commits, how they correlate with the general branches in the central repository. This may work if the developer makes relatively rare commits - he took a feature, implemented it, committed it, but the specifics are such that frequent commits and exchange of current code are needed.
Now it seems to have agreed that only common main branches are stored in the central repository (release, pre-release, current development, plus, if necessary, bug fixes, features, etc.). And each developer has one repository in which he starts his own local branches and conducts current work in them. All changes from the central repository are regularly pulled into this repository, and if necessary, the local branches are merged with the general ones ... Only the general branches are pushed into the central repository. Those who wish can create local repositories for the group and make a two-level system. When you need to commit to a common branch, then go to this branch (update to its head). Then we do a revert to the required revision of the local branch (we get the state of the local branch in the working folder, but without changing the current revision - we remain in the head of the general branch). We make a commit (to the general branch). We push only common branches. As a result, local branches do not get into the central repository. To indicate the connection between local and general branches, at some significant stages (when the developer considers it necessary - at least every time), the developer, after committing to the general branch, merges it into the local branch. As a result, on the graph in his repository, he sees a connection between his local branches and the general ones, but at the same time, local branches do not fall into the central repository.
In general, it works. But somehow, too, strange and crooked.
Maybe someone has some useful practice ideas on this topic? In general, it is interesting to hear about the hierarchy and organization of repositories in the light of active development and pollution of the central repository with branches.

Answer 1

nvie.com/posts/a-successful-git-branching-model/

Answer 2

Feature brunches.