0

We are currently playing with Git one of our developers wants to delete old branches from our repository. The reason for this request is 'house keeping'.

I'm from an SVN background and not properly versed in Git but, from my experience with SVN, you never delete a branch; it was a rule of thumb from day one.

There is nothing gained from deleting a branch in SVN because its size is relatively tiny and it may hold important commit/merge information that would be completely lost if it was deleted. And, from a house keeping perspective, if this branch is too hideous to look at, it can always be moved to another location that's well out of the way of the regular workflow.

Does anyone have any concrete reasons for deleting branches from a modern Version Control system?

Uyghur Lives Matter
  • 18,820
  • 42
  • 108
  • 144
ShaneC
  • 2,237
  • 2
  • 32
  • 53
  • 2
    Your statement about information being "completely lost if it (a branch) was deleted" is not true. Nothing is truly deleted from a Subversion repository unless you perform major surgery on the repository with `svnadmin` and `svndumpfilter`. *Anything* you delete in SVN can be recovered in the future, and deleting things that aren't needed anymore is not a bad practice. – alroc Oct 02 '14 at 01:58

3 Answers3

5

According to the accepted answer on the S.O question, "Git - When to Delete Branches": 

You can safely remove a branch with git branch -d yourbranch. 
If it contains unmerged changes (ie, you would lose commits by deleting the branch), 
git will tell you and won't delete it.

However, another author does go on to state:

 the disadvantage of deleting branches is that you will break any hyperlinks 
 to those branches on GitHub.

One of the biggest arguments I've found which talks about the disadvantage of deleting branches is discussed in the article titled, "Why I don’t like feature branches,":

 If feature branches are deleted once they are merged into master, where do bug 
 fixes go? On a new feature branch or on master? There will no longer be an easy way 
 to find a list of the commits that went into a feature.

The article Git Basics: Cleaning up excess branches, shows how you can automate deleting branches and make it a quicker process, if you choose to do so.

Please let me know if you have any questions!

Community
  • 1
  • 1
Devarsh Desai
  • 5,984
  • 3
  • 19
  • 21
  • 2
    The article you cite is written from somebody who thinks you shouldn't have any branches in the first place (the Martin Fowler school of thought), which is not particularly valid in the context of deleting a branch you have already created. – Andrew C Oct 01 '14 at 16:59
  • 2
    It doesn't matter what his viewpoint is, it's still a valid argument and a reason for concern when thinking about deleting a branch. – Devarsh Desai Oct 01 '14 at 17:10
  • Please explain how the two sentences you cite are valid generally or even applicable to the original question here. – Andrew C Oct 01 '14 at 17:34
  • 2
    Andrew, Shane wants to know if its ethical to delete a branch and there exists `any concrete reasons for deleting branches`. I'm citing a line in Paul's article stating, that when you're deleting a branch you should be aware that there `no longer be an easy way to find a list of the commits that went into a feature.`. This concern is something he should be aware of if he chooses to delete a branch. Please let me know if you have any questions. – Devarsh Desai Oct 01 '14 at 17:38
  • The author's mistake was presuming that he had a way before deleting the branch. Depending on their branch strategy, he already didn't have an easy way to find those commits. Deleting the branch doesn't change that. – Andrew C Oct 01 '14 at 17:44
  • 3
    Andrew, I think David W's answer below proves that, prior to branch deletion there is an easy way of finding the commits, in SVN anyway. After deletion, to find any branch information, you must find the revision number the branch was deleted in and 'undelete' it from the revision number previous to the one it was deleted from. Which seems as crazy to me as a concept as the sentence was to write – ShaneC Oct 02 '14 at 08:49
4

This Answer is in reference to Subversion.

I have no compunction about deleting obsolete branches and tags in Subversion. It keeps the /tags and /branches directories cleaner. Instead of hundreds of branches and tags, only a couple of dozen may show up.

If a branch is no longer being used for active development, and no one is interested in the code, why not delete it? If you have a tagged a revision of your code that no customer is using, and no developers no longer reference, why not delete it?

I usually have some sort of time basis for branches. No work done on them for a year? They're a candidate for deletion. If the developers are no longer interested in the code, out it goes.

In Subversion that nothing is ever permanently deleted You can always get it back:

Let's say I deleted the tag to Version 1.6 of our code. Suddenly an army of auditors show up demanding to examine that particular release of the code. I can run:

$ svn log -q -v http://server/repo/tags | less

And, find when I deleted that tag:

------------------------------------------------------------------------
r76229 | smith | 2011-09-01 11:26:47 -0400
Changed paths:
   D /tags/1.6

The 1.6 tag was deleted in revision 76229, so I know that tag was in revision 76228 of my repository. I can restore that tag:

$ svn cp -r76228  http://server/repo/tags/1.6@76228 http://server/repos/tags/1.6

If I merely want to see this code, I could check it out without undeleting the tag:

$ svn co -r76228  http://server/repo/tags/1.6@76228

Now the auditors can get to work and pester the developers and leave me in piece.

Community
  • 1
  • 1
David W.
  • 105,218
  • 39
  • 216
  • 337
  • So let me get this straight: after deletion in SVN, to find any branch information, you must find the revision number the branch was deleted in and copy the deleted branch to a new location from the revision number previous to the one it was deleted from? I know that this scenario is not one that would need to repeated on a regular basis, even so, it seems like a very convoluted approach when the branch could just be left as it is – ShaneC Oct 02 '14 at 09:30
  • 2
    @ShaneC It's a balance of needs. If you do a lot of branching, you could end up with hundreds and maybe even thousands of branches in your `/branches` directory. This can make it difficult for the developers to find the correct branch they should use. Imagine an obsolete branch (*Allow status posts to Friendster profile*). Is there work on it? Do the developers need to reference the branch? If not, why not delete it? If the fear that sometime in the future, Friendster will make a comeback, and you'll need this code, no problem. You can restore it. – David W. Oct 02 '14 at 18:42
  • @ShaneC Finding the revision where a branch was deleted takes only a few seconds. I run `svn log -v -q` against my Repos's URL, and pipe the output to `less`. Now, I can search for the deletion in `less` output using `/^ D /branch/branch_name`. The needed revision is right above this line. Use `k`, `^K`, `^P`, `y`, or `^Y` to go backwards up a few lines. Once you find the revision, restoring the branch is a single command. – David W. Oct 02 '14 at 18:54
2

Branches in Git (generally speaking) don't matter after they have been merged. They are only useful if they point to unique commits not reachable via any other means.

Git even provides git branch --merged which is documented as 

--merged is used to find all branches which can be safely deleted,
       since those branches are fully contained by HEAD.
Andrew C
  • 13,845
  • 6
  • 50
  • 57