When should I maintain or delete a branch?

Asked

Viewed 649 times

9

I’m working on a project and I’m starting to use a versioning control system, Git. When I create a branch to introduce a new functionality and after its completion, I merge with the master.

What is the best practice to be adopted regarding branchs created, delete or maintain them? In what types of situations should I choose to delete and not delete?

git versioning

2 answers

7


Each person has his own flow. In thesis after doing the merge you can delete it.

You may want to keep it for some time to facilitate maintenance if you encounter any problems specifically on something done on that branch, but it is no use to keep for long, after the code starts to be changed it will become easier to move from the master.

It may hold for historical reasons, but is rarely useful in fact.

  • Thanks @bigown! Taking advantage of the situation, in a project, the right thing is always to work on branchs instead of working directly on the master?

  • 3

    Yes, this is what it’s all about. Working at master is Ambi in the thick.

  • Got it, thanks a lot @bigown!

  • Regarding versioning, there are also contexts of knowledge management and production management of the project. Following this, the correct thing would be to have a policy of its own for each project.

  • 1

    @Duds Modern software development ideas (for many already a little old up) advocate continuous commit directly on the line master (also called main or trunk in other tools). For several years I have used this model successfully in many projects, and have seen it work in many others. Search for Agreement and non-continuous delivery and take a look at that answer: When branches are useful in Git?

3

In Git, branches are just pointers (references) to commits in a directed acyclic graph (DAG) of commits. This means deleting a branch only removes commit references, which can make some commits in DAG unreachable, therefore invisible. But all commits that were in a deleted branch will still be in the repository, at least until the unreachable commits are pruned ("pruned", for example using git gc).

Notice that git branch -d will refuse to delete a branch if you cannot guarantee that removing it will not make commits unreachable. If you really want to remove it, you need to use git branch -D to force the deletion of a branch that can make commits unreachable.

Also note that unreachable commits, if any, are only those between the last tip of a deleted branch and a commit that has been merged into another existing branch, or the point where the branch has emerged; whichever is last. For example in this situation:

----O----*----*----/M----*    <-- master <-- HEAD
     \            /
      \--.----.--/--x---y     <-- branch deletado

Only x and y commits will be unavailable after deleting the branch.

This text was extracted and translated from the Jakub Narębski in another question, where you can read more about it in English.

Browser other questions tagged git versioning

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