Do you delete Git branches?

Hey,

good question!

I've been working on big repo for years now.
This is a strategy that works. I'm not saying it's the best one but it works and scale.

How to keep repository clean?

Everybody fork the main repo and no commit / branch creation is allowed on the main repo.
Dev create a branch on his own repo, then he create a pull request on main repo.

Delete local branches and keep the remotes?

In GitLab/ GitHub, you have an option to delete the branch when PR is merged.
Then from time to time you can run git fetch -p to clean up your local repo. On you repository, there's usually a button to remove merged branches. You can also manually remove old branches (i.e. latest commit > 60 days).

Delete remote branches and lose the Jira link on historical tickets?

For this, I couldn't agree more with @cescquintero . You can link the ticket number to the commit message ;)

As a general rule, delete them completely, but embed the relevant info in the commits (either the merge commit if you use one, or the commits of the branch itself if you don't) to link things to your issue tracker (see for example how GitHub handles lines of the form Fixes: #XXXX in commits, when the commit is merged the referenced issue is closed and retains a link to the commit that closed it).

Having too many branches actually has a negative impact on git performance (it's not much unless you have really crappy storage (or are stuck using WSL1), but it's there) and repository size (bigger impact here), even aside from the issue of finding specific branches.

When it's a "topic branch" (some stuff/features that you want to develop outside of master but that are really part of the "main development branch") then as soon as the code review has been done and the branch has been merged to master I almost always delete both the remote and the local branch. I cant remember that I've ever missed them later on, besides the commits are still there anyway, and it just reduces a lot of useless clutter which isn't helpful in any way.

I've seen projects where they keep feature branches for a long long time. This is something called long-lived branches.

I personally don't like it. I prefer short-lived branches.

In that regard, the only branches I keep in the projects I've worked are the ones related to the flow of deployment:

• master
• production

Everything else is deleted whenever it's possible: right after merging or when cleaning the repo.

It all depends on what the team wants to do with branches. I've fortunate to always have a say in how to order branches in my teams and this is the way we go.

And also I'm a very organized person and seeing all those branches make me itch and just can't resist the urge to delete them 🤣🤣

The best practice would be:

1. Name feature/bugfix branch having JIRA ticket # in name
2. When committing don't put JIRA ticket # in commit message
3. When done with development in that branch, merge it to master/develop branch, but make sure that JIRA ticket # is in merge commit message
4. Delete the feature/bugfix branch

This will make sure that:

1. During the development you know which branch is linked to that JIRA ticket
2. Will not poison your commit messages with JIRA ticket #
3. When merged the information about name of feature/bugfix branch and its JIRA ticket # is kept and still linked to JIRA
4. That repo then can be brought to any different bug-tracking/repository hosting system without having it too linked to Atlassian stack. If this would be needed in future...

Commit message should list relevant issues. In general this is a single issue. Some put the number in the summary, I stopped doing this, it is just better to search the history for a specific issue.

Do not keep merged branches around. It isn't worth it.

BTW, if in your commit you use the Jira story ID, then you'll never lose track of Jira <-> commit