🌐 Read this post in Bahasa Indonesia here.
📝 A note on this article
This post is based on my personal study notes. The ideas, learning journey, and understanding are mine — I used AI to help structure and expand them into a proper blog format form.
Learning Git doesn't have to be intimidating. In this article, I'll break down the essential concepts of version control and collaboration — using simple analogies that anyone can understand.
What Is Git?
Git is a version control system. Think of it as a save system for your code — like save points in a video game. Every time you save (commit), Git remembers the state of your project at that moment. If something goes wrong, you can always go back.
Repository: Your Project's Warehouse
A repository (or "repo") is the folder that Git watches. There are two types:
- Local repository: lives on your computer. Your personal workspace.
- Remote repository: lives on a server (GitHub, GitLab, Bitbucket). The "official" shared copy your team can access.
They stay connected through a Remote URL, so you can push your local changes up and pull others' changes down.
git init # Start tracking a folder
git remote add origin <url> # Connect to a remote repo
git push origin main # Send commits to remote
git pull origin main # Get latest from remote
Commit: Your Project's Save Point
A commit is a snapshot of your project at a specific moment. Each commit has:
- A message describing what changed
- A unique ID (hash)
- A timestamp
git add . # Stage all changes
git commit -m "Add homepage layout" # Save a snapshot
git log --oneline # View commit history
Write meaningful commit messages. Future you will thank present you.
Checkout, Reset, Revert: Traveling Through Time
These three commands all interact with your commit history — but in very different ways:
git checkout — Visit the Past (Temporarily)
Like a time traveler with a visitor's pass. You can look around at an old commit without changing anything permanently.
git checkout <commit-hash> # Visit an old commit
git checkout main # Go back to the present
git checkout -b new-branch <hash> # Start a new branch from old commit
git reset — Erase History
Goes back to a past commit and removes everything that came after. Use with care — especially if you've already pushed.
git reset --soft HEAD~1 # Undo last commit, keep changes staged
git reset --hard HEAD~1 # Undo last commit, delete changes too
git revert — The Safe Undo
Creates a new commit that reverses a previous one. History stays intact — the safest option when working on a shared repo.
git revert <commit-hash> # Undo a commit safely
Rule of thumb: if you've already pushed, use
revert. If you haven't,resetis fine.
Branches: Parallel Universes for Your Code
A branch is an independent line of development. You can create branches to work on features or fixes without touching the stable main branch.
git switch -c feature/dark-mode # Create and switch to new branch
git switch main # Switch back to main
git branch -d feature/dark-mode # Delete merged branch
git push origin feature/dark-mode # Push branch to remote
A common branch naming convention:
| Type | Prefix | Example |
|---|---|---|
| New feature | feature/ |
feature/dark-mode |
| Bug fix | fix/ |
fix/login-redirect |
| Urgent fix | hotfix/ |
hotfix/payment-crash |
Stash: The Pause Button for Unfinished Work
You're halfway through a feature. Code is messy, not ready to commit. Then your team lead says: "Can you quickly fix that bug on main?"
You can't switch branches with uncommitted changes. But you're not ready to commit either. The answer: stash it.
Analogy: You're drawing a picture but need to use the table for something else. You put everything in a drawer. Later, you open the drawer and continue exactly where you left off.
git stash # Save work temporarily
git switch fix/some-bug # Switch branches freely
# ... fix the bug, commit, come back ...
git switch feature/dark-mode
git stash pop # Restore your work
Adding a label makes it easier to manage multiple stashes:
git stash push -m "WIP: dark mode palette" # Named stash
git stash list # See all stashes
git stash pop # Restore latest
git stash apply stash@{1} # Restore specific (keep in list)
git stash drop stash@{1} # Remove specific
git stash -u # Include untracked (new) files
Worktree: No Stash Needed
Stash works well for quick interruptions. But if the other task is longer — or you simply don't want to touch your current work at all — Git Worktree is the cleaner solution.
Worktree lets you check out a second branch in a separate folder, without touching your current work:
# Create a new folder with a different branch checked out
git worktree add -b hotfix/login-bug ../my-project-hotfix origin/main
# Work in that folder, commit, push
cd ../my-project-hotfix
git add . && git commit -m "Fix login redirect"
git push origin hotfix/login-bug
# Remove the worktree when done
git worktree remove ../my-project-hotfix
Both folders share the same .git directory — one repo, two windows into it. GUI tools like GitHub Desktop, GitKraken, and Fork all recognize it as one repo.
| Stash | Worktree | |
|---|---|---|
| Current work | Saved and hidden | Completely untouched |
| Multiple branches at once | ❌ | ✅ |
| Ideal for | Quick interruptions | Longer parallel work |
Merge & Pull Requests: Bringing It All Together
When your feature is ready, you merge it back into main.
git switch main
git merge feature/dark-mode
On GitHub/GitLab, this is typically done through a Pull Request (PR) — a formal process where:
- You push your branch and open a PR
- Teammates review your code and leave feedback
- Once approved, it gets merged
Merge Options
| Method | What happens |
|---|---|
| Merge commit | All commits preserved + merge commit added |
| Squash and merge | All commits squashed into one |
| Rebase and merge | Commits replayed on top of main, no merge commit |
Handling Conflicts
When two branches edit the same line, Git can't auto-merge. You'll see:
<<<<<<< HEAD
const msg = "Hello!";
=======
const msg = "Hi there!";
>>>>>>> feature/dark-mode
Manually resolve it, then:
git add <file>
git commit
Rebase: A Cleaner Alternative to Merge
When you're the only one working on a branch, rebase is a great way to keep your branch up to date with main — without creating merge commits.
Instead of merging main into your branch (which adds noise), rebase replays your commits on top of the latest main:
git fetch origin
git rebase origin/main
# If conflicts arise during rebase:
git add <file>
git rebase --continue # move to next commit
git rebase --abort # cancel and go back
# Force push after rebase (required — history was rewritten)
git push origin feature/dark-mode --force-with-lease
⚠️ Never rebase a branch other people are also working on. Rebase rewrites history — it's only safe when you're the sole author of that branch.
| Situation | Use |
|---|---|
| Solo feature branch, want clean history | rebase |
| Shared branch or already merged | merge |
| Preparing a clean PR |
rebase first, then open PR |
Code Reviews: The Quality Gate
Before a PR is merged, someone reviews it. Good reviewers check for:
- Logical correctness
- Readability and naming
- Test coverage
- Complexity (is it simpler than it needs to be?)
- Style guideline compliance
Code reviews aren't just about catching mistakes — they're also how knowledge spreads through a team.
Fork & Clone: Contributing Without Access
Forking copies someone else's repo into your GitHub account. Cloning copies a repo to your local machine.
The typical open-source contribution flow:
# 1. Fork on GitHub (click the Fork button)
# 2. Clone your fork
git clone https://github.com/your-username/the-project.git
# 3. Add original repo as upstream
git remote add upstream https://github.com/original-owner/the-project.git
# 4. Create a branch, make changes, push
git switch -c fix/typo-readme
git add . && git commit -m "Fix typo in README"
git push origin fix/typo-readme
# 5. Open a Pull Request on GitHub
Keeping Your Fork Synced
git fetch upstream
git switch main
git merge upstream/main
git push origin main
Git GUI Apps: You Don't Have to Type Everything
Knowing the commands makes you a stronger developer — but you don't have to use the terminal every day. There's a whole ecosystem of GUI (Graphical User Interface) apps that let you commit, branch, merge, and stash by clicking buttons, with a visual map of your repo history.
Here are the most popular ones:
| App | Platform | Price | Best For |
|---|---|---|---|
| GitHub Desktop | Mac, Windows | Free | Beginners, GitHub users |
| GitLens (VS Code ext.) | All OS | Free / Paid | Devs living in VS Code/Cursor |
| GitKraken | Mac, Win, Linux | Free (limited) / Paid | Visual power users |
| Fork | Mac, Windows | Free trial / ~$50 | Speed + power balance |
| Sourcetree | Mac, Windows | Free | Atlassian/Bitbucket users |
GitHub Desktop is the simplest — made by GitHub, focused on the essentials.
GitLens is a VS Code extension that adds inline blame, visual commit graphs, and stash management right inside your editor.
GitKraken has a stunning commit graph and drag-and-drop merging.
Fork hits a great balance of speed and power.
Sourcetree (by Atlassian) is free and feature-rich, especially if you use Bitbucket.
Even if you use a GUI app daily, knowing the underlying commands helps you debug problems and work on servers where no GUI exists. Think of GUI apps as a productivity layer on top of your Git knowledge — not a replacement for it.
Summary
| Concept | In Short |
|---|---|
| Repository | Warehouse for your project files + history |
| Commit | A saved snapshot with a message |
| Checkout | Visit past commits temporarily |
| Reset | Erase commit history (use carefully) |
| Revert | Safely undo a commit |
| Branch | Independent line of development |
| Stash | Temporarily save unfinished work |
| Worktree | Work on two branches at once in separate folders |
| Merge | Combine branches |
| Rebase | Replay your commits on top of another branch (solo branches only) |
| Pull Request | Formal request to review and merge code |
| Fork | Copy someone else's repo to your account |
| Clone | Copy a repo to your local machine |
Git takes practice, but these concepts cover 90% of what you'll use day-to-day. Start small, commit often, and don't be afraid of making branches.
The more you use it, the more natural it feels.
One commit at a time. 🚀
Originally published as a series (Git for Everyone) at: What Is Git, Repository, and Commit | Traveling Through Time — Checkout, Reset, and Revert
| Branches, Stash, and Git Workflow | Merge, Pull Requests, and Code Reviews | Fork, Clone, and Open Source Collaboration | Git GUI Apps — You Don't Have to Use the Terminal
Top comments (0)