DEV Community

Cover image for Git for Beginners: A Complete Practical Guide to Version Control
Benjamin Tetteh
Benjamin Tetteh

Posted on

Git for Beginners: A Complete Practical Guide to Version Control

#git #webdev #tutorial #beginners

Whether you're writing your first line of code, learning DevOps, cybersecurity, cloud, data, or simply revising your notes — this guide will help you understand Git from the ground up.

Introduction

If you are new to tech, one tool you will meet again and again is Git.

At first, Git can feel confusing because it introduces terms like commits, branches, staging, pushing, pulling, merging, and remote repositories.

But once you understand the basics, Git becomes one of the most useful tools in your workflow. It helps you track changes, collaborate with others, recover from mistakes, and manage your projects professionally.

This article is written for beginners and for anyone who wants a clear revision guide.

Table of Contents

  1. What is Git?
  2. Why Git Matters
  3. Git vs GitHub
  4. Key Git Concepts
  5. Installing Git
  6. Configuring Git
  7. Creating Your First Repository
  8. The Basic Git Workflow
  9. Working with Branches
  10. Merging and Rebasing
  11. Working with Remote Repositories
  12. Understanding git push origin main
  13. The .gitignore File
  14. Git Security: Do Not Commit Secrets
  15. Undoing Mistakes
  16. A Simple Daily Git Workflow
  17. What Is a Pull Request?
  18. Useful Git Commands Cheat Sheet
  19. Common Beginner Mistakes
  20. Next Steps

1. What is Git?

Git is a distributed version control system — a tool that tracks changes to your files over time so you can save different versions of your project and return to them when needed.

Think of Git like a detailed save system for your project. Without it, you may end up with files like:

project_final.js
project_final_v2.js
project_final_real_final.js
project_ACTUALLY_final.js
Enter fullscreen mode Exit fullscreen mode

Git helps you avoid that mess by keeping a clean history of every change.

Git was created by Linus Torvalds in 2005 — the same person who created the Linux kernel. Today, it is one of the most widely used tools in software development and modern technology work.

2. Why Git Matters

Git is important because it gives you:

History — See what changed, when it changed, and who made the change.

Collaboration — Multiple people can work on the same project without overwriting each other's work.

Backup — Push your work to platforms like GitHub or GitLab so it is not only stored on your computer.

Experimentation — Create a separate branch to test a new idea without breaking your main project.

Accountability — Understand why a change was made, not just what changed.

Whether you are a solo developer, DevOps engineer, cloud engineer, cybersecurity analyst, or part of a large engineering team, Git is an essential skill.

3. Git vs GitHub

Many beginners confuse Git and GitHub. They are related, but they are not the same thing.

Git is the tool installed on your computer. It tracks changes in your project locally.

GitHub is an online platform where you can store Git repositories, collaborate with others, and share your code publicly or privately.

A helpful way to think about it:

Git is the tool that tracks your project history. GitHub is the online home where you can upload and collaborate on that project.

Other platforms similar to GitHub include GitLab, Bitbucket, and Azure DevOps.

4. Key Git Concepts

Before using Git commands, it helps to understand the vocabulary.

Term Meaning
Repository A project folder tracked by Git
Commit A saved snapshot of your changes
Branch A separate line of development
Merge Combining changes from one branch into another
Remote A version of your repository hosted online
Clone Downloading a remote repository to your computer
Push Uploading your local commits to a remote repository
Pull Downloading remote changes into your local repository
Staging Area A holding area where you prepare changes before committing
HEAD A pointer to your current commit or branch

5. Installing Git

To check if Git is already installed, open your terminal and run:

git --version
# Example output: git version 2.43.0
Enter fullscreen mode Exit fullscreen mode

macOS

Git is often pre-installed on macOS. You can also install it via Homebrew:

brew install git
Enter fullscreen mode Exit fullscreen mode

Windows

Download the installer from git-scm.com. The installer also includes Git Bash, a terminal you can use to run Git commands.

Linux (Ubuntu/Debian) 

sudo apt update
sudo apt install git
Enter fullscreen mode Exit fullscreen mode

6. Configuring Git

Before making your first commit, tell Git who you are. This information is attached to every commit you make.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Enter fullscreen mode Exit fullscreen mode

To check your configuration:

git config --global --list
Enter fullscreen mode Exit fullscreen mode

You can also set your preferred text editor. For VS Code:

git config --global core.editor "code --wait"
Enter fullscreen mode Exit fullscreen mode

7. Creating Your First Repository

There are two common ways to start working with Git.

Option 1: Start a New Project 

mkdir my-first-git-project
cd my-first-git-project
git init
Enter fullscreen mode Exit fullscreen mode

git init creates a hidden .git folder inside your project. That folder stores all of Git's tracking information — do not delete it unless you intentionally want to remove Git tracking from the project.

Option 2: Clone an Existing Repository

If a project already exists on GitHub or another platform:

git clone https://github.com/username/repository-name.git
cd repository-name
Enter fullscreen mode Exit fullscreen mode

8. The Basic Git Workflow

The core Git workflow has three stages:

Working Directory  →  Staging Area  →  Repository
   (edit files)        (git add)        (git commit)
Enter fullscreen mode Exit fullscreen mode

Step 1: Make changes

Create, edit, or delete files in your project as normal.

Step 2: Check the status 

git status
Enter fullscreen mode Exit fullscreen mode

This shows which files have changed, which are untracked, and which are staged and ready to commit.

Step 3: Stage your changes 

# Stage a specific file
git add filename.txt

# Stage all changes at once
git add .
Enter fullscreen mode Exit fullscreen mode

Staging lets you choose exactly which changes to include in your next commit.

Step 4: Commit your changes 

git commit -m "Add README file"
Enter fullscreen mode Exit fullscreen mode

A commit is a saved checkpoint. Write clear, specific messages so your history is useful later.

Good commit messages:

git commit -m "Add login page"
git commit -m "Fix broken navigation link"
git commit -m "Update project documentation"
Enter fullscreen mode Exit fullscreen mode

Avoid vague messages like "stuff", "changes", or "update".

Step 5: View your history 

git log

# For a cleaner, one-line view
git log --oneline
Enter fullscreen mode Exit fullscreen mode

9. Working with Branches

Branches allow you to work on features, bug fixes, or experiments without affecting your main project.

main:     A --- B --- C
                      \
feature:               D --- E
Enter fullscreen mode Exit fullscreen mode

The main branch holds the stable version of your project. The feature branch holds work in progress, completely isolated.

Create and switch to a branch 

# Create a branch
git branch feature/add-login

# Switch to it
git checkout feature/add-login

# Or create and switch in one step
git checkout -b feature/add-login

# With newer Git versions (2.23+)
git switch -c feature/add-login
Enter fullscreen mode Exit fullscreen mode

List branches 

git branch        # local branches only
git branch -a     # local and remote branches
Enter fullscreen mode Exit fullscreen mode

Delete a branch after merging 

git branch -d feature/add-login
Enter fullscreen mode Exit fullscreen mode

10. Merging and Rebasing

Once your branch is ready, you need to bring those changes back into main.

Merging

Switch to the branch you want to merge into, then merge:

git switch main
git merge feature/add-login
Enter fullscreen mode Exit fullscreen mode

Handling Merge Conflicts

A merge conflict happens when Git cannot automatically combine changes — for example, when two people edit the same line in the same file. Git will mark the conflicting section:

<<<<<<< HEAD
This is the version from main
=======
This is the version from your feature branch
>>>>>>> feature/add-login
Enter fullscreen mode Exit fullscreen mode

To resolve it:

  1. Open the file and choose the correct final version
  2. Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
  3. Stage the resolved file
  4. Commit the result 
git add filename.txt
git commit -m "Resolve merge conflict"
Enter fullscreen mode Exit fullscreen mode

Merge conflicts are normal. They are not a sign that you have done something wrong.

Rebasing

Rebasing is an alternative to merging that replays your branch's commits on top of another branch, producing a cleaner, linear history.

git switch feature/add-login
git rebase main
Enter fullscreen mode Exit fullscreen mode

As a beginner, do not worry about mastering rebase immediately. Also avoid rebasing branches that other people are already working on, since it rewrites commit history and can cause problems for collaborators.

11. Working with Remote Repositories

A remote repository is an online version of your project, hosted on GitHub, GitLab, Bitbucket, Azure DevOps, or similar platforms.

Connect your local project to a remote 

git remote add origin https://github.com/yourusername/your-repo.git
Enter fullscreen mode Exit fullscreen mode

Check your remotes:

git remote -v
Enter fullscreen mode Exit fullscreen mode

Push your code 

# First push
git push -u origin main

# Subsequent pushes
git push
Enter fullscreen mode Exit fullscreen mode

Pull and fetch 

# Download and apply remote changes to your current branch
git pull

# Download remote updates without applying them
git fetch
Enter fullscreen mode Exit fullscreen mode

Think of it this way: git fetch checks what is new online. git pull checks what is new and brings it into your current branch.

12. Understanding git push origin main

Many beginners see this command and wonder what each part means.

git push origin main
Enter fullscreen mode Exit fullscreen mode

Here is the breakdown:

git push — upload your local commits to a remote repository.

origin — the name of the remote. By default, Git uses origin when you clone a repo or add a remote, but it is just a name, not something special. You could name it anything:

git remote add github https://github.com/yourusername/your-repo.git
git push github main
Enter fullscreen mode Exit fullscreen mode

main — the branch you are pushing. Most modern repos use main as the default, but some use master, dev, or staging.

So git push origin main simply means: "Push my local main branch to the remote called origin."

The -u flag sets an upstream link:

git push -u origin main
Enter fullscreen mode Exit fullscreen mode

After this, Git remembers the connection between your local main and the remote main, so future pushes and pulls can be run without specifying the remote and branch each time.

To check your current branch:

git branch
Enter fullscreen mode Exit fullscreen mode

To check your remote names:

git remote -v
Enter fullscreen mode Exit fullscreen mode

13. The .gitignore File

Not everything in your project should be tracked by Git. Common files to exclude include dependency folders, environment files, logs, build outputs, and OS-generated files.

Create a .gitignore file in your project root:

touch .gitignore
Enter fullscreen mode Exit fullscreen mode

A practical example:

# Dependencies
node_modules/

# Environment variables
.env
.env.local

# Logs
*.log

# macOS files
.DS_Store

# Windows files
Thumbs.db

# Build output
dist/
build/
Enter fullscreen mode Exit fullscreen mode

Git will ignore everything listed here. You can find ready-made templates for different languages and frameworks at gitignore.io.

Set up your .gitignore before your first commit — not after.

14. Git Security: Do Not Commit Secrets

This is one of the most important habits to build early.

Never commit sensitive information such as:

  • Passwords
  • API keys
  • Access tokens
  • Private keys
  • Database credentials
  • Cloud credentials
  • .env files

Example of what not to commit:

DATABASE_PASSWORD=mysecretpassword
AWS_SECRET_ACCESS_KEY=examplekey
GITHUB_TOKEN=exampletoken
Enter fullscreen mode Exit fullscreen mode

If you accidentally commit a secret, simply deleting the file later is not enough. Git keeps the full history, so the secret remains visible in past commits. You should immediately rotate or revoke the exposed credential.

Add these to your .gitignore as standard practice:

.env
*.pem
*.key
Enter fullscreen mode Exit fullscreen mode

This is especially relevant if you are learning cloud, DevOps, or cybersecurity — exposed credentials are one of the most common causes of security incidents.

15. Undoing Mistakes

Everyone makes mistakes. Git gives you several ways to recover.

Unstage a file 

git restore --staged filename.txt
Enter fullscreen mode Exit fullscreen mode

Discard changes in your working directory 

# Careful: this permanently removes uncommitted changes
git restore filename.txt
Enter fullscreen mode Exit fullscreen mode

Fix the last commit message 

git commit --amend -m "Corrected commit message"
Enter fullscreen mode Exit fullscreen mode

Only use this if you have not already pushed the commit.

Undo the last commit but keep the changes 

git reset --soft HEAD~1
Enter fullscreen mode Exit fullscreen mode

Undo the last commit and discard the changes 

# ⚠️ Destructive — your work will be lost
git reset --hard HEAD~1
Enter fullscreen mode Exit fullscreen mode

Safely undo a pushed commit 

git revert commit-id
Enter fullscreen mode Exit fullscreen mode

git revert creates a new commit that reverses the target commit. This is the safe option for shared repositories because it does not rewrite history.

16. A Simple Daily Git Workflow

Here is a practical workflow you can use on real projects right now.

Get the latest changes:

git pull
Enter fullscreen mode Exit fullscreen mode

Create a new branch for your work:

git switch -c feature/update-readme
Enter fullscreen mode Exit fullscreen mode

Make your changes, then check status:

git status
Enter fullscreen mode Exit fullscreen mode

Stage and commit:

git add .
git commit -m "Update README documentation"
Enter fullscreen mode Exit fullscreen mode

Push your branch:

git push -u origin feature/update-readme
Enter fullscreen mode Exit fullscreen mode

Then open a pull request on GitHub or your preferred platform for review before merging.

17. What Is a Pull Request?

A pull request (PR) is a request to merge your branch into another branch, usually main.

Pull requests help teams:

  • Review code before it is merged
  • Discuss proposed changes
  • Run automated tests
  • Catch mistakes early
  • Keep the main branch stable and deployable

Even if you work alone, pull requests are a good habit. They give you a chance to review your own work before it becomes part of the project history.

18. Useful Git Commands Cheat Sheet 

# Setup
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Starting out
git init
git clone <url>

# Core workflow
git status
git add <file>
git add .
git commit -m "message"
git log --oneline

# Branching
git branch
git checkout -b <branch-name>
git switch -c <branch-name>
git switch main
git merge <branch-name>
git branch -d <branch-name>

# Remote repositories
git remote -v
git remote add origin <url>
git push -u origin main
git push
git pull
git fetch

# Inspecting changes
git diff
git diff --staged
git show <commit-id>

# Undoing changes
git restore --staged <file>
git restore <file>
git reset --soft HEAD~1
git reset --hard HEAD~1
git revert <commit-id>
Enter fullscreen mode Exit fullscreen mode

19. Common Beginner Mistakes

Committing directly to main — In team projects, always work on a separate branch and merge through a pull request. Keep main stable.

Writing vague commit messages — "stuff" and "changes" tell future-you nothing. Write messages like "Fix login form validation" instead.

Forgetting .gitignore — Set it up before your first commit to avoid accidentally tracking node_modules/, .env files, or build folders.

Using git reset --hard carelessly — This can permanently remove your work. When in doubt, use --soft or git stash to park your changes safely.

Force-pushing to shared branches — git push --force can overwrite your teammates' commits. Only use it on private branches when you fully understand the risk.

Not pulling before starting work — Always run git pull before beginning new work on a shared project to reduce merge conflicts.

Committing secrets — As covered above, never commit passwords, API keys, or credentials. Set up .gitignore and get into this habit from day one.

20. Next Steps

You now have a solid foundation in Git. Here is where to go from here:

  • Practice — Use Git on a small personal project. Even solo work benefits from Git habits.
  • GitHub — Create an account at github.com and push your first repository.
  • Interactive learning — Try Learn Git Branching, a free visual tool that makes branching and rebasing click.
  • Advanced commands — Explore git stash, git cherry-pick, git bisect, and Git hooks when you are ready.
  • Conventional commits — A standard for writing consistent, meaningful commit messages: conventionalcommits.org.

The goal is not to memorise every Git command. The goal is to understand the workflow:

Make changes. Review changes. Stage changes. Commit changes. Push changes. Collaborate safely.

Once that clicks, Git stops being intimidating and starts being one of your most reliable tools.

In the next article, we'll explore how teams manage code in practical dev environments using real-world git branching strategies.

Found this helpful? Drop a ❤️ or leave a comment below with any questions. Your feedback is always welcome.

Top comments (0)