When are branches useful in Git?

Asked

Viewed 551 times

19

I’m studying Git and from what I’ve seen about branches I’ve basically identified two major situations where branches are useful:

  1. When we have a stable version of the code in the master branch and want to add a new functionality, we then create a branch to develop the functionality without having the danger of breaking what we already have in the master branch.

  2. When we have a stable version of the code in the master branch and need to fix any bugs found, we create a branch to work on this bug and do not run the risk of damaging the stable code

These two uses seem to be quite common, because I have also seen in many articles and videos they are cited. The point is, I’ve also heard that more experienced Git users recommend doing a lot of branch work. Once I saw even an answer in Stack Overflow in English that said the ideal is to start branches earlier and always use branches.

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

That way, when branches are really useful in Git and why this recommendation to start using branches from scratch and always use?

git

  • Or more than one stable code version, for example a new version with root changes in the code structure. I read for some time about gitflow, I think it’s good to give a read.

4 answers

15

Git offers the resources but its 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 (Continuous Integration)

According to the practice of Continuous Integration, the mechanics is somewhat different from the traditional creation of branches for the development of Features or major changes. She gets like this:

  • All developers commit continuously in the main line of development (in Git, "master branch"). Commits bug fixes, minor changes and major changes. Maximum avoidance of developing branches.

  • At some point, a certain snapshot of the main line is chosen for release. Let’s say that this release has been named version 2.0.

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

  • It turns out that a bug has been found and its fix cannot wait until version 3.0.

  • Here is made a maintenance branch of version 2.0. It is done from that chosen shapshot. The bug fix is done on this branch and played on the main line. If the version 2.0 has already been released, will be released a version 2.0.1 with the fix of this bug. This branch will only serve for maintenance of stable version 2.0, that is, only to implement bug fixes in this release. Major changes will be avoided precisely so that the version remains stable. The next releases of this version, with bug fixes, will be 2.0.2, 2.0.3 and so on. All corrections made here are replicated on the main line so that the version 3.0 won’t bring these bugs back.

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

A way to represent that would be:

inserir a descrição da imagem aqui

Completion:

The branches that will be created depend on the team’s engineering decisions. Using continuous integration practices, there will usually be only two active branches:

  • The master branch, which is the line of development and also the line from which releases are generated;

  • And the maintenance branch of the latest release.

Read more about other aspects and advantages of Continuous Integration in this article by Martin Fowler: http://martinfowler.com/articles/continuousIntegration.html

  • Branchs serve tbm to avoid file conflict if two users modify the same file on the same line?

  • @No, no, no, no, no. If the two users are using the same branch, one of them will have to resolve the conflict at the time they commit/push; and if each one is using a distinct branch, this conflict will have to be resolved anyway at the time the branches merge. So, no, branch doesn’t serve to avoid conflict. It is just the opposite that occurs: the longer the development occurs in different branches, the more conflicts there will be to resolve at merge time.

6

Good here in our company we work with our own model, but that started from the following logic: http://nvie.com/posts/a-successful-git-branching-model/ . In general terms this depends on you, if you will work with pull request for example, it is suggested to work with 2 branchs develop and a master, and you will do a pull request to develop. And so on and so on.

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

I hope I’ve helped you.

  • Similar in the company where I work, but I see that working with more branches when there are several clients, different versions and not being a Saas, there may be some bug in some client who did not buy the latest version and you need to fix it. Depends on the case.

5

Usually you use a second (third, fourth and so on) branch to develop something without interfering with the development of branch main, and so the development of the second branch ends, um merge is carried out 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 beginning with a copy of the code master and as soon as they’re ready, run merge to combine the codes and thus have the complete code.

Why this recommendation to start using branches from the start?

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

Why use branches at all times?

Because every line of development is one branch. [/piadaRUIM]

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

0

It turns out that in these two cases that I identified which branches would be useful, the utility comes from the fact that there is a stable code that is not interesting to move around and we want to have the freedom to work on something without screwing up that code. I can’t see how before we have a stable branching code it might 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 stable code, because nothing has been implemented. Still, we can create a branch from master, implement a new Feature and after it is properly tested, merge into master. In which case it will be the main branch.

At this point, there is no problem if some other Feature that is being implemented is still not working properly. Because we only add to the main branch what’s working. As the other Features are finished, they will be added to the main branch.

That way, we’ll always have stable code in a given branch from the start.

Browser other questions tagged git

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