How important is the branch in versioning?

Asked

Viewed 1,059 times

2

  • Because creating branches is important in software versioning, rather than just using "master" (in large, medium, small or even personal applications)?
  • What advantages do I have in using them?
  • A versioning without them can entail some "evil"?
  • Could a lot of branches become a problem? If so, how much would that be?
git branch

  • Versioning is usually done in tags, which would be an "immutable state in history". Which versioning system do you use?

  • @Jeffersonquesado GIT, in case would version control? Help me kkkk .-.

2 answers

7


By itself, branches are not versioning tools. I’ll come back to that 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 workflow gitflow.

In addition to separate feature development, it also allows you to have a stable branch (master) and an unstable (develop). What do I mean that branches are stable and unstable? Well, any correction will only make the system more stable (in theory), so corrections 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.

On the other hand, a functionality or system rearquiteture can bring great instabilities in the system. Applying this code change has the highest risk of introducing bugs. So if a production code undergoes this kind of change, it will no longer be ready to go into production.

See more on the link I posted on the gitflow.

Branches and versions

In several projects you will find that the repository includes branches such 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 provide stability for each version. This depends on the life cycle of each release.

Disregarding patches with fixes that need to be delivered in hot, I have only worked on projects whose life cycle is weeks, and the new version totally supplants the old and is no longer offered maintenance the previous version. So I don’t have much experience in this kind of development with long life cycles 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 without forcing the client to update the version he 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 see?

Basically because branches are changeable, they were made to be changed. Versions, no. Version v4.5.17 you want it to always be the same version v4.5.17, No? If you put as branch v4.5.17, someone can commit and change the version code, without changing the version identifier string.

In git, you get some of that immutability by using tags. In thesis, tags are points in the code history. They are not changing heads, they can evolve. They are just "pointers" to a certain point in the code.

Answering specific points

Because creating branches is important in software versioning, rather than just using "master" (in large, medium, small or even personal applications)?

Separate branches help in the stability of the software. They also don’t carry much weight of use, concept, time or tools.

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

What advantages do I have in using them?

Stability and isolation.

A versioning without them can entail some "evil"?

If you’re too disciplined, you wouldn’t need to development. But using branches in your workflow helps against eventual human failures.

Could a lot of branches become a problem? If so, how much would that be?

Yes, they can generate negative effects. For example, client software can take a long time to display branches. Or make it difficult to find a specific branch. I’ve suffered it with a setup on Jenkins, but they managed to get around where I work by changing from one select box simple for something more interactive with filters.

Another problem you can cause is with co-workers. One fine day an old employee (who worked before git and if he depended on it would continue with CVS) complained that there were more than 10 branches in the repository...

1

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

First: When a person gives a COMMIT and a PUSH, she can send to BRANCH that she’s using, that way, if she breaks the code that she did something, it won’t stop the code of everyone who’s using the MASTER and also not everyone will need to take the previous version because it was broken. Basically that’s it, people can have it like a MASTER for every feature you create, so you don’t commit directly to ORIGIN/MASTERif it is a risk feature that can break the entire program.

2º: A versioning without them would not cause any harm, would only increase the security of the code COMMITSbroken.

3rd: Having many can lead to a problem of MERGE, if there are many BRANCH'S long, which are not in the MASTER, when it comes to moving there, it can cause several conflicts, so it’s best to make the functionality and give the COMMITand the PUSH(Unbroken codes) not to accumulate too much and give too many conflicts at the time of the MERGE.

Browser other questions tagged git branch

You are not signed in. Login or sign up in order to post.