Every journey in Git begins with the fundamentals, commands so simple they often go unnoticed, yet so powerful they define the very structure of collaboration.
Understanding init, add, commit, and push isn’t just about memorizing syntax; it’s about realizing what happens each time you record a piece of history.
Each command represents a decision, a checkpoint in your project’s evolution, a moment where code transforms from an idea into a traceable change.
Before diving into complex workflows, rebase conflicts, or merge strategies, it’s essential to internalize these basics.
True confidence in Git doesn’t come from mastering every command, but from understanding how a few simple ones connect to the bigger picture of version control, clarity, accountability, and shared progress.
In this page, I’ll revisit the basics not just to remember them, but to re-understand them, the way a developer grows by returning to fundamentals with new eyes.
git init vs git clone — Two Ways to Begin
Every Git project begins with a choice of how to start. If you’re building something completely new, you use git init.
If you’re joining an existing project, you use git clone.
These two commands define your starting point in Git’s world.
git init — When You’re Starting a History from Scratch
git init is the first breath of a new project. It turns an ordinary folder into a Git repository by creating a hidden directory called .git.
From that moment, Git begins to track every change, your project now has a memory and a history.
git init
Bash
복사
This command isn’t just initialization, it’s a declaration: “From now on, my work will be versioned and remembered.”
However, if you run git init inside a folder that already contains a .git directory, you may create duplicate or broken histories.
In that case, it’s safer to remove the existing .git folder (rm -rf .git) and start clean.
git init is perfect for personal projects, experiments, or learning exercises, any situation where you’re creating something new and want to manage its evolution from the very beginning.
git clone — When You’re Continuing an Existing Story
On the other hand, git clone starts from a completely different point.
It copies an existing repository, not just the files, but its entire history, its commits, branches, and tags.
git clone https://github.com/user/project.git
Bash
복사
git clone YOUR GIT REPOSITORY URL
This command downloads everything from a remote repository, allowing you to continue where someone else left off.
It’s not just copying files, it’s copying time itself, bringing the full version history into your local environment.
In short, if git init begins a new story, git clone lets you join one that’s already in progress.
When collaborating on a team project or exploring open source repositories, git clone is almost always your first step.
git add — Bringing Changes to the Stage
Just because you modified a file doesn’t mean Git is aware of it. git add is the process of bringing those changes onto the stage,
telling Git, “This is something I’m ready to record.”
git add index.html
git add .
Bash
복사
The first command stages a single file the second stages everything in the current folder.
It’s more than just “adding”, it’s defining the boundaries of a meaningful commit.
In Practice
•
git add . is powerful but dangerous, it may include unwanted files.
Use .gitignore to exclude logs, temporary files, and local configurations.
•
To undo a mistaken addition, you can unstage it:
git restore --staged <filename>
Bash
복사
Common Issue
“I added the file, but it’s not being committed!”
The file might be listed in .gitignore, or you didn’t stage it correctly.
Always check your repository state with git status.
git commit — Giving Meaning to Change
A commit isn’t just a snapshot of your work, it’s a statement of intent.
It answers the question, “Why did this change happen?”
git commit -m "Fix incorrect token refresh logic on re-login"
Bash
복사
A good commit message tells a story. It helps your future self or your teammates, understand not only what changed, but why it mattered.
Guidelines for Good Commits
•
Focus on the “why,” not just the “what.”
◦
Fix bug◦
Fix incorrect token refresh logic on re-login•
Keep each commit focused on a single logical change.
(Don’t mix UI edits with backend fixes in the same commit.)
Troubleshooting
“I committed, but nothing changed!”
Unstaged files aren’t included in the commit.
Always check with git status before committing.
“I made a typo in my commit message!”
You can fix the most recent commit with…
git commit --amend
Bash
복사
But if it’s already been pushed to a shared repository, avoid amending it to prevent history conflicts.
git push — Sharing Your History with the World
git push is how you send your local commits to a remote repository.
It’s the bridge between your personal history and the team’s shared truth.
git push origin main
Bash
복사
This pushes your local main branch to the remote repository named origin.
In collaborative environments, this step ensures everyone is aligned with the latest version of the codebase.
Common Errors
“error : failed to push some refs to…”
This happens when someone else has pushed newer commits to the remote branch before you did.
Your local history is now behind the remote one.
How to Fix
1.
Pull the latest changes first
git pull origin main
Bash
복사
2.
If conflicts occur, resolve them manually, then recommit and push again
git add .
git commit -m "Resolve merge conflict"
git push origin main
Bash
복사
Collaboration Tip
Instead of pushing directly to the main branch, create a feature branch and open a Pull Request.
This makes room for code review and keeps the main branch stable.
The Complete Flow — From init to push
At its core, Git follows a simple but powerful cycle
git init # Initialize a new repository (or use git clone)
git add . # Stage your changes
git commit -m "..." # Save a meaningful version of your work
git push origin main # Share it with others
Bash
복사
These four lines represent the essence of version control, the flow from creation to collaboration.
Learning Git isn’t about memorizing commands. It’s about understanding how changes are tracked, given meaning, and shared.
Once you internalize that flow, Git stops being just a tool, it becomes a language for expressing how you think and evolve as a developer.