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 finishing it, I make a merge with master .
What is the best practice to adopt with regard to branchs created, delete or maintain? In what types of situations should I choose to delete and not delete?
Each person has a flow of his own. In thesis after doing merge , you can delete it.
You may want to keep it for some time to make it easier to maintain if you encounter any problems specifically in something done on that branch . But it's no use holding on for long, after the code starts to be changed it's getting easier to move from the master .
You can keep for historical reasons, but it is rarely useful in fact.
In Git, branches are just pointers (references) to commits in a directed acyclic graph (DAG) of commits. This means that deleting a branch removes only referrals to commits, which may make some DAG commits unreachable, therefore, invisible. But all the commits that were in a deleted branch will still be in the repository, at least until unreachable commits are pruned (eg using git gc).
Note that git branch -d will refuse deleting a branch if you can not guarantee that removing it will not leave 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 leave commits unreachable.
Note also that unreachable commits, if any, are just those between the last end of a deleted branch and a commit that has been merged into another existing branch, or the point where the branch came up; whichever is the last. For example in this situation:
----O----*----*----/M----* <-- master <-- HEAD
\ /
\--.----.--/--x---y <-- branch deletado
Only the 'x' and 'y' commits will be unavailable after deleting the branch.
This text has been extracted and translated from the answer of the Jakub Narębski in another question , where you can read more about it at English.