Git in 15 minutes — Guides — Arsenal qvib.pro

What for: stop losing versions of your code — init → commit → push → branches → rollback. Only the commands you actually need every day.

Git is a "time machine" for code: it records versions, lets you roll back and run parallel lines of work (branches). It works with any cloud (GitHub / GitLab / Gitea / Bitbucket). The commands below are verified against the official git-scm.com.

🧭 The big picture

Without Git you live in fear: "if I touch this, I'll break what already worked". With Git every recorded state (a commit) is a save point in a game — you can return to any of them. What you get: a history of every version, an "undo" button, the ability to run several lines of work at once (branches), and a way to move code between your machine, a server and your teammates through the cloud (push/pull).

The three "places" your code lives in are the whole essence of Git:

Working directory — the files you're editing right now.
Index (staging) — the "basket" of what will go into the next commit (git add puts things here).
History (repository) — recorded commits (git commit writes here).

💡 Install Git if you haven't: macOS — brew install git (or the Xcode Command Line Tools), Windows — the installer from git-scm.com (Git Bash), Ubuntu — sudo apt install git. Check: git --version → it should print a version.

Step 1. Introduce yourself once (name/email in commits)

What we're doing: telling Git who the author of the commits is. Without this the first commit will complain.

git config --global user.name "Anton Laskov"
git config --global user.email "you@mail.com"
git config --global init.defaultBranch main   # so a new branch is called main, not master

How to tell it worked: git config --global --list shows your user.name and user.email.

Common mistakes:

Set it without --global — the setting applies only to the current repository (sometimes that's exactly what you want, but for a start set it globally).
The email isn't the one on GitHub → your commits won't be linked to your profile (no avatar). Use the same email as on your account.

Step 2. Create a repository (once, in the project folder)

What we're doing: turning an ordinary folder into a Git repository and making the first commit.

cd path/to/project
git init                                   # creates a hidden .git/ folder
git add .                                  # put all files into the index
git commit -m "First commit: project start"

How to tell it worked: after git init — the line Initialized empty Git repository in .../.git/. After git commit — 1 file(s) changed (or however many files you have).

Now connect the cloud. Create an empty repository on GitHub (no README, so there's no conflict) → connect it and push:

git remote add origin https://github.com/YOUR_USERNAME/my-project.git
git branch -M main                         # name the current branch main
git push -u origin main                    # push and remember the link (-u)

How to tell it worked: refresh the repository page on GitHub in your browser — your files are there.

Common mistakes:

fatal: not a git repository — you're in the wrong folder or forgot git init.
remote origin already exists — origin is already set; to change the address: git remote set-url origin <URL>.
Updates were rejected on the first push — GitHub already has a commit (an auto-generated README, for example). Fix: git pull --rebase origin main, then git push again.
It asks for a login/password and won't let you in — GitHub stopped accepting passwords over HTTPS long ago. Use a Personal Access Token instead of a password (Settings → Developer settings → Tokens) or an SSH key.

Step 3. The minimum daily set

What we're doing: the basic loop — "looked → staged → recorded → pushed".

git status                 # what changed (your best friend — check it often)
git add .                  # stage ALL changes (or git add file.js — one at a time)
git commit -m "a clear description of what you did"
git push                   # send it to the cloud
git pull                   # fetch changes (from another device / from teammates)
git log --oneline          # short commit history (q to quit)

How to tell it worked: after commit — git status says nothing to commit, working tree clean. After push — git status says Your branch is up to date with origin/main.

Common mistakes:

A commit without -m opens the vim text editor — which scares beginners. To exit without changes: press Esc, type :q!, Enter. From now on always write -m "...".
Commit messages like "fix", "update", "one more time" — a week later you won't remember what they were. Be specific: "Added validation to the login form".
Forgot git add before the commit → the commit is empty or missing the file you needed. First add, then commit (or git commit -a — commits already-tracked modified files, but NOT new ones).

Step 4. Branches (solo and in a team)

What we're doing: isolating each task in its own branch so you don't break stable code.

main — the stable line (what's "in production"). We don't write here directly.
feature/<task> — a separate branch for each feature/fix.

git switch -c feature/login    # create a branch and move into it (older synonym: git checkout -b)
# ...you edit the code...
git add . && git commit -m "Login by email"
git push -u origin feature/login
# done and tested → go back to main and merge:
git switch main
git merge feature/login

How to tell it worked: git branch lists the branches, and the asterisk * shows which one you're on. After the merge your changes are in main.

Common mistakes:

You start editing without switching → the commit lands in the wrong branch. Check git branch before you start.
A merge conflict — two changes to the same line. Git marks the spots with <<<<<<<, =======, >>>>>>>; pick the right version, delete the markers, then git add file and git commit. Don't panic — this is a normal part of the job (see the rescue prompt).

Step 5. Rolling back — when you break something

What we're doing: taking the code back. The key is understanding WHAT exactly you're undoing.

git restore <file>          # return one file to the last commit (unsaved edits are gone)
git restore --staged <file> # unstage a file from git add (the edits themselves stay)
git restore .               # undo ALL unsaved edits (careful!)
git revert <hash>           # safely undo an existing commit — with a NEW commit
git log --oneline           # grab the short hash of the commit you need (e.g. a5eec9d)

How to tell it worked: git status shows the file is back to its original state. After a revert, a new "Revert ..." commit appears in git log.

Common mistakes:

Mixing up restore (undo uncommitted edits) and revert (undo a commit that already exists). Check git status/git log first.
git restore . wipes unsaved work with no trash bin. If you're not sure — run git stash first (it hides your edits; bring them back with git stash pop).

🧠 For the senior

reset vs revert: revert is safe for published history (a new commit); reset --soft/--mixed/--hard rewrites history — only for local commits you haven't pushed yet.
Recovering "lost" work: almost everything is fixable through git reflog — it remembers where HEAD has been, even after a "hard" reset. You can resurrect a deleted branch from the reflog by hash.
Clean history: git rebase -i for squash/fixup before a PR, git commit --amend to fix the last commit (only before pushing). Conventional Commits + an automatic CHANGELOG.
Hygiene: a protected main (PR + review + required checks), git switch instead of the overloaded checkout, a .gitignore for your stack (see github/gitignore), hooks via pre-commit (linting/secret scanning before the commit).
Large files: don't put binaries/datasets in git — use Git LFS or external storage.

⚠️ Warnings (irreversible / security)

Secrets (passwords/keys/tokens) — NEVER in git. Only in .env, and .env must be in .gitignore. A key leaked into a public repository = a breach, and removing it from history after the fact is painful (you need git filter-repo + key rotation). Better not to let it happen.
git reset --hard and git push --force are irreversible and can wipe work (yours or your teammates'). Make a backup branch before them: git branch backup (an instant "snapshot" of the current state).
git clean -fd deletes untracked files from disk with no trash bin. Run git clean -nd first (the -n flag means "show what would be deleted, but don't delete").

🆘 Rescue prompt

I'm new to git, explain in plain words and step by step.
WHAT I WANTED TO DO: <e.g. undo the last commit / merge a branch / restore a deleted file>
HERE'S MY STATE:
<paste the output of `git status`>
<paste the output of `git log --oneline -5`>
HERE'S THE ERROR / WHAT I SEE: <error text>

What to do:
1) Explain what happened and why.
2) Give me the exact commands to get back to how it was, losing NOTHING.
3) If a command is irreversible (reset --hard, push --force, clean) — warn me and offer a backup branch first.
4) At the end — how to verify everything is back in place.

💎 Depth and value

Git is insurance against fear. You stop being afraid to experiment: any change can be rolled back. That changes how you work — you try things more boldly and learn faster.
It's your ticket into team development. The entire world of code (GitHub, open source, any IT team) runs on Git and Pull Requests. Without it you can't join a project; with it you're immediately one of the crew.
The foundation for everything else. Deploying to a server, CI/CD, vibe coding with an AI agent, moving a project between machines — all of it rests on Git. Fifteen minutes here pay off for years.