DEV Community: Alson Garbuja

How Git manages to stay lean and fast ⚡?

Alson Garbuja — Wed, 04 Mar 2026 08:34:19 +0000

You launch a project, initialize Git, stage your changes, and commit. Boom. Just like that, you have version control—a permanent, searchable history of your work.

As the project scales into something massive, the need for experimentation grows. You decide to build a complex new feature, so you spin up a branch. Bam. In seconds, you have a parallel sandbox where you can break things, fix them, and evolve your code without ever touching the stability of your main build.

Yes, that is the power of Git. It is fast, efficient and stays leans even when your project is huge and complex.

In this post, I will try to explain the behind the scene of how git manages to do it.

Chapter 0: The three areas

Imagine you are launching a new project. To ensure every move is recorded and the chaos of multiple contributors is kept at bay, you reach for a foundation: you initialize Git.

Git works by dividing your project into 3 distinct areas, Working, Staging, History/Snapshot.

Working area: This is the area where you actually work and make changes.
Staging area: This area holds the changed and added files from the project.
Snapshot area: Finally this area holds the history/snapshot of each commits.

So you make changes to the project and ready to use the power of GIT.

Chapter 1: Staging

As soon as you stage your changes (git add), Git compresses the file content using zlib and generates a SHA-1 hash.

Why generate a hash instead of simply copying the changes to history? This hash acts as a unique digital fingerprint, enabling a superpower known as "deduplication". Because the SHA-1 hash is derived strictly from the file's content, identical content always produces the identical hash.

Hence if you have the same file content across multiple locations in your project, Git doesn't store multiple copies of the data. Instead, it stores the compressed object once and simply points every instance to that same SHA-1 hash, saving a massive amount of storage space.

To tie everything together, Git creates a mapping file known as the index (located inside the .git directory).

Think of the index as the "staging map." It creates a direct link between your familiar file paths and the newly generated, compressed SHA-1 blobs. Instead of Git searching through your entire folder structure every time, it refers to this lean binary file to know exactly which version of a file belongs where.

This index is the secret bridge that allows Git to track your workspace changes in real-time and prepare them for the final commit without any overhead.

Chapter 2: Commiting

With your changes staged and ready for the history books, it’s time to secure them. You execute the command: git commit -m "Your message".

Under the hood, Git first validates the changes by looking at the difference between hashes from previous commit to new one. Then it extracts the authors metadata. Finally, Git creates a commit object. This small text file contains the essentials: a unique commit ID, a pointer to the parent commit (linking it to the previous history), the author’s metadata, a timestamp, and your message. Compresses it and saves it.

Because Git has already compressed your files and generated their SHA-1 hashes during the staging phase, the "heavy lifting" is already done. Creating a commit is simply a matter of recording this new metadata and linking it to the existing chain. Your project's state is now officially captured as a permanent, lightweight snapshot in Git’s history.

Chapter 3: The tree

Beyond just file blobs and commit objects, Git organizes your project using a Tree structure.

Think of a Tree object as a virtual directory. Each node in this tree stores essential metadata: the file mode (permissions), the type (is it a "blob" or another "tree"?), the SHA-1 hash, and the filename.

This hierarchical design is the secret to Git’s efficiency. When you modify a single file, Git doesn't need to rebuild your entire project structure. It simply traverses the shortest path to that specific leaf node. It updates only the affected nodes along that path while leaving the rest of the tree untouched, pointing back to the existing, unchanged hashes.

This surgical precision is exactly why staging and committing remain lightning-fast, regardless of how many thousands of files your project contains.

Chapter 4: Branch

Your project has grown massive and complex, but a radical new idea strikes. You want to experiment without breaking your stable build. This is where Git reveals its true power: Branches.

You might worry that such a huge project would make branching a slow, storage-heavy nightmare. Yet, the moment you run git branch "branch-name", the new branch appears instantly. You switch over, and in seconds, your entire workspace shifts.

How is this possible? It lies in Git’s architectural genius. Instead of duplicating your entire history or copying files into a new folder, Git simply creates a 41-byte text file. This tiny file acts as a pointer, containing nothing more than the SHA-1 commit hash of the branch's tip.

Whenever you create a new commit, delete one, or roll back, Git doesn't move mountains; it just updates the hash inside that small text file. Since the chain of commit history is already linked through parent pointers, Git only needs to know the "head" of the chain to give you access to the entire timeline.

You might wonder: how does Git know which branch you are currently using? The answer is equally elegant. Inside the .git directory, a file named HEAD acts as a master pointer. It contains a simple reference to the branch file you are currently checked out to. That is it—simple, efficient, and lightning-fast. This is the power of world-class software architecture at work.

Chapter 5: The Reflog

We have covered the genius architecture that makes Git efficient, fast, and lean. Now, let’s look at its ultimate safety net: the Reflog.

Stored within the logs folder inside your .git directory, the Reference Log (or reflog) is a chronological record of every single move you’ve made in your local repository. By default, it tracks your actions for 90 days—even those that aren't part of a formal branch history.

If you accidentally perform a hard reset to an unknown commit or "lose" work during a messy rebase, Git still has your back. By running git reflog, you can see the history of your HEAD pointer, find the hash of the commit right before the chaos happened, and restore your project instantly with git reset --hard [hash].

It is the ultimate "undo" button, proving that Git's design isn't just about speed—it’s about absolute data integrity.

Well there you have it. How Git manages to stay lean, fast and efficient even when our projects gets complex and massive. If you have any questions then feel free to comment and let me know if there is any mistakes.

References:

Idempotent: What does this means?

Alson Garbuja — Fri, 25 Oct 2024 14:48:39 +0000

Welcome back to our series, Now You Know! Last time, we explored the concept of the Virtual DOM and how React leverages it to update and render components efficiently.

Today, we’re diving into a mathematical and programming concept: idempotence.

If you find this helpful, like, share with friends, and comment on topics you’d like us to cover next. Let’s get started!

According to Wikipedia

Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.

But what exactly is an idempotent operation, and why should we care about it? Let’s dig in.

Idempotent operation

An idempotent operation is one that can be performed repeatedly with the same result every time. In other words, running it multiple times yields the same outcome as if it were only run once.

In the example above, we see a simple multiplication operation with two parameters, 2 and 2, producing a result: “The answer is 4.” No matter how many times this operation runs, the result will always be the same.

Why care about Idempotence?

Now that you understand idempotent operations, you might wonder why they matter. After all, you’ve likely written many functions that behave in such way. But understanding idempotence is crucial, it brings consistency and reliability to the system.

Especially in areas such as:

Database operations: Making database operations such as writes and updates idempotent ensures repeated operation doesnot change the stored data unexpectedly.
API design: With idempotent API endpoints we can be sure unintended consequences do not occur in repeated calls.
Network requests: Retrying failed request calls becomes safer, since we know the operations are idempotent and will not produce unwanted results.

Idempotent is not just property but a foundational principal that ensures we build resilient and predictable system.

Examples of Idempotent operation

Some examples of where Idempotent operation can be used are:

API endpoints: GET endpoints in REST APIs are Idempotent in nature. No matter how many times we call a GET resource from the server, the server will always return the data in the format specified and data present in the database.
Transaction operations: Transaction of money from one account to another account is one of the most used operation around the globe and they must be created as Idempotent operation since we don't want customers getting charged extra for honest mistake like network latency, lack of system knowledge or poorly designed system

Similary it can be helpful in many situations where predictability and reliablity of the system is priority.

Cavaets

While Idempotent offers stability and produces resilient systems, not all operations must be Idempotent. Some cavaets to keep in mind are:

Not always applicable: Not all operations/functions can be Idempotent. Operation such as Increment/Decrement operation cannot be made Idempotent with out extra handling and probably should not be made Idempotent either since we need different result in each calls.
Complexity in implementation: Making certain operations idempotent may introduce extra complexity. For example when retrying transaction operation we need to ensure the customer isn't charged multiple times which requires sophisticated handling of the overall transaction operation.
Performance overhead: Implementing idempotence, especially in distributed system will add extra steps(such as tracking state, checking for duplicate datas), which might impact performance.

Conclusion

To wrap up, idempotence is a foundational concept that allows us to design operations that are predictable, resilient, and ultimately contribute to building reliable systems. It plays a key role in fields like API design, database transactions, and network requests.

But with every concepts of programming and life, idempotence is not with its limitation and should not be used overly.

Just like with the Virtual DOM, after reading this, I hope I can say, Now you know! If you found this helpful, feel free to share it and let us know what you’d like covered next. Until then—happy coding!

Virtual DOM: Technque behind React's quick DOM updates.

Alson Garbuja — Mon, 21 Oct 2024 11:41:17 +0000

Hello everyone, I’m excited to kick off a new series of posts where I’ll try to explain various concepts from the programming world. We’ll cover everything from terms like idempotent and idiomatic to more specific concepts related to libraries and frameworks. And today, we’ll dive into one such topic — Virtual DOM.

If you find this helpful, don’t forget to Like, Share, and Comment about which topics you’d like me to cover next. Let’s not waste any more time and jump straight into the Virtual DOM!

NOTE: Before we continue, it's important to understand that the concept of a Virtual DOM is not exclusive to React. Other JavaScript frontend libraries, like Vue, also use it to enhance rendering performance.

DOM

The DOM (Document Object Model) is a tree-like representation of an HTML document (or webpage/web application) using nodes or objects. The DOM was designed so that frontend libraries and frameworks (javascript) can interact with and manipulate the document programmatically via its API.

Why Virtual DOM

While the DOM provides an efficient way to manipulate a document through its API, performance can become an issue when there are thousands of elements on the screen. This is because updates in the DOM often involve destroying and recreating entire subtrees.

This is where the Virtual DOM comes into play. The Virtual DOM is a lightweight, in-memory representation of the Real DOM, allowing for fast and efficient synchronization of changes to the actual DOM — a process known as Reconciliation.

The key things to remember here are:

The Virtual DOM is a lightweight version of the Real DOM, meaning it doesn't have all the properties of the Real DOM, which makes it more efficient to work with.
The Virtual DOM exists in memory, allowing for faster and more efficient manipulation before the changes are applied to the Real DOM.

With this in mind, JavaScript libraries that use the DOM API create their own Virtual DOM and manipulate it. They update the Real DOM only when necessary, and even then, with minimal operations.

How is virtual DOM handled in React??

React JS is a popular library developed by Facebook for building user interfaces. Due to its simplicity it has gain massive popularity and used in many modern web projects.

Like many other JS frontend libraries, React uses the concept of a Virtual DOM to efficiently manage re-renders and updates in an application.

React uses a diffing algorithm alongside a reconciliation technique to optimize this process. (Specifically, the ReactDOM library handles this behind the scenes.)

Lets break it down step by step:

React component's render() function
- The render() function of react component first create the React Element/Virtual DOM with the JSX.
- It contains lightweight version of Real DOM counterpart and extra properties such as $$typeof, props, to facilitate efficient diffing.
Diffing algorithm
- Whenever a React component is updated, a new Virtual DOM is created, and the diffing process begins. This is an O(n) heuristic algorithm based on two key assumptions.
  1. Different types of elements produces different trees.
  2. A key prop can be used to track which child elements remain consistent between renders.

2.1. Steps in diffing algorithm

When the algorithm encounters two different types of DOM element: it will tear down the old Virtual DOM and create a new one from scratch based on the new element's specifications.
When React encounters same types of DOM element: it preserves the old DOM object and only updates the changed attributes.
For React elements of the same type, React keeps the old DOM object intact and supplies updated props.
When handling child elements, React iterates through both sets of children (old virtual DOM tree and newly created tree), making updates where differences exist.

2.2. Why use keys?

As mentioned in the last point, the diffing algorithm iterates through child lists and makes changes where necessary. If you don’t use keys in a list of children, performance might suffer, and you could encounter unexpected behavior.

Let's see example:

<ul> // old list
  <li>apple</li>
  <li>pineapple</li>
</ul>

<ul> // new list
  <li>apple</li>
  <li>pineapple</li>
  <li>grape</li>
</ul>

In the above scenario the algorithm can actually efficiently handle the modification. It looks at each index child and finds <li>apple</li> && <li>pineapple</li> is same in both list and does nothing to them while <li>grape</li> is only present in new list hence adds one to the old list.

But say, we want to add the <li>grape</li> at the beginning.

<ul> // old list
  <li>apple</li>
  <li>pineapple</li>
</ul>

<ul> // new list
  <li>grape</li>
  <li>apple</li>
  <li>pineapple</li>
</ul>

Here the performance of the algorithm will decrease as it sees <li>grape</li> inplace of <li>apple</li>, <li>apple</li> inplace of <li>pineapple</li> and a new <li>pineapple</li> in the last position. Thus recreating all the elements from strach.

To solve this performance bottleneck, React team employees the use of Key which is an unique id attached to the list child items that can be used by the algorithm to determine if the item can be left intact and just reorder the position or needs to be recreated.

<ul> // old list
  <li key="a.fruit45">apple</li>
  <li key="p.fruit90">pineapple</li>
</ul>

<ul> // new list
  <li key="g.fruit20">grape</li>
  <li key="a.fruit45">apple</li>
  <li key="p.fruit90">pineapple</li>
</ul>

Now react can use the Key attributes and only reposition the non updated child items while adding the new child item.

3) ReactDOM's render() function

Finally the ReactDOM's render() function is called, which reconciles the differences between the new Virtual DOM and the Real DOM. This results in minimal operations needed to re-render the HTML efficiently.

Conclusion

In this article, we’ve explored the Virtual DOM, a technique used by many frontend libraries to handle data and element changes efficiently with minimal DOM operations. We also looked at how React specifically uses a diffing and reconciliation process to optimize updates.

I hope this post helped you better understand how the Virtual DOM works. Even if you were familiar with the concept, I hope Now you know what is Virtual DOM and how it contributes in creating optimized frontend environment.

Reusability: A magic potion or curse in disguise

Alson Garbuja — Thu, 10 Oct 2024 07:40:22 +0000

Reusability is a common term in programming, known for its benefits. But is it really as helpful as people say, or is it just an overused concept? In this article, we’ll explore what reusability truly means and whether it’s the hero people claim or just another fancy over used software term.

What is Reusability?

Keeping it simple. Reusability in software engineering refers to the idea of creating components or functions that can be reused in the future. In simple terms reusability is like making a handy tool out of your broom in order to clean tight corners of your room then instead of taking it apart you keep it intact so that you can use it next time you clean your room.

Benefits: What makes it a hero!

Reusability offers several benefits in the programming world, including:

Eliminates code duplication: By reusing code, we can avoid having duplicate code in our codebase.
Single source of truth: Since the same code is used in multiple places, we have a central location to check and fix any errors.
Reduces code size: Along with cutting down on duplicate code, reusability also helps minimize the overall number of lines in the codebase.

In addition to these, there are many other advantages we can gain by applying the concept of reusability in our projects.

Examples of applying reusability

Now, let's look at some examples of how to apply the concept of reusability. For this demonstration, I'll be using the React library, though this concept can be applied to any programming language.

Reusable component/Widget/UI

export default function PhoneTile({ name, avatar, number }) {
  return (
    <div className="px-2 py-4 rounded-md bg-white shadow-md text-black">
      <div className="flex gap-4 items-center">
        <img src={avatar} alt={`profile pic of ${name}`} className="w-12 h-12 rounded-full object-cover" />
        <a href={`tel:${number}`}>{name}</a>
      </div>
    </div>
  );
}

In the example above, we've created a PhoneTile component, which can be placed in a separate file and reused across different parts of the project. To use it in various components, all you need to do is pass the necessary props, which are name, number, and avatar.

Reusing functions

export const apiCaller = async (url, method, payload) => {
  try {
    let options = {
      method,
      headers: {
        "Content-Type": "application/json",
      },
    };

    if (payload) options[body] = JSON.stringify(payload);

    const res = await fetch(url, options);
    const data = await res.json();

    if (!res.ok) throw new Error(data.message); // considering your error is present in the message key
    return data;
  } catch (error) {
    console.error(error); // Or you can throw it and handle it elsewhere
  }
}

We've created a function called apiCaller that takes a url, method, and an optional payload to fetch data or log errors using the fetch API. By defining this function as a separate global function, we can reuse it throughout our project for various tasks, like fetching user data, updating user information, and more.

Reusable constants

enum Direction {
  Up = 1,
  Down,
  Left,
  Right,
}

We can also apply reusability when defining constants in our program. For instance, I've created an enum called Direction in TypeScript, with four values ranging from 1 to 4 (Note: the values can be any numbers we specify). Instead of using the number values which are difficult to remember, we can use the more inuitive and understandable labels Up, Down, Left and Right. These values can then be reused anywhere in our codebase, improving readability and reducing errors.

Potential danger lurking behind the scenes

So far, we’ve discussed the positive aspects of reusability, and it’s clear that it offers many advantages for writing cleaner and more efficient code. However, what many, especially beginners, may not realize is that reusability also comes with certain disadvantages.

Let's look at those disadvantages one by one.

Correctly spelling reusability: The frustration i had while attempting to spell reusability and instead typed resuability is unmatched. Just joking here, jokes apart below are the real disadvantages listed.

Over reuse

While reusability is excellent for reducing code and making it cleaner, it doesn’t automatically guarantee maintainable code. Returning to our analogy of the broom tool—which we created to clean tight corners efficiently—if we try to use the same tool to clean regular floors or rooftops, it could lead to issues.

Similarly, if we use the PhoneTile component to represent a contact folder by adding optional isFolder and onClick props, and also reuse it to display an email list, we might start facing problems. While reusability is great, stretching a component beyond its original purpose can make the code harder to maintain and understand, potentially leading to confusion and bugs.

export default function PhoneTile({ name, avatar, number, isFolder, mail, onClick }) {
  return (
    <div className="px-2 py-4 rounded-md bg-white shadow-md text-black">
      <div className="flex gap-4 items-center" onClick={onClick ?? () => {}}>
        {isFolder ? <FolderIcon /> : <img src={avatar} alt={`profile pic of ${name}`} className="w-12 h-12 rounded-full object-cover" />}
        <a href={number?`tel:${number}`:mail?`mailto:${mail}`:"#"}>{name}</a>
        {mail && <MailIcon />}
      </div>
    </div>
  );
}

As we can see, the code begins to get messy. While we may reduce code duplication and write less code, the overall developer experience deteriorates. It becomes much harder to maintain and manage this kind of code over time, leading to increased complexity and confusion.

Difficulty in testing

Another problem that will surface up when over reusing or not correclty implementing reusability is the difficulty while testing.

Unit testing is a crucial step in the software development process, and used to test different components or functions in a unit level. Hence excessive reliance on a single component to accommodate various functionality can make it nearly impossible to test each case separately

Here is an example of how the unit test for well-designed component and poorly created reusable component might look like. (NOTE: I am using jest along with testing library)

// Proper reused component unit testing
test('Check if phonetile shows correct info', () => {
  render(<PhoneTile name="Alson" number={1234567890} avatar="https://api.dicebear.com/9.x/bottts-neutral/svg?seed=Alson" />)
  expect(screen.getByRole('a')).toHaveTextContent('1234567890')
});

// Poorly reused component unit testing
test('Check if phonetile shows correct info', () => {
  render(<PhoneTile name="Alson" number={1234567890} avatar="https://avatar.com/alson.png" />)
  expect(screen.getByRole('a')).toHaveTextContent('1234567890')

  // We have to test for different types again which defeats the purpose of unit testing
  render(<PhoneTile name="Families" isFolder={true} onClick={navigateToFamiliesList} />)
  expect(screen.getByRole('a')).toHaveTextContent('Families')
});

Conclusion

Reusability, like many software concepts, is neither an absolute hero nor a complete villain. Its effectiveness largely depends on how developers implement and leverage it. Ultimately, reusability can be a powerful asset or a source of complexity, based on the choices made during development.

Here are some of the questions and steps for beginners to filter out if they need to make any component/function/constant or block of code reusable or not.

Do not over complicate the reusable blocks of code by over reusing (over engineering) it. Have one block of code handle only one function.
Reuse any component/function/constants if and only if, it is needed to be reused again in an Idompotent manner.
Divide and conqure can be applied in cases where we need to reuse some block of codes for different functionality. By futher dividing parts of reused codes into smaller reusable codes.

Staying motivated in development world

Alson Garbuja — Fri, 03 May 2024 08:15:44 +0000

Developers have it rough, and I understand it is not easy to be a developer, especially when met with unrealistic deadlines, bugs, code breaks, and threats from AI nowadays.
Needless to say, it is really difficult to stay motivated as a developer sometimes.

Here are some tricks I personally use to stay motivated in my work as well as on personal projects.

Break the problem

One of the fundamental concepts in programming is breaking a bigger problem into smaller chunks that can be solved one after another. Instead of trying to solve a big problem at once, why not take a step back for a moment and break that problem into smaller problems?
A big goal in front of you to finish by a certain deadline will be much harder to tackle than having smaller and more realistic goals to be finished at the same time.

Join communities

What can't be done alone can only be done with a team. While working independently can hone your skills, working in a team when needed will help you boost your skills by 10X.
It takes less time to debug and find solutions; you can gain perspective from different developers (from different viewpoints) to find the optimal solution.
Join virtual or physical communities with developers of like mind and similar skill sets. They will help you stay motivated.

Find your passion

It sounds obvious, and you might have heard it from thousands of developers. When I say find your passion, I mean "the thing" that first got you into programming. Go back to your roots and do some personal, fun, and bite-sized projects to get yourself the adrenaline that you first got when you started. For me, it was game development that I wanted to do, and ultimately I ended up doing programming. So when I get frustrated with all the errors and bugs, I just take my time off from that and work on personal game projects to keep me motivated.

Take some well-needed rest.

It is one of the most effective ways to stay motivated and also a way to have a long-lasting career in not only the development world but every other aspect of life. We are humans, not machines; we get tired and anxious over repetitive tasks. So in order to not get tired and anxious, you should take some rest and get yourself some fresh air.
Go somewhere cozy, watch something fun, or do some sports; just get out of your chair and do anything new. Refresh your brain, come back, and look at the problem from a different perspective.

I hope these tips and tricks will come in handy in keeping you motivated and creating amazing products.

Happy developing 👨‍💻