Daniel Villa

Git Lessons Learned from Webflyx

Jan 9, 2026

Git CLI Version Control

Overview

Before this project, I was basically using Git like:

add -> commit -> push -> hope everything works

This project helped me understand what Git is actually doing under the hood. Instead of just memorizing commands, I started thinking in terms of history, branches, and how changes flow through a system.

What Git Is Actually For

Git is a distributed version control system. But more importantly, it's a tool for:

  • tracking changes over time
  • undoing mistakes
  • collaborating with other people
  • organizing work across branches

The biggest shift for me was realizing Git is not just about saving code. It's about managing change.

Branching Changed Everything

Working directly on main feels simple, but it's risky.

Using branches lets you:

  • work on features without breaking things
  • isolate changes
  • test before merging
  • collaborate more safely

Now I think in terms of:

"this change belongs in a branch"

instead of:

"just push it to main"

Fast-Forward Merge

A fast-forward merge happens when your branch is just ahead of main, and nothing else has changed.

A - B - C main
         \
          D feature

If main hasn't moved, Git just moves the pointer forward.

Why It Matters

  • clean history
  • no extra commits
  • easy to understand

This is the simplest case, and honestly the ideal one.

Non-Fast-Forward Merge (Merge Commit)

This is when both branches have new commits.

A - B - C - F main
     \
      D - E feature

Now Git has to combine both histories, so it creates a merge commit.

What I Learned

  • this is normal in real projects
  • it reflects actual collaboration
  • history gets more complex

This is where Git starts to feel confusing if you do not understand what is happening.

Why People Fear Merging

I used to think merging was risky. Now I see why people get nervous:

  • conflicts show up
  • history looks messy
  • you are not sure what Git is doing

But the problem is not merging itself. It is not understanding the history.

Once I started visualizing branches, merging made more sense.

Rebase

Rebase was the missing piece.

Instead of merging, rebase replays your commits on top of the latest main branch.

Before:

A - B - C main
    \
     D - E feature

After rebase:

A - B - C main
         \
          D - E feature

It makes it look like your work started from the latest version of main.

Rebase vs Merge

Merge

  • combines histories as they happened
  • creates a merge commit
  • shows the real branching structure

Rebase

  • rewrites your branch history
  • replays commits on top of main
  • creates a cleaner, linear history

What I Took Away About Rebase

Rebase is not "better" than merge. It is just different.

I would use rebase when:

  • I want to update my feature branch with the latest changes
  • I want a cleaner commit history
  • I want to avoid unnecessary merge commits

But I also understand now:

Rebase rewrites history, so you have to be intentional.

Merge Conflicts

Conflicts happen when Git cannot decide which version is correct.

Usually because:

  • two branches changed the same lines
  • something was edited in different ways

What I Learned

  • conflicts are normal
  • not a failure
  • you just need to decide what makes sense

It is less "Git broke" and more "you need to make a decision."

Commit History Matters

Commits are not just saves.

They are:

  • a record of decisions
  • a way to debug issues
  • a way to communicate with other developers

Now I try to:

  • keep commits focused
  • write meaningful messages
  • avoid messy history

Final Takeaway

Git is not about memorizing commands.

It is about understanding:

  • how branches diverge
  • how changes come back together
  • when to merge vs rebase
  • how to keep history clean

That shift made everything click.