I have forked a repo and branched that clone to code a story, and because I didn’t understand the problem, wrote code that isn’t solving my task at hand, but may prove useful later.
Should I:
- Delete it, and don’t worry about it. Then commit without the extra code.
- Make yet another branch for just that work, commit it, but don’t post a pull request on it.
- Just commit it with the existing code, and worry about the extra “fluff” later.
I was thinking #2. If I understand correctly, I could just keep the extra code on a branch I never use on my clone, and dig it up later if something comes up that may benefit from using it.
4
You should have included option number 4….
4. Commit it with the extra code, and then delete it and commit it again.
If you don’t commit it, it is lost. If you commit it and leave it in, then you have an extra source of confusion — you should try to avoid having other people scratching their heads and wondering WTF is going on here…
Commit it, delete it, commit it again — add a couple of good commit comments and you’re golden.
5
Option #2 is legitimate if the code really could be useful later on. #3 is not the right answer.
Option #1 is probably the right answer. More often than not, the code should just be scrapped. As programmers, we don’t like to delete code–if feels like throwing out our babies. One of the biggest rules of programming is “do not be afraid to delete code” (I think Jeff Atwood had a post to this effect, but I don’t have the link handy). Unused code that gets squirreled away seldom finds its way into a working project. It just sort of molders there until someone finally deletes it (even in another branch) because it’s been laying around forever and no one knows why it’s there.
8
You need to make an assessment of whether it is likely that the code will be used in the future:
- If it is (realistically) unlikely, then just get rid of it; i.e. #1
- If it is likely #3 followed by some refactoring to make sure that the “fluff” code doesn’t impact on your actual builds, test coverage, etc.
My reason for preferring #3 over #2 (or #4) is that code on old development branches or in the revision history is hard to find … unless you know to look for it. When I look at a codebase to see if some bit of functionality is there to be reused, I look at HEAD:master. I don’t trawl through the old branches, or through the commit logs.
Now in your case, there is a reasonable chance that you will remember that you implemented the functionality and then removed it from “master”. But your co-workers are unlikely to know this, and even if you mention it to them they likely to forget it. However, if the code is still in HEAD:master, then there is a much better chance that they will find using IDE search.