DEV Community: Gaurav Singh

Git Revert: A Safe Way to Remove Faulty Commits

Gaurav Singh — Sun, 29 Sep 2024 11:53:09 +0000

Have you ever faced a situation where you had to undo changes in the master branch because some unwanted code was committed, potentially leading to production bugs?

Well, we faced a similar issue in our project when a developer accidentally cherry-picked a commit that wasn’t tested and deployed it to production. Luckily, our app is an in-house product used by the company itself, so the impact was minimal.

Such cases can happen when you have a distributed team spread across a few countries and different time zones. Here's how we removed a particular commit from our master (production) branch and resolved the issue quickly.

Git revert to the rescue.
git revert is used to create new commits that reverse the effects of earlier commits (often just a faulty one).

The git revert command can be considered an "undo" type of command, but it is not a traditional undo operation. Instead of removing the commit from the project history, it inverts the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is crucial for the integrity of your revision history and for reliable collaboration.

In simple terms, git revert is used to undo a commit (say hash 2afe34), but it does so by creating a new commit that removes the changes from the commit (2afe34) you are reverting.

For example, if you’re tracking down a bug and find that it was introduced by a single commit, instead of manually fixing it and committing a new change, you can use git revert to automatically handle this for you.

Syntax:
git revert [--options] <commit>

git revert takes a specified commit from the history, inverts the changes from that commit, and creates a new "revert commit."

Let's demo it:
I have this index.html file I created for demo purposes. It contains an ordered list of fruits. Below are my commits with the changes made in each one:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Fruits</title>
</head>
<body>
    <div>
        <h3>Fruits list</h3>
        <ol>
            <li>Mango</li>
            <li>Orange</li>
            <li>Banana</li>
        </ol>
        <h3>Other list</h3>
        <ul>
            <li>Apple</li>
            <li>Pineapple</li>
        </ul>
    </div>
</body>
</html>

7afe5e3 (HEAD -> master) add other list
c8862d9 add banana
8db1cd2 add orange
f4e9e1f add mango
065a354 initial commit

My first commit is an initial commit with just the basic HTML structure like head and body. Rest commits are self explanatory. I added mango in commit f4e9e1f, orange in 8db1cd2, and banana in c8862d9 inside the first ordered list (<ol>). I then added a second ordered list with more items in commit 7afe5e3, which is the current HEAD commit.

Let’s say I want to remove banana from the list. In this simple example, we could just remove banana from the code and create a new commit reflecting that change.

However, in a collaborative project with multiple contributors, commit history becomes important to track the project's state at any given point in time. Moreover, manually undoing large code changes wouldn’t be feasible, and git revert becomes an inevitable solution.

Going back to our demo, to remove banana from the first ordered list, I can simply run git revert c8862d9 and this creates a new commit explaining the reason for the revert. You’ll see that banana is now removed from the list.

So new index file and commit history will look like below:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Fruits</title>
</head>
<body>
    <div>
        <h3>Fruits list</h3>
        <ol>
            <li>Mango</li>
            <li>Orange</li>
        </ol>
        <h3>Other list</h3>
        <ul>
            <li>Apple</li>
            <li>Pineapple</li>
        </ul>
    </div>
</body>
</html>

Commit history after git revert: git log --oneline

828ef17 (HEAD -> master) Revert "add banana"
7afe5e3 add other list
c8862d9 add banana
8db1cd2 add orange
f4e9e1f add mango
065a354 initial commit

Sometimes, Git is not smart enough to figure out the exact code that needs to be removed, leading to merge conflicts. In these cases, you, as a developer, need to help Git a bit.

It’s important to understand that git revert undoes a single commit—it does not "revert" the project to a previous state by removing all subsequent commits like git reset.

Reverting has two important advantages over resetting:

It doesn’t change the project history, making it a “safe” operation for commits that have already been published to a shared repository.
git revert can target an individual commit at any arbitrary point in the history.

Happy coding! 😊

𝗛𝗼𝘄 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗮 𝗟𝗮𝗿𝗴𝗲 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲

Gaurav Singh — Fri, 13 Sep 2024 16:55:44 +0000

Have you ever felt overwhelmed by a large and complex software codebase?

Joining an existing team with a large, unfamiliar codebase can be daunting, especially when there’s little documentation and poor test coverage.

I was recently tasked with adding a new feature to a project and it took me an unusually long time to complete. I wasn’t struggling because of my knowledge of the framework used or programming language, but because I didn’t fully understand how the project was designed or its various user workflows. It was my first time seeing this codebase and the tight delivery deadline only added to the pressure.

To get past this, I began searching how to quickly understand large, complex codebases. Here are a few key insights I’ve gathered. I call this 𝗧𝗼𝗽 𝗗𝗼𝘄𝗻 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵

𝟭. 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘁𝗵𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁’𝘀 𝗣𝘂𝗿𝗽𝗼𝘀𝗲: This may sound obvious, but sometime even experienced developers lack a basic understanding of what the system's main purpose is. Focus on understanding the business concepts before diving into the technology. Ask questions like: Who is using the software? What are their main objectives? 𝘊𝘰𝘥𝘦 𝘪𝘴 𝘮𝘦𝘳𝘦𝘭𝘺 𝘢 𝘮𝘦𝘢𝘯𝘴 𝘵𝘰 𝘢𝘯 𝘦𝘯𝘥 𝘢𝘯𝘥 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘬𝘯𝘰𝘸𝘪𝘯𝘨 𝘵𝘩𝘦 𝘦𝘯𝘥 𝘢𝘭𝘭 𝘤𝘰𝘥𝘦 𝘪𝘴 𝘦𝘴𝘴𝘦𝘯𝘵𝘪𝘢𝘭𝘭𝘺 𝘮𝘦𝘢𝘯𝘪𝘯𝘨𝘭𝘦𝘴𝘴.

𝟮. 𝗙𝗮𝗺𝗶𝗹𝗶𝗮𝗿𝗶𝘇𝗲 𝗬𝗼𝘂𝗿𝘀𝗲𝗹𝗳 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: Start with the high-level architecture before getting into the details of the each implementation. Understand the different layers, such as the web tier, business tier, and database tier, as well as front-end and back-end. You don’t need to know every technical detail, just enough to get a general understanding of the system’s structure. This can help to create a map of how different piece of technology work together.

𝟯. 𝗗𝗶𝘃𝗲 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗖𝗼𝗱𝗲: Begin with the specific code or component you’re working on. Understand what’s its purpose? What functionality does it provide? If available, unit tests can be helpful in understanding how a component works. In well-structured projects, good naming conventions for variables and methods often provide hints about many code flows.

It’s important to remember that this process isn’t immediate - understanding a codebase is iterative. The more you dig into these concepts and understand user journey flows, the easier it gets.

Don’t hesitate to ask for help if you are stuck. Happy coding!😊

LLMs Two Big Limitations: Stochastic Responses & Fabrication

Gaurav Singh — Sun, 04 Aug 2024 17:06:13 +0000

We all by now has heard the term Prompt Engineering but ever guessed why do we need it? The answer lies in the fact that current LLMs pose a number of challenges that make reliable and consistent completions more challenging to achieve without putting effort into prompt construction and optimization.

Currently LLM models face two big challenges - Stochastic and Fabrications

Model responses are stochastic:
This means if you ask the model a question and provide a text input, there is no guarantee that it will give you the same response every time. There is no guarantee that the response will be correct, and there is no guarantee that the response will be what you expected.

For example, the prompt: “Tell me about the element Calcium” gives different responses in different models.

With GPT-4o:

GPT-4o mini:

Clearly responses are not same, i.e. different model can produce different responses for same prompt.

Models can fabricate responses:
LLMs are trained on massive text datasets, but they don't understand the meaning of the words in the prompt or tokens; they just recognize patterns they can "complete" with their next prediction.

We use the term Fabrication to refer to the phenomenon where LLMs sometimes generate factually incorrect information due to limitations in their training or other constraints. This means they can generate realistic responses that are not factually accurate.

For example, with GPT-4o, the prompt:
“Who won the Player of the Match award for the ICC Men's T20 World Cup final 2026?”

As we can see, the two responses for the same prompt vary. The first one is close to being accurate, but the second response has made up a fictional award that hasn't happened yet.

Prompt engineering techniques like metaprompting and temperature configuration may reduce model fabrications to some extent.

GitHub Copilot has its quirks

Gaurav Singh — Mon, 15 Jul 2024 14:23:37 +0000

I've been using GitHub Copilot with our production codebase for the last 4 months, and here are some of my thoughts:

The Good:

Explains Complex Code: It’s been great at breaking down tricky code snippets or business logic and explaining them properly.
Unit Tests: Really good at writing unit tests and quickly generating multiple scenario-based test cases.
Code Snippets: It can easily generate useful code snippets for general-purpose use cases.
Error Fixes: Copilot is good at explaining errors in code and providing suggestions to fix them.

The Not-So-Good:

Context Understanding: It’s hard to explain the context to a GenAI tool, especially when our code is spread across multiple files/repos. It struggles to understand larger projects where changes are required in multiple files.
Inaccurate Suggestions: Sometimes it suggests installing npm libraries or using methods from npm packages that don’t exist. This is called Hallucination, where AI-generated code looks convincing but is completely wrong.
Complex Code: Occasionally, the code it generates is confusing and complex, making debugging harder. In those moments, I wish I had written the logic myself and let Copilot check for errors or bugs.

Overall, GitHub Copilot has been a useful tool, but it has its quirks. When using large language models, the responsibility always stays with the programmer.

Creating tech blog using MERN stack. Help!

Gaurav Singh — Sat, 23 Jan 2021 15:22:57 +0000

I am fairly new to blogging sites architecture and planning to create one in MERN stack.

I am good with MERN tech, but never built something of production level. There is lot of decision that I think I have to take before starting with code.

For starter...

What are some best practices to store each of the articles, is it in database(Mongodb)?
How static assets like images and videos are stored for blogging sites?
Do I need to implement some caching for api calls?

I want to built it from beginning and publish it as I know the tech but systems design is kinda daunting me!

Has anyone faced such challenge? What are your advice?

Thanks for reading.

Need help with deciding right track.

Gaurav Singh — Mon, 16 Dec 2019 14:11:18 +0000

I am beginner in python and JavaScript. What is the right path to move to AI and ML or data science?