Git Basics: A Beginner's Guide to the Commands You'll Actually Use

What Git is and why it exists

Git is a version-control system: it tracks changes to your files over time, so you can see what changed, when, and by whom, and roll back if something breaks. It also lets multiple people work on the same project without overwriting each other. Created by Linus Torvalds (of Linux fame) in 2005, Git is now the near-universal standard, and it is what powers platforms like GitHub, GitLab, and Codeberg. Learning it is non-negotiable for anyone writing code.

The mental model: four places your code lives

Git clicks once you picture four areas. The working directory is your actual files on disk. The staging area (or 'index') is a holding pen for changes you have marked to save next. The local repository is your committed history on your machine. The remote repository is the shared copy on a server (like GitHub). The everyday flow is: edit files (working directory), stage the ones you want (add), save a snapshot (commit) to your local repo, then upload (push) to the remote. Grasp this and the commands stop feeling random.

Getting started: clone or init

Two ways to begin. To work on an existing project, copy it with: git clone <url> which downloads the whole repo and its history. To start version-controlling a new project, go into its folder and run: git init which creates the hidden .git directory that tracks everything. First time on a machine, set your identity so commits are attributed: git config --global user.name "Your Name" and git config --global user.email "[email protected]".

The daily loop: status, add, commit

These three are your bread and butter. git status shows what has changed and what is staged, run it constantly, it is your compass. git add <file> stages a specific file (or git add . stages everything) for the next snapshot. git commit -m "Describe what you changed" saves the staged changes to history with a message. Good commit messages are short, present-tense summaries ('Add login validation'), your future self will thank you. Use git log to view the history you have built.

Working with a remote: push and pull

To share your work and collaborate, you sync with the remote. git push uploads your local commits to the server (e.g. GitHub). git pull downloads and merges changes others have made, do this before you start working to stay current. If you cloned a repo, the remote is already set up; if you ran git init, you link one with git remote add origin <url> and then git push -u origin main the first time. That is the complete round-trip most developers do dozens of times a day.

Branches: work without breaking things

Branches let you develop a feature or fix in isolation without touching the stable code. git branch <name> creates one; git checkout <name> (or the newer git switch <name>) moves onto it; git checkout -b <name> does both at once. When your work is ready, you merge it back: switch to the main branch and run git merge <name>, or, on a team, open a pull request on GitHub so others can review before merging. Branching is what makes safe, parallel collaboration possible.

The commands worth memorizing

You can go a long way with just these: clone/init to start, status to check, add to stage, commit to save, push/pull to sync, branch/switch/merge to work in parallel, and log to look back. When you get stuck (everyone does), git's built-in help and the massive body of Stack Overflow answers will rescue you, and for the scary 'I broke everything' moments, git reflog can often recover work you thought was lost. Start with this core set and expand as you need to.

Related on Skillo

See also: What is Docker? Containers explained, JetBrains unveils JetBrains Air agentic dev system.

Sources

• Git official documentation and reference (git-scm.com)

Published date reflects the original event date (2026-08-12). This article is original Skillo editorial written from the sources above; facts were verified in September 2026.