# A beginner’s guide to version control with Git

> Version control tracks changes to your code; this guide shows beginners how to start using Git, from initial setup to avoiding a common .gitignore mistake.

- URL: https://cmskite.com/b/my-blog/beginner-guide-version-control
- Blog: DEV
- Author: DEV
- Published: 2026-10-31
- Category: Guides
- Tags: git, version-control, beginner

In this beginner’s guide to version control, we’ll explain what version control is, why Git is the go‑to tool for developers, and walk you through the exact steps to set up your first repository, make your first commit, and avoid a common pitfall many newcomers miss.

## What is version control and why it matters

Version control is a system that records every change to a set of files over time. It lets you revert to previous versions, compare changes, and collaborate without overwriting each other’s work. Git, created by Linus Torvalds in 2005, has become the industry standard because it’s fast, distributed, and free. When you commit changes, Git stores a snapshot, not just a diff, making roll‑backs reliable. For beginners, understanding that each commit is a safe checkpoint reduces the fear of breaking things. If you want more context about why we started this blog, see our welcome post at [https://cmskite.com/b/my-blog/welcome-to-the-dev-blog](https://cmskite.com/b/my-blog/welcome-to-the-dev-blog).

## Beginner’s guide to version control: core concepts

The core concepts you need to grasp are repository, commit, branch, and remote. A **repository** (repo) is the container for all your project files and history. A **commit** records a snapshot with a message describing what changed. **Branches** let you work on separate lines of development without affecting the main codebase; the default branch is usually called `main` or `master`. **Remotes** are versions of your repo hosted elsewhere, like GitHub, enabling collaboration. Understanding these four pillars lets you reason about any Git workflow, from solo projects to large team environments.

## Step‑by‑step: initializing a Git repo and making your first commit

1. Open a terminal and navigate to your project folder.
2. Run `git init` – this creates a hidden `.git` folder that tracks changes.
3. Create a file, e.g., `README.md`, and add some content.
4. Stage the file with `git add README.md` (or `git add .` to stage everything).
5. Commit using `git commit -m "Initial commit"`. Git now records the first snapshot.
6. To view history, type `git log` – you’ll see the commit hash, author, date, and message.
7. If you have a remote, add it with `git remote add origin https://github.com/yourname/repo.git` and push with `git push -u origin main`. This concrete workflow eliminates guesswork and gives you a reproducible pattern for every new project.

## The often‑overlooked step: creating a proper .gitignore before your first commit

A `.gitignore` file tells Git which files or patterns to ignore. Skipping this step can flood your repo with build artefacts, IDE settings, or secret keys. Create the file **before** your first `git add`:

```
# Example .gitignore for a Node.js project
node_modules/
.env
.DS_Store
```

Add it with `git add .gitignore` and commit. This ensures unwanted files never enter the history, keeping the repository clean and reducing future merge conflicts. Many beginners forget this, only to spend hours cleaning large binary files from the repo later.

## Common mistakes and how to fix them

- **Committing large binaries:** Use Git LFS or keep binaries out of the repo. If already committed, run `git filter‑repo` to rewrite history.
- **Forgetting to pull before pushing:** Run `git pull --rebase` to incorporate others’ changes and avoid unnecessary merge commits.
- **Writing vague commit messages:** A good message follows the pattern `type(scope): short description`. Example: `feat(auth): add login endpoint`.
- **Accidentally committing sensitive data:** If you push a password, revoke it immediately and purge the commit using `git filter‑repo --invert-paths --path credentials.txt`. By recognizing these pitfalls early, you’ll maintain a healthier repository and smoother collaboration.

With these fundamentals in place, you’re ready to explore more advanced Git features like rebasing, cherry‑picking, and submodules. Happy coding!

[Add your call-to-action here]