The basic instruction is that one should delete dead code and find it later in version control if it is needed, but this requires the step of making it reasonably easy to find it. What are the steps you go to to ensure this task is straightforward?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (14)
Couple of things, based on the feedback from the Twitters.
Learning how to write effective, short, sweet, to the point commit messages.
Start your commit message with the story or task id you worked on. Things like that help too.
If you're tinkering, and not sure if you'll use the code tomorrow, it's totally fine to comment it out and save it. However, don't forget about it. Typically I'll put "tinker" code in a branch and clean it up before merging.
The end goal is to create clean, maintainable code that other developers can continue building on. If they have to sort through many dead functions, it's not going to give them a fresh perspective to fix the problem. Instead, they'll be inclined to resurrect your dead code. A huge issue I have with this - anything I built a year ago, I can build better and more efficient today. Why wouldn't you want that.
Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.
Lastly, we've had to resurrect old features that were once deleted due to scope change. So - we went to the last known release tag with that feature in it, checked it out and found the feature we needed.
Again: Create clean, maintainable code for other developers. Your version control is not only for you - even if you are the only developer currently. Someday others will take it over. *deep breath.
I'm looking forward to other input and tips too. :)
We have not been doing that but it's a great call. As a web-first shop it may not occur to us to see any release as major the same way I imagine it would be in iOS world.
I could definitely see how the lines get blurred. Releases on mobile are generally driven by feature changes.. so it's memorable like that too. Can't speak to the web equivalent. :(
In somewhat counter to the first point of "short, sweet, to the point commit messages", lately I've tried to stuff some keywords into my commit messages to make searching through GitHub easier. I'm really not sure how reliable this is.
Excellent! +1
I've also picked up some habits that I find very useful.
To delete dead code:
To delete a file:
Saved my bacon many time.
And for those who are unfamiliar with clean code, read the book Clean Code by Robert Martin. It's got good mojo.
On deleting code in a single file, I agree with the other commenter about good commit messages (
git add -pis your friend!).For entirely deleted files, I use GitFlow, and as part of my release notes, I use a script that compares master to the release branch to get a list of added, modified, and deleted files, and the last known blob commit hash URL for those files, then include that in the change log and/or release notes.
Makes it really easy to find when a specific file was deleted, as finding removed files can be challenging in both CLI git and in Github if they are no longer in the codebase, or have been renamed.
I stumbled upon this discussion too - yeah sure we have version control - so nothing is lost - but FINDING deleted code is hard. Good commit messages help, but this is maybe not obvious.
I was thinking about some kind of a time-machine for files - so basically something like:
git log --follow file
get an overview about the changes + some "UI" or command line tool to "travel" back and forth between commits - may only my commits
git checkout commit (to be able to see the "whole" file - not just the changes - at a certain point in time)
Does something like this exist? I saw some node-git packages, may this is a starting point to implement something like this.
There's a time-lapse view for git that mimics the time-lapse view that Perforce has in PV4.
Oh man, this is a tough one. I don't know how to make it easier. I think @kimberlypilbeam has outlined some really good thoughts. I especially like the thoughts on tagging. As I've used that approach when pushing out weekly builds of an application.
What I can share are some things I do in my own workflow. While I mainly use git on the command line, searching for specific commits is just easier visually. For this, I use a git app called GitUp on macOS. Super lightweight and open source. It's also has a command line tool to quickly start it up.
Other than that, if I know the specific file the code was deleted on and just want to see the history of that file to track down the code, I run
git log -p path/to/filenamewhich helps isolate my search down to at least the file.Get really familiar with your version control system! Here's some tips for
git:git log --grep "<search>" # search logs for stringgit log -S"<search>" # search content for stringgit log -G"<regex>" # search content for regexgit log -- <path_to_file> # show logs of file pathgit log -p # show logs with contentWhile I think this is an interesting discussion and there are some good comments here, I question if this is a real problem.
The focus of Git is code - more accurately changesets. There is no other context. As such, the history Git forms only indirectly relates to how your project changed.
You can (and should) make individual commits for deleted code. You can (and should) add tags to mark contextual milestones for the project. But attempts to write a fuller commit message or copy changesets are ultimately trying to outsmart Git and yourself.
Gits job is not to remember you may need this code in the future. Gits job is simply to remember the code. You have to make the connection. That's a human job. You have to have some clues - what code, what file, around when? That's the hard part. From there it is easy, just use those clues to run
git logcommands.I actually haven't really run into issues with deleting code instead of commenting it out. Part of it is probably being able to search through the history effectively. There's the basics like being able to go back a blame and being able to see previous versions of a file from your editor. But there's probably some more advanced things which could be used for this specific problem.
The first thing which pops into my mind is
git log -pand then search using/<search for something>in the less program (which is the default pager for git). Pressnto go to the next match.You can also use
git grepto search through multiple revisions. Lets say you want to search through all the revisions in your current branch - you could run something along the lines ofgit grep '<search for something>' $(git rev-list HEAD). I've never had to use this particular combination before though, might be overkill.We use git flow with all our feature branches being named after their Jira tasks. It's a little strict but it does mean it's very easy to find which code belongs to which function.
We also at this point have about 150 branches and have only been working on this project for two weeks. Worth it though!
You can always use
git bisect, it is meant to find bugs but if you know the files where the deleted code was it will be helpfulgit bisect documentation