Git from zero to deploy: the no-BS guide for modern devs
Learn Git the right way, from your first commit to your first deploy, without being a hostage to GUI tools.
✨TL;DR / Executive Summary
Learn Git the right way, from your first commit to your first deploy, without being a hostage to GUI tools.
💡 TL;DR (Too Long; Didn't Read)
Git is a time machine for your code. In this practical guide you learn: creating your first repository, making purposeful commits, using branches safely, undoing mistakes without panic, and finally preparing everything for your first deploy. No academic theory, no GUI tools, just what actually works.
If you're still afraid of git, it's not because you're "bad". It's because someone probably taught you the wrong way.
In this article you'll learn Git from zero to your first deploy, the way devs actually use it daily — no fluff, no empty theory, and with copy-paste friendly examples.
We'll cover:
- What Git really is (without academic jargon)
- Your first commits
- Branches done right
- Going back in time without nuking everything
- Laying the foundations for a sane deploy workflow
1. What Git really is (and why you should care)
Forget the phrase "Git is a distributed version control system".
In practice, Git is:
A time machine for your code, that lets you and your team work together without constantly stepping on each other's toes.
With Git you can:
- See what changed, when, and by whom
- Roll back file or project versions
- Work on multiple features at the same time using branches
- Test risky ideas without destroying the stable code
People who master Git:
- Unblock the team when things break
- Recover "lost" work
- Avoid deleting each other's changes
It looks like a technical detail, but Git directly affects how senior you look.
2. Getting started: your first repository
Let's create a local repo and make your first commit.
mkdir my-git-project
cd my-git-project
git initThis creates a .git folder where the magic happens.
Now create a simple file:
echo "console.log('Hello Git!')" > index.jsCheck repo status:
git statusYou'll see something like:
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.jsAdding files and making your first commit
- Add the file to the staging area:
git add index.js- Register the commit:
git commit -m "feat: first commit of the project"- Check history:
git log --onelineCongrats, you just created the first point in your time machine.
3. Small commits, big you
If you store everything in a single commit, you're using Git like a glorified USB stick.
Best practices:
- Small, focused commits
- Each commit answers: "what was done?" and, when needed, "why?"
- Skip
"fix","test","final changes"as messages
Bad example:
git commit -m "final adjustments"Good example:
git commit -m "fix: correct discount calculation on checkout screen"Important reminder:
Git is not backup. Git is decision history.
4. Using .gitignore so your team doesn't roast you
Every dev has accidentally committed something they shouldn't: node_modules, .env, massive log files…
Use a .gitignore at the project root to tell Git what to ignore:
node_modules/
dist/
.env
*.log
.idea/
.vscode/After that, Git will pretend these files don't exist.
Pro tip: generate ready-made .gitignore files for your stack using gitignore.io or GitHub presets.
5. Branches: stop living dangerously on main
If you do everything directly on main, you're not fast — you're reckless.
Healthy workflow:
mainalways stable- No crazy experiments directly on
main - Each feature/bugfix on its own branch
Creating a branch:
git checkout -b feature/login-screenGoing back to main:
git checkout mainMerging your feature into main (simple merge):
git checkout main
git pull origin main # update first
# after your feature is reviewed and approved
git merge feature/login-screenBranches are cheap. Broken production is expensive.
6. Going back in time without wrecking everything
See what changed before committing
Always review before registering a commit:
git diff # everything that changed
git diff --staged # only what you added with git addThis helps avoid:
- Shipping stray
console.log - Pushing
.envto production - Committing temporary files
Reverting a single file
Newer Git:
git restore path/to/fileOlder Git:
git checkout HEAD -- path/to/fileThis reverts just that file to the last commit.
7. Working with remotes (GitHub, GitLab, etc.)
Let's connect your local repo to a remote (e.g. GitHub):
- Create an empty repo on GitHub
- Copy the URL (HTTPS or SSH)
- In your local project, run:
git remote add origin [email protected]:user/my-git-project.git
git branch -M main
git push -u origin mainNow your main is synced with the remote.
Whenever you make new changes:
git add .
git commit -m "feat: add profile screen"
git push8. Stash: quick pause without making a mess
In the middle of something and someone asks you to fix an urgent bug?
Instead of committing garbage just to "save":
git stash # save your local changes
# fix the bug
git stash pop # bring your work backIt's like an organized CTRL+Z.
9. Daily Git checklist
If you just do this, you're already above average:
- Use
git statusandgit diffbefore every commit - Have a decent
.gitignorefrom day one - Never work directly on
mainin serious projects - Use branches per feature/bugfix
- Write commit messages that actually mean something
- Review before hitting
git push
10. Next steps: becoming actually dangerous (in a good way)
To move past the basics and become "the Git person" on your team, study:
git rebase(for cleaner history)git revert(to undo without hiding)git reflog(to recover "lost" work)git bisect(to find which commit broke everything)- Hooks and aliases (to automate best practices)
In the next articles, we'll go deeper into these topics.
Meanwhile, if this article helped you:
- Save it to revisit later
- Share it with that friend who's still scared of Git
- And keep following the #gittips ;)