Page 1 of 2
Imagine you're writing a document and you save versions as essay.doc, essay_final.doc, essay_final_v2.doc, essay_final_ACTUALLY_FINAL.doc. Now imagine two people doing that on the same project, emailing files back and forth, trying to remember whose changes are newest. This is roughly how software development worked before version control, and it was exactly as painful as it sounds - lost work, overwritten changes, and no way to answer "what did this file look like last week, and who changed it?"
Git is a version control system: a tool that tracks every change ever made to a set of files, lets multiple people work on them at once without stepping on each other, and gives you a complete, searchable history of how the project got to where it is. Every change is recorded as a commit - a snapshot with a message explaining what changed and why.
Git is also distributed, which is a specific and important design choice: every person who clones a project gets the entire history on their own machine, not just the latest files. You can commit, browse history, and create branches with no network connection at all. You only need the network when you want to sync with other people.
This trips up nearly every beginner at some point, so it's worth understanding early: a file in a Git project can sit in one of three places, and moving it between them is most of what you do day to day.
The working directory is just your normal files on disk - what you see in your editor. The staging area (also called the index) is a holding area where you build up exactly what you want your next commit to contain. The repository (the .git folder) is where committed snapshots permanently live.
git add file.txt # working directory -> staging area
git commit # staging area -> repository (creates a snapshot)
The staging area is the part people find confusing coming from other tools: you don't commit "your changes," you commit "whatever you've staged." That's a feature, not friction - it means you can edit five files, but stage and commit only two of them as one focused change, saving the rest for later.
To start tracking a project with Git, you turn a plain folder into a repository:
git init # creates a hidden .git folder that stores all history
From there, the basic loop is: edit files, stage the ones you want to save, commit them.
git add index.html # stage a specific file
git add . # stage everything changed in the current directory
git commit -m "Add homepage" # commit staged changes with a message
Commit messages matter more than beginners expect - "fix stuff" tells future-you nothing, while "Fix off-by-one error in pagination" tells you exactly what problem existed and that it's now solved. You'll thank yourself in six months.
Two commands answer almost every "what's going on?" question in Git.
git status # what's changed, what's staged, what's untracked
git log # the history of commits, newest first
git status is safe to run constantly - it never changes anything, it just reports. Run it before and after almost every other command until checking becomes automatic.
git log --oneline # one line per commit: short hash + message, easy to scan
Each commit gets a unique identifier called a hash (like a3f9c2d) - a fingerprint of that exact snapshot. You'll use these hashes to refer to specific points in history later on.
Most of the time you don't start a project with git init - you copy an existing one. That's cloning:
git clone https://github.com/someuser/somerepo.git
This downloads the full project and its entire history onto your machine. The location you cloned from is remembered as a remote - by default named origin.
git remote -v # show the remote(s) this repo is connected to
A remote isn't magic - it's just another copy of the repository, usually hosted somewhere like GitHub or GitLab, that you and your collaborators sync with.
Once you've committed locally, your changes exist only on your machine until you send them somewhere. That's pushing. Getting other people's changes is pulling.
git push origin main # send your local commits on "main" to the remote
git pull origin main # fetch and merge remote commits into your local branch
A very common beginner confusion: committing does not automatically share your work with anyone. You commit locally, then push explicitly. Likewise, other people's commits don't appear on your machine until you pull. Git never syncs anything without you asking it to.
A branch is an independent line of development - a way to work on something (a new feature, an experiment) without touching the stable version of the project. The default branch is usually called main.
git branch feature-login # create a new branch
git checkout feature-login # switch to it
git switch feature-login # newer, clearer equivalent to checkout
git checkout -b feature-login # create and switch in one step
Branches are cheap and fast in Git - creating one doesn't copy any files, it just creates a new named pointer to a commit. This is why Git culture encourages branching constantly: for every feature, every bug fix, every experiment, rather than working directly on main.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.