What does it mean to close a branch?

Question

And what are the advantages of closing a branch? And what happens if I don't do that.

I work in a team and we use Git in Bitbucket. Some colleagues always say that it is very important to close the branch. But why?

Answer 1

In Git, there is no defined concept of closing a branch, and therefore it would be akin to deleting a branch. Perhaps the terminology came from Mercurial , where you cannot delete a branch, but instead you can only close (hide) it.

That being said, if your question now becomes:

Why is it very important to delete branches?

I might argue that important isn't the right word, since you don't have to delete branches if you don't want to, kind of like how you don't have to empty your email spam or trash folders either if you don't want to. But you can delete your branches and perhaps you should delete them for sanity purposes, as long as they are no longer needed.

So when is a branch "no longer needed"? Even this is a source of debate. But I think both sides of that debate would agree that:

1. Once a branch is fully merged into a long-lived shared branch, it can be safely deleted. If you wanted to re-create the branch exactly like how it was before it was deleted, you can do this anytime in the future. (Assuming the branch name hasn't been re-used by something else.) One exception to this would be when you merge a long-lived shared branch into another (eg master into develop in Git Flow): that doesn't mean you should go and delete master just because it's fully merged, but, in theory, you could , and then recreate it later when you need it again (but why bother if you absolutely will need it again!)
2. Even if a branch isn't fully merged, if you know you no longer need it for whatever reason (perhaps a throwaway branch for testing or old code that you don't care about it), it can be safely deleted.

I think the point of contention around deleting branches typically is around whether or not you should delete release branches after they are fully merged. (I doubt many people would argue you should keep feature/topic branches around forever.) Some say keep the release branches forever so you know what's in any particular release. Others say just Tag the commit that the release was on and then you don't need all the extra branches in your face when you list all the remotes. But unless you have a lot of remote branches, I doesn't really matter much one way or the other, at least not from a performance or utility stand point. If you are keeping branches around forever, I'd recommend at least organizing them in some sort of pseudo folder structure, such as release/* to help filter them out when you don't want to see them.

As for deleting your local branches after the remote counterpart is deleted, I do recommend keeping up with this. My last laptop had hundreds of local branches on it, and when I got a new laptop I made a copy of that repo because I still to this day have no idea which of those branches I might need, but I'm fairly certain the number is less than 10, likely even just 5 branches. But I don't want to take the time to go through them all. For that reason, now in my main working repo, I'm pretty religious about deleting all the branches I no longer need; I try to clean them up at least once a day.