Git Repository Cheat Sheet: Essential Commands for Developers

Any developer who has worked on a team knows that modern software development is hard to imagine without a version control system. Git is the go-to tool for managing code — used by solo side projects and large distributed teams alike. Behind the apparent simplicity of commands like git add and git commit lies a logic that's worth understanding rather than just memorizing.

This article is a practical Git reference. It's written for beginners who are just getting familiar with version control, as well as for developers who need a quick reminder of a specific command. We'll cover how a repository is structured, which commands handle everyday tasks, and which ones come in handy in less common situations — from undoing a commit to working across several branches at once.

What Git and a Repository Actually Are: The Basics

Before diving into commands, it helps to get the terminology straight — otherwise the rest of this guide will read like instructions in an unfamiliar language.

Git is a distributed version control system (VCS) that tracks changes to project files and lets you return to any saved version. Unlike centralized systems such as SVN, every team member holds a full copy of the project's history, not just a snapshot of the current files.

A repository is the storage Git uses to keep the entire project history: files, their changes, branches, and metadata about every commit. A repository can be local, living on a developer's machine, or remote — hosted on a server, for example on GitHub, GitLab, or your own VPS.

A few concepts worth knowing before moving on:

• Commit — a recorded set of changes with a unique identifier and a description.
• Branch — an independent line of development that lets you work on different tasks in parallel.
• Working directory — the project folder on disk that a developer interacts with directly.
• Index, staging area — an intermediate zone where changes land before being committed.
• Remote — a copy of the repository on a server that local changes sync with.

Short list, but these five concepts form the basic model of how Git works. Next, let's look at how they interact in practice.

How Git Works: A Step-by-Step Process

The overall Git workflow looks roughly the same regardless of project size: initializing or cloning a repository, making changes, committing them, and syncing with a remote. Let's walk through each stage and the commands involved.

Initializing and Cloning

Work starts with one of two scenarios: creating a new repository or getting a copy of an existing one.

git init

creates a new local repository in the current folder.

git clone https://github.com/username/repository.git

copies an existing remote repository along with its entire history.

Tracking Changes

Once files are created or modified, Git needs to be told about the changes explicitly — nothing gets recorded automatically.

git status

shows which files have changed, are staged, or aren't tracked at all.

git add filename

stages a specific file; git add . stages every changed file in the current directory.

git diff

prints a line-by-line diff between the working directory and the last commit — useful for checking exactly what changed before staging it.

Committing Changes

git commit -m "description of changes"

saves the staged changes as a new point in the project's history. A commit message isn't a formality — six months from now, it's what will tell you why a change was made.

Syncing With a Remote Repository

git push origin main

sends local commits to the remote repository.

git pull origin main

fetches changes from the remote and immediately merges them into the current branch.

git fetch origin

downloads changes from the server without applying them automatically — useful when you want to review what changed before deciding whether to merge it.

Between them, these commands cover most day-to-day work. The table below rounds them up along with a few more you'll reach for slightly less often, but still regularly.

Advantages and Disadvantages of Git

Git isn't the only version control system out there, but it covers the needs of most teams — from small side projects to operating system development. It's worth weighing its strengths and weaknesses before relying on it as your only tool for managing code.

Strengths:

• Distributed architecture: every developer holds a full copy of the history, which lowers the risk of losing data if a server goes down.
• Fast local operations: commits, browsing history, and switching branches all happen without touching the network.
• Flexible branching: parallel work on different features doesn't get in the way of itself.
• Rich ecosystem: GitHub, GitLab, Bitbucket, and dozens of CI/CD integrations.

Weaknesses:

• Steep learning curve: the basics click quickly, but rebase, cherry-pick, and resolving merge conflicts take practice.
• Slower on large repositories: years of history and binary files add up and slow down cloning and history operations.
• Risk of data loss if used carelessly: force-push and a hard reset can wipe out someone else's work if you're not careful.

Limitations and Risks When Working With a Repository

Beyond Git's general downsides, there are risks that show up specifically in day-to-day repository work.

The first and most common is merge conflicts. They happen when two people change the same lines of a file on different branches. Git doesn't resolve these automatically — a developer has to manually decide which version to keep.

The second risk involves the project's history: commands like git rebase or git push --force rewrite commit history. If a branch has already been shared with the team, that kind of rewrite can confuse teammates and cause their work to be lost the next time they sync.

The third issue is repository size. Storing large binary files — archives, video, datasets — directly in Git gradually slows down cloning and history operations. Extensions like Git LFS, Large File Storage, exist for this, but they need to be set up in advance, before the repository has already grown to several gigabytes.

Finally, security matters: passwords, API keys, or .env files committed by accident stay in the repository's history even after the file is removed in a later commit. Cleaning that up requires a separate step — for example, with the git filter-repo tool.

Practical Git Scenarios

Let's walk through a few situations developers run into regularly — from starting a new project to recovering from a mistake.

Scenario 1. Starting a New Project

A team launches a new service and deploys it on a dedicated server — for example, a VPS from Serverspace, where it's convenient to keep both the working environment and a Git repository for the team's internal needs. Once the project folder is ready, the repository is initialized and connected to a remote:

git init
git remote add origin https://github.com/username/project.git
git add .
git commit -m "Initial commit"
git push -u origin main

The -u flag links the local branch to the remote one, so afterward a plain git push is enough — no need to specify origin and the branch name.

Scenario 2. Parallel Development of Several Features

When several people work on a project, each feature gets its own branch. That keeps people out of each other's way and lets changes be tested in isolation:

git checkout -b feature/new-auth
git add .
git commit -m "Add OAuth authentication"
git push origin feature/new-auth

Once the work is done, the branch gets merged into main through a pull request or directly with git merge.

git merge vs. git rebase: What's the Difference

At first glance, both commands solve the same problem — combining changes from one branch into another. The result in the project's history, though, looks quite different.

Scenario 3. Undoing a Bad Commit

Mistakes happen to everyone: the wrong file gets committed, a debug line stays in, a commit message is wrong. If the commit hasn't been pushed yet, it's safe to undo:

git reset --soft HEAD~1

This undoes the last commit but keeps the changes staged — you can fix them and commit again. If the commit has already been pushed to a shared repository, git revert is the better option: it creates a new commit that reverses the changes without rewriting history.

Scenario 4. Temporarily Saving Unfinished Work

Sometimes you need to switch to another task urgently, but your current changes aren't ready to commit. That's what stash is for:

git stash
git checkout other-branch
git checkout feature/new-auth
git stash pop

Changes are set aside temporarily, without becoming part of any commit, then restored to the working directory later.

Scenario 5. Deploying a Project to a Server via Git

When deploying to your own server, the repository is often cloned directly onto the machine that will run the application. On a VPS, the process is the same as on a local machine: install Git, clone the repository, and pull future updates with git pull. This approach suits small and medium projects well: complex CI/CD infrastructure isn't necessary here — what matters more is being able to spin up an environment quickly on a rented server, whether that's a staging box or production for an internal company service.

Where to Host a Remote Repository

The choice of platform for a remote repository depends on project scale and privacy requirements:

For a self-hosted repository on your own server — through GitLab CE, for example — you'll need a machine with enough resources. A VPS server from Serverspace fits that job well: its configuration is easy to size to a specific repository and team's workload, and full server access makes setup independent of third-party platforms.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

Conclusion

Git is a tool that's quick to pick up at a basic level but only really clicks with practice — working with branches, resolving conflicts, recovering from mistakes. The commands in this cheat sheet cover most everyday tasks; from there, documentation and hands-on experience fill in the rest. Git forgives almost any mistake, as long as you know which command fixes it.

If a repository does more than just store code — say, it's part of a project's infrastructure through deploy hooks or a self-hosted GitLab instance — it's worth thinking ahead about where the server will live. A VPS server from Serverspace works well for that: resources can be sized to a specific project's load, and full server access makes it easy to set up Git hooks, CI agents, and other related services. For more on infrastructure and developer tooling, check out the Serverspace blog.

Frequently Asked Questions (FAQ)