By itself, branches are not versioning tools. I'll come back to this later.

Within a development process, you can use branches to isolate development. This allows you to change a code base without necessarily affecting the entire stable part of the code. I particularly use the gitflow workflow.

In addition to developing features separately, it also allows you to have a stable branch ( master ) and an unstable branch ( develop ). What do I mean by stable and unstable branches? Well, any fix will only make the system more stable (in theory), so patches in that direction would not increase software instability. Thus, a production code after undergoing a correction, the new code will also be ready to go to production.

Already a feature or system rearranging can bring great instabilities in the system. Applying this code change has the greatest risk of introducing bugs. So if a production code suffers from this type of change, it will no longer be ready to go to production.

See more in the link I posted on gitflow .

Branches and versions

In several projects you will find that the repository includes branches as v4.5-stable , v4.6-stable and v5-unstable .

But what is the function of these branches? Well, they have no versioning function, but they provide stability for each version. This depends on the life cycle of each release.

Disregarding patches with fixes that need to be delivered on hot, I have only worked on projects whose lifecycle is weeks, and the new version completely overrides the old one and is no longer serviced the previous version. So I do not have much experience in this kind of development with long lifecycles with overlapping stable versions, but I can speculate.

This separation of maintenance branches allows the correction to be made where the problem was detected and then propagated to the other versions "more in the future", all this without forcing the client to update the version that is using. This also prevents new features (which bring instability) from being inserted into older versions but still supporting them.

Why not use branches to version?

Basically because branches are mutable, they are meant to be altered. Versions, no. The version v4.5.17 you want to always equal the v4.5.17 version, no? If you put it as a v4.5.17 branch, someone can commit and change the version code without changing the version identifier string.

In git, you get part of this immutability using tags. In theory, tags are points in the historical code. They are not changeable heads that can evolve. They are just "pointers" to a certain point in the code.

Responding to specific points

  

Why create branches are important in software versioning, rather than using only the master (in large, medium, small or even personal applications)?

Separate branching helps in software stability. They also do not carry great weight of use, concept, time or tools.

Anyway, if you work with git hosted on some server, you already are working with branches. At the very least, master local and remote.

  

What advantages do I have in using them?

Stability and insulation.

  

A versioning without them can lead to some "evil"?

If you are very disciplined, you would not need to development . But using branches in your workflow helps against eventual human failures.

  

Having many branches could be a problem? If so, how much would this be?

They can have negative effects, yes. For example, a client software may take a long time to display the branches. Or make it difficult to find a specific branch. I have experienced this with a configuration in Jenkins, but have been able to work around where I work by switching from a simple%% to something more interactive with filters.

Another problem you may encounter is with coworkers. One day an old employee (who worked before git and if it depended on him would continue with CVS) complained that there were more than 10 branches in the repository ...

The BRANCH's of GIT help you organize your versioning better, see:

1st: When a person gives a COMMIT and a PUSH , he can send to the BRANCH that he is using, so if he codes the code he broke something, he will not stop the code of everyone who is using MASTER and also not everyone will need to get the previous version because it was broken. Basically that's it, people can have it as a MASTER for every feature they create, thus not committing directly to ORIGIN/MASTER if it is a risk feature that can break the whole program.

2º: A versioning without them would not cause any harm, only increase would give more security to the code as the% broken%.

3rd: Having many can cope with a problem of COMMITS , if there are many MERGE long, which are not in BRANCH'S , at the time of going there, it can lead to several conflicts, so the best is make the functionality and give MASTER and COMMIT (Codes not broken) to not accumulate much and give many conflicts at the time of PUSH .