24 Oct 2026 · Developer workflow · 7 min read

Git and Version Control Basics

Version control keeps your work safe and your team in sync. These are the Git commands you will actually use.

Before version control, teams copied folders named project-final and project-final-v2. Git replaced that with a precise history of every change, who made it and why. Learning a small set of commands covers almost everything you will do day to day.

What a repository is

A repository is a project folder that Git tracks. It contains your files plus a hidden history of every committed change. You can create one from scratch or copy an existing one from a remote server.

The repository records snapshots rather than just the current state, so you can compare versions, undo mistakes and see how a file evolved over weeks or years.

Working tree, staging area and history

Git organises your work into three places. The working tree is the files as they are right now. The staging area holds the changes you have chosen for the next snapshot. The commit history is the permanent record once you save that snapshot.

Staging lets you commit a focused, reviewable change even when you have edited several unrelated files.

Starting out and committing

Turn a folder into a repository with git init, or copy a project from a server with git clone. From there the rhythm is always the same: check what changed, stage the change, then commit it with a clear message.

git init
git status
git add src/app.js
git commit -m "Add search filter to the notes list"

Writing messages that explain the intent, not just the file name, makes history readable months later.

Branching and switching

A branch is a movable pointer to a line of work. The default branch is often called main. You create a branch so experimental or in-progress work never disturbs the stable version.

git switch -c feature/dark-mode
# make changes...
git add .
git commit -m "Add dark mode toggle"

Switching branches swaps the files in your working tree to match that line of work, so you can jump between tasks without copying folders.

Merging and resolving conflicts

When a branch is ready, merge it back. If the same lines were changed in two branches, Git marks a conflict and asks you to choose. You edit the file to keep the correct lines, remove the conflict markers, then stage and commit the result.

Conflicts look alarming the first time but are usually small. Read both versions, decide what the code should be, and run your tests before committing the merge.

Remotes, push and pull

A remote is a shared copy of the repository hosted on a service like GitHub or GitLab. Pushing sends your commits there; pulling brings other people's commits to you.

git remote add origin https://example.com/team/project.git
git push -u origin main
git pull

Pulling regularly keeps your local copy close to the shared one, which keeps merges small and conflicts rare.

What a pull request is

A pull request is a request to merge one branch into another, opened on the hosting platform. It gives teammates a place to review the diff, comment and run automated checks before the change lands. It is a conversation wrapped around a merge, and it keeps the main branch trustworthy.

The everyday commands

You can go surprisingly far with a short list. Keep it handy and the rest will stick with practice.

git status              # what changed
git add <file>          # stage a change
git commit -m "msg"     # save a snapshot
git switch -c <name>    # start a branch
git pull                # get latest changes
git push                # share your commits
git log --oneline       # review history

Learn these seven well before reaching for advanced commands. They cover the safe, collaborative workflow that most projects rely on every day.

Back to all blogs