DEV Community

Ben Halpern
Ben Halpern

Posted on

How do you make it easier to search through version control for deleted code?

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?

Top comments (14)

kaydacode profile image
Kim Arnett 

Couple of things, based on the feedback from the Twitters.

  1. 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.

  2. 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.

  3. 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.

  4. Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.

  5. 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. :)

ben profile image
Ben Halpern

Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.

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.

kaydacode profile image
Kim Arnett 

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. :(

Thread Thread
ben profile image
Ben Halpern

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.

eljayadobe profile image

Excellent! +1

I've also picked up some habits that I find very useful.

To delete dead code:

  • comment out the code
  • check in the change
  • delete the code
  • check in the change

To delete a file:

  • delete all the lines of the file
  • add one line, a comment, saying the file is being delete
  • check in the change
  • delete the file
  • check in the change

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.

razoxane profile image
Jade Edward

On deleting code in a single file, I agree with the other commenter about good commit messages (git add -p is 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.

denisenepraunig profile image
Denise Nepraunig • Edited

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.

eljayadobe profile image

There's a time-lapse view for git that mimics the time-lapse view that Perforce has in PV4.

michael profile image
Michael Lee 🍕

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/filename which helps isolate my search down to at least the file.

chilcutt profile image
Kyle Chilcutt

Get really familiar with your version control system! Here's some tips for git:

  1. Always write good, descriptive commit messages, this helps set up later tips.
  2. When you think you know what the commit message contains:
    • git log --grep "<search>" # search logs for string
  3. When you can't find what you want in the log, but know what some of the code said:
    • Use the pickaxe to search content: git log -S"<search>" # search content for string
    • Need something better? Use the pickaxe with a regex: git log -G"<regex>" # search content for regex
  4. When you can't find it in the log, don't know the commit message, but remember where the file was:
    • git log -- <path_to_file> # show logs of file path
  5. When all else fails, get your hands dirty:
    • git log -p # show logs with content
gonedark profile image
Jason McCreary • Edited

While 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 log commands.

aghost7 profile image
Jonathan Boudreau • Edited

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 -p and then search using /<search for something> in the less program (which is the default pager for git). Press n to go to the next match.

You can also use git grep to 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 of git grep '<search for something>' $(git rev-list HEAD). I've never had to use this particular combination before though, might be overkill.

stefandorresteijn profile image
Stefan Dorresteijn

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!

masticore252 profile image
Albert Vásquez • Edited

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 helpful

git bisect documentation