If you are not maintaining releases and do not have many people working on the code-base, there is no reason to branch - especially not with a modern tool like hg or git.

In hg or git every commit is like a microbranch so you are already befitting in a small way from branch technology.

On small projects at home I never branch. At work we have to maintain a shitload of branches.

If you do a release then you should tag that commit (so you can find it easy) then if-and-when you need to fix a bug you can create a branch to support that release and release 1.0.1, 1.0.2, etc...

If the project is large and stable and you want to develop a big new feature, then you can create a 'development branch' to keep the experimental work on that branch until you deem it high enough quality to merge to the mainline.

If you have lots of developers simultaneously developing features then you can create 'feature branches' to keep each feature's development from interfering from one-another as they break things.

If you had to fix a bug in the 1.0 release then odds are it's still in the mainline code so you'd want to merge that bug fix back to the mainline.

If you make development branches then you want to periodically merge the mainline to the development branch first to work out compatibility issues on the development branch (made other people have merge big ass development branches in the mean-time.) Once you have a recent main->branch merge then you do a branch->main merge (this ensure the merge to main is easy).

When you're doing small feature branches you might just go-for-it and merge the feature back to the trunk (and if you have trouble, then abort the merge and merge the trunk to the feature branch).

I never use the command line for merge management; you really want to see what you are doing.

With hg, merging a branch is not really any different from merging two check-ins on the trunk.