I'm relatively new to Git. I've been told that the recommended behaviour is to create a different branch for every new task (optionally deleting the branch after finishing). This is also implied in this post that I found.
However, considering the branch names can't include whitespace I was wonder if that is correct, and if so, what benefit is there from it (as opposed to "recycling" a couple of fixed-named branches, such as "task1", "task2" for example).
Never call your tasks "task1" and re-use it. You might as well call it "development" and only work on the single branch... which I'm sure you can see defeats the point of branching.
Try using underscores, and call each branch something relevant to the task at hand - if you have a bug/task tracker, call each branch the bug number or at least call it with enough information that you can see what you were doing on that branch months later.
You can use hyphen or minus to replace whitespace or you can you camelCase.
The main purpose of the name is to help you avoid mistakes. Avoid strict rules which go one way or the other. Eventually, you'll find yourself in a situation where you work on more than a single branch at the same time. At that point, you really need a simple naming scheme which makes sense for your brain.
A common practice is to use JIRA or bugzilla IDs for branch names because then you can "link" complex information. The drawback is that BUG-37145 doesn't say much (except that you have too many features and/or bugs).
Github can also help since you can give the pull request a title which explains in 4-5 words what it contains.
There are few different workflows with git:
I suggest to look through this article.
About branch names, I would recommend naming them with feature, implemented in them, obviously. For example, if you're planning to implement 'Actor system clustering', call your branch 'actor-system-clustering', or 'actor-clustering' if you prefer shorter names.
Try not to use / symbols, since some GUI apps (e.g. SourceTree) are treating it as grouping prefix, and will make a folder with that prefix.
This is caused by GitFlow naming policy.
If you actually want to group some branches, give them a prefix, like clustering/actor-clustering.
In my opinion, the most interesting is GitFlow workflow. It gives you a formalised workflow for releases, hot-fixes, features etc.
The advantage of having a branch for each task is, that you can make changes (let's say a hotfix) to your master branch (or indeed another task branch) while you are working on your task.
If necessary you can merge the hotfix into your task branch.
Later you can either merge your task branch into master or rebase it to make your history look a little cleaner. This allows you to work on a task for some time (or multiple tasks simultaneously), but make every task only show up as one single commit in the master branch.
If you are working alone on a small project, branching might seem unnecessary. It is a good idea to get used to it though, since you will need it, if you ever work on a bigger project with multiple people.
Answer to (from comments):
"I understand the benefit of using different branches when developing different tasks simultaneously, but I still don't understand what benefit I get from the branches afterwards. I mean, I commit with a message that describes the change, and when done I push all my changes from the branch to the remote repository, but afterwards what benefit is there to the branch?"
After you are done with your task, there is no real benefit of the branch anymore. That's why you can delete it (as you mentioned yourself in your question). Having the branch is only useful as long as you are actually working on the task.
