Git offers the features but your issue has more to do with team engineering decisions than with Git itself.

Each team can choose to work in a different way.

Continuous Integration )

According to the practice of Continuous Integration, the mechanics is a bit different from the traditional creation of branches for the development of features or great changes. It looks like this:

• All developers continually commit to the main development line (in Git, "master branch"). They fix bug fixes, minor changes and major changes. Make the most of creating development branches .

• At any given moment, a particular snapshot of the main line is chosen for release. Let's say this release was nominated version 2.0 .

• Developers have never stopped committing to the main line, and all subsequent commits to that chosen snapshot will eventually constitute version 3.0 .

• It turns out that a bug was found and its fix can not wait until version 3.0.

• Here is a maintenance branch for version 2.0 . It is made from that chosen shapshot. The bug fix is done on this branch and reproduced on the main line. If version 2.0 has already been released, a version 2.0.1 will be released with this bug fix. This branch will be used exclusively for maintenance of the stable version 2.0 , that is, only to implement bug fixes in this version. Great changes will be avoided just so that the version remains stable. The next releases of this bugfixed version will be 2.0.2 , 2.0.3 and so on. All fixes made here are replicated on the main line so that version 3.0 will not bring these bugs back.

• When version 3.0 is released (in the same way it was version 2.0 - from a snapshot of the main line), probably version 2.0 it will no longer receive maintenance and that maintenance branch tends to die. For maintenance of version 3.0 will be created a new branch, which will give rise to versions 3.0.1, 3.0.2 and so on, as it happened with version 2.0.

One way to represent this would be:

Conclusion:

Thebranchesthatwillbecreateddependontheengineeringdecisionsoftheteam.Usingcontinuousintegrationpractices,therewillusuallybeonlytwoactivebranches:

Themasterbranch,whichisthedevelopmentlineandalsothelinefromwhichreleasesaregenerated;

• Andthemaintenancebranchofthelastreleasedversion.

ReadmoreaboutotheraspectsandadvantagesofContinuousIntegrationinthisMartinFowlerarticle: link

Well here in our company we work with a model of its own, but started with the following logic: link . In general terms this depends on you, if you are going to work with pull request for example, it is suggested to work with 2 branchs develop and the master, and you will do a pull request to develop. And so it goes.

I believe that the above link helps you a lot, we start from this supposed presumption of 2 branch. Master and Developer.

I hope I have helped you.

Generally, you use a second (third, fourth, and so on) branch to develop something without interfering with the development of the parent branch, and so the second branch ends, a merge is performed to combine the two codes.

How many branches are really useful in Git?

It depends a lot on the amount of development branches are occurring in a given period. If you are developing 5 new features, the idea is to create 5 branches which start with a copy of the code master and as soon as they are ready, execute merge to match the codes and thus have the complete code.

Why this recommendation to start using branches from the beginning?

This depends more on the number of developers / teams involved in the design and designation of each. In general, a branch is created to develop a part without modifying the previous stable code itself.

Why use branches always?

Because every line of development is a branch . [/ joeRUIM]

Because each branch represents a "subject", a focus of project development. Even if you only have one development line, you have a branch , which is usually called master by GIT.

  

It turns out that in these two cases that I have identified which branches would be useful, the utility comes from the fact that there is a stable code that is not interesting to mess around with and want to have the freedom to work on something without spoiling this code. I can not see how that before we have a stable branching code can be useful.

We will always have a main branch that is where the stable code will be. When starting the project, we already have an initial branch, which is the master. Actually at this beginning there will still be no stable code because nothing has been implemented. Still, we can create a branch from the master, implement a new feature and after it is properly tested, make a merge to the master. In this case it will be the main branch.

At this point, it does not matter if some other feature being deployed is still not working properly. Because we only add in the main branch what is working. As the other features are being finalized, they will be added to the main branch.

In this way, we will always have stable code in a given branch from the beginning.