Understanding Git in Simple way - Part 2

Source: Dev.to

Hello, I’m Ganesh. I’m working on FreeDevTools online, currently building a single platform for all development tools, cheat codes, and TL;DRs — a free, open‑source hub where developers can quickly find and use tools without the hassle of searching the internet.

Git Commit Structure

Each commit stores:

• Snapshot of the project files
• Metadata (author, date, message, etc.)
• Parent commit ID

Because a commit can have only one or more parent IDs (in the case of merges) and never references itself, the commit history cannot form a cycle. This guarantees a Directed Acyclic Graph (DAG) structure.

Directed Acyclic Graph (DAG)

The DAG represents the entire history of a repository:

• Every branch, merge, and decision is captured as a node.
• You can jump to any point in the history because each commit is uniquely reachable via its parent links.
• The graph is acyclic, so there is no way to create loops in the commit history.

Branches

A common misconception is that a branch contains a full copy of its parent commit. In reality, a branch is simply a pointer to a commit (its parent ID). It does not duplicate the data; it references the existing commit history.

Creating a New Branch

# Create and switch to a new branch named "iss53"
git checkout -b iss53
# Output:
# Switched to a new branch "iss53"

# Alternatively, you can create the branch first and then switch
git branch iss53
git checkout iss53

Committing Changes

If you need to make changes on the master branch:

# Switch to the master branch
git checkout master
# Output:
# Switched to branch 'master'

# Make your changes, stage them, and commit
git add .
git commit -m "Your commit message"

The DAG now includes the new commit on master, preserving the full project history.

Summary

• Every commit forms a node in a DAG, ensuring a non‑cyclic history.
• Branches are lightweight pointers to commits, not full copies.
• Creating branches and committing changes updates the DAG, allowing you to navigate the project’s entire evolution.

In the next blog, we will explore how Git knows the current working location and how branches are merged via pull requests.