When working on complex projects, you’ll inevitably encounter situations where you need to undo changes from a specific commit that’s buried several commits back in your history. Recently, I faced this exact scenario when commit 1d814e5 needed to be reverted from our development branch, but it wasn’t the most recent commit. This post explores the safest and most effective ways to handle this situation.

The Challenge

Looking at a typical git reflog, you might see something like this:

Safely Resetting to a Previous Commit in Git

When working with Git, sometimes you need to reset your working tree to a specific commit while preserving the commit history. This guide explains how to do this safely and understand what’s happening behind the scenes.

The Problem

Typically, when developers want to revert to an older commit, they might reach for git reset --hard. However, this can be dangerous as it:

Sometimes as developers we run into a legacy application that has been running in production for years when suddenly a bug surfaces. If nobody knows where the source code for that legacy application is, that can be a huge problem.

Introduction to .NET Decompilation

Decompilation is the process of converting compiled .NET assemblies (DLLs or EXEs) back into readable source code. This can be incredibly useful when:

• Dealing with legacy applications without source code
• Debugging production issues where deployed code differs from source control
• Understanding third-party libraries when documentation is insufficient
• Investigating potential security issues or malware

Using dotPeek

dotPeek by JetBrains is a powerful free .NET decompiler that can help solve these problems. I recently had an occasion to use it, and even without the .pdb file, it was able to decompile the code to be very close to the source code we had in source control that we knew wasn’t what was running in production.