How to Use Git and GitHub: Fix Version Control Confusion for Complete Beginners

If you have never used version control before, there is a specific moment that usually converts people. You are three hours deep into refactoring a feature, something breaks badly, and you realize you have no way back to the working version you had this morning. The only options are manually undoing changes you can barely remember, or accepting the broken state and trying to fix it from here.

I hit that exact wall on my second serious project. My "version control" was a folder called ProjectBackups with files named things like game_final.zip, game_final2.zip, and game_ACTUALLY_FINAL.zip. When the refactor broke something, I spent two hours trying to reconstruct what I had done rather than just rolling back to a known good state. It was slow, stressful, and completely avoidable.

Git solves this problem. Not eventually, not for big teams — from day one, even for solo projects. This guide teaches you everything you need to go from zero to confidently managing your project history, creating branches for experimental features, and backing everything up to GitHub so you never lose work to a corrupted drive or an accidental file deletion again.

What Is Git?

Git is a version control system — software that tracks every change you make to files in a project over time. Every time you save a snapshot of your project (called a commit), Git records exactly what changed, who changed it, and when. You can look at the full history of every change ever made, compare any two points in that history, and jump back to any previous state at any time.

Git runs entirely on your own computer. It does not need an internet connection, a server, or anyone else to be involved. It is a local tool for tracking your own project's history.

What Is GitHub?

GitHub is a website that stores Git repositories online. While Git tracks history locally on your machine, GitHub gives you a remote backup in the cloud, a way to access your project from different computers, and — when working with others — a shared location where multiple developers can push and pull changes.

Git and GitHub are often mentioned together but they are separate things: Git is the tool, GitHub is one of several hosting services that work with Git. GitLab and Bitbucket do the same job. GitHub is simply the most widely used, which is why this guide focuses on it.

Why Every Developer Needs Version Control

Before getting into installation and commands, it is worth being specific about what version control actually gives you, because the benefits are not obvious until you have needed them.

• A complete undo history — not just one level of Ctrl+Z, but a full record of every saved state going back to the beginning of the project. You can roll back one commit, ten commits, or all the way to day one.
• Safe experimentation — create a branch to try a new feature or refactor without touching your working main code. If it works, merge it in. If it does not, delete the branch and the main code is exactly as you left it.
• Offsite backup — push to GitHub and your project survives a dead hard drive, a stolen laptop, or a corrupted OS install.
• Collaboration without overwriting each other's work — when multiple people work on the same project, Git tracks who changed what and merges changes intelligently instead of having the last person to save win.
• A clear record of why things changed — good commit messages create a readable log of decisions made over the project's lifetime, which is invaluable when returning to a project after months away.

When To Start Using Git

The correct answer is: immediately, on every project, from the very first file. Not when the project gets big enough. Not when you start working with other people. From day one.

The common beginner reasoning is "I will add version control once the project is more established." The problem with this is that the moment you most need to roll back to a previous state is almost always during early messy experimentation — exactly the phase beginners skip version control for. Starting Git on a new project takes about two minutes. Adding it to a large existing project retroactively is much more work.

Part 1: Installation and First-Time Setup

Installing Git

Windows: Download the installer from git-scm.com. Run it with all default options — the defaults are correct for most users. After installation, open Command Prompt and type git --version to confirm it installed correctly.

Mac: Open Terminal and type git --version. If Git is not installed, macOS will prompt you to install Xcode Command Line Tools, which includes Git. Alternatively, install via Homebrew with brew install git.

Linux: Use your package manager. On Ubuntu or Debian: sudo apt install git. On Arch: sudo pacman -S git.

First-Time Configuration

Before using Git for the first time, tell it who you are. These details are attached to every commit you make:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Use the same email address you will use for your GitHub account. The --global flag applies these settings to every repository on your machine rather than just the current one.

Creating a GitHub Account

1. Go to github.com and click Sign Up.
2. Choose a username you are comfortable with publicly — this appears on your profile and on your repository URLs.
3. Verify your email address when prompted.
4. Free accounts include unlimited public and private repositories, which is everything you need to get started.

Part 2: Core Concepts — The Mental Model

Most Git confusion comes from not having a clear mental model of how it works. Before running any commands, understand these four concepts.

The Three Areas

Git tracks files across three distinct areas at any given moment:

• Working Directory — your actual files on disk, where you write code and make changes as normal.
• Staging Area (Index) — a holding area where you assemble the exact set of changes that will go into your next commit. Think of it as a packing box — you choose what goes in before sealing it.
• Repository (.git folder) — the permanent record of every commit you have sealed and saved. This is Git's actual database, stored in a hidden .git folder inside your project.

The workflow is always: make changes in the Working Directory → stage the ones you want with git add → save them permanently with git commit. Understanding this three-step flow makes almost every Git command immediately logical.

What Is a Commit?

A commit is a permanent snapshot of your staged changes, saved to the repository with a message describing what changed and why. Every commit has a unique ID (a long string of letters and numbers called a hash) that you can use to reference or return to that exact state at any time.

What Is a Branch?

A branch is an independent line of development — a copy of your project's history that you can work on without affecting other branches. The default branch is usually called main. When you want to try something new, you create a branch, work on it freely, and merge it back into main when it is ready — or delete it if it did not work out.

What Is a Remote?

A remote is a version of your repository stored somewhere else — typically on GitHub. When you push, you send your commits from local to the remote. When you pull, you fetch changes from the remote to your local machine.

Part 3: Your First Repository — Step by Step

Initializing a Repository

Navigate to your project folder in the terminal and run:

git init

This creates the hidden .git folder inside your project, turning it into a Git repository. Nothing in your project changes — Git just starts watching the folder. If you type git status now, you will see all your existing files listed as untracked, meaning Git sees them but is not yet managing them.

Creating a .gitignore File

Before staging anything, create a .gitignore file in your project root. This file tells Git which files and folders to ignore — never track, never commit. For any project you will want to ignore:

# Operating system files
.DS_Store
Thumbs.db

# Editor and IDE files
.vscode/
*.suo
*.user

# Build outputs
/build/
/dist/
*.log

For project-specific ignores, GitHub maintains a collection of pre-made .gitignore templates for hundreds of project types — search "github gitignore templates" to find the one matching your language or engine. Committing a proper .gitignore is one of the most impactful things you can do for a clean repository history. Without it, you will inevitably commit generated files, local configuration, and build outputs that clutter the repository and cause merge conflicts for no reason.

Your First Commit

# Stage all files in the project
git add .

# Confirm what is staged
git status

# Commit with a message
git commit -m "Initial commit — project setup"

git add . stages every untracked and modified file in the current folder and all subfolders. The dot means "everything here." For more selective staging, replace the dot with a specific filename: git add PlayerMovement.cs.

git commit -m "message" saves the staged changes permanently with the message in quotes. The message should describe what changed and why — "Fixed jump bug when landing on slope" is useful; "update" is not. You will thank yourself for descriptive commit messages when looking back through history six months later.

Part 4: The Daily Git Workflow

Once the repository is initialized, the daily pattern is simple and consistent:

# 1. Check what has changed
git status

# 2. See detailed changes
git diff

# 3. Stage your changes
git add filename.cs
# or stage everything:
git add .

# 4. Commit with a message
git commit -m "Add enemy patrol waypoint system"

# 5. View history
git log --oneline

The git log --oneline command shows a compact one-line view of every commit, most recent first, with its short hash and message. This is the most useful form of the log for day-to-day use — the full git log output is verbose and harder to scan quickly.

The Essential Git Commands Reference

Command	What It Does
git init	Initializes a new Git repository in the current folder.
git status	Shows which files have been modified, staged, or are untracked.
git add .	Stages all changes in the current folder for the next commit.
git add filename	Stages a specific file only.
git commit -m "message"	Saves staged changes permanently with a description.
git log --oneline	Shows a compact one-line history of all commits.
git diff	Shows line-by-line differences between working directory and last commit.
git branch	Lists all branches. The active branch is marked with an asterisk.
git branch branchname	Creates a new branch without switching to it.
git checkout -b branchname	Creates a new branch and switches to it immediately.
git checkout branchname	Switches to an existing branch.
git merge branchname	Merges the specified branch into the currently active branch.
git push origin main	Pushes local commits to the main branch on the remote named origin.
git pull	Fetches and merges changes from the remote into the current branch.
git clone URL	Copies a remote repository to your local machine.
git stash	Temporarily saves uncommitted changes and cleans the working directory.
git stash pop	Restores the most recently stashed changes.

Part 5: Connecting to GitHub

Step 1: Create a Repository on GitHub

1. Log into GitHub and click the + button at the top right, then New repository.
2. Name it to match your local project folder — this is not required but avoids confusion.
3. Leave it empty (no README, no .gitignore, no license) — you already have these locally.
4. Click Create repository.

Step 2: Link Your Local Repository to GitHub

GitHub shows you the exact commands to run after creating an empty repository. For a local repo you are pushing for the first time:

git remote add origin https://github.com/yourusername/yourrepo.git
git branch -M main
git push -u origin main

git remote add origin creates a named connection called "origin" pointing to your GitHub URL. "Origin" is the conventional name for the primary remote — you could call it anything, but origin is what every tool and tutorial expects.

git branch -M main renames the current branch to "main" if it was created as something else (Git historically used "master" as the default name; modern Git and GitHub both default to "main").

git push -u origin main pushes your local commits to GitHub and sets "origin main" as the default tracking relationship, so future pushes just need git push without specifying the remote and branch every time.

Authenticating with GitHub

When pushing for the first time, GitHub will ask for authentication. As of 2021, GitHub no longer accepts your account password for Git operations — you need a Personal Access Token (PAT):

1. On GitHub, go to Settings > Developer settings > Personal access tokens > Tokens (classic).
2. Click Generate new token, give it a name, set an expiry, and check the repo scope.
3. Copy the generated token — you will only see it once.
4. Use this token in place of your password when Git prompts for credentials.

Alternatively, install GitHub Desktop or the GitHub CLI (gh auth login) which handle authentication through a browser flow and never require a PAT for standard operations.

Part 6: Branches — Safe Experimentation

Branches are one of the most underused features by beginners, usually because they seem unnecessary on a solo project. They are not — they are just as valuable when working alone as on a team.

A Practical Branching Workflow

# Create a branch for a new feature
git checkout -b feature/enemy-patrol

# Work on the feature, make commits as normal
git add EnemyPatrol.cs
git commit -m "Add waypoint-based patrol route system"

# When the feature is ready, switch back to main
git checkout main

# Merge the feature branch into main
git merge feature/enemy-patrol

# Delete the branch now that it is merged
git branch -d feature/enemy-patrol

The practical benefit for a solo developer: if you start working on a new mechanic on a branch and it does not work out, you delete the branch and your main code is untouched. If you had worked directly on main, you would need to manually undo all the changes — which is exactly the situation I described at the beginning of this guide.

Part 7: Fixing a Merge Conflict

A merge conflict happens when two branches have both modified the same part of the same file in different ways, and Git cannot automatically decide which version to keep. This is the moment most beginners panic. It looks alarming and it is actually straightforward to resolve.

# After running git merge branchname, if there is a conflict:
# Git marks the conflicting file with conflict markers

# Open the conflicting file in your editor
# You will see something like this:

<<<<<<< HEAD
float moveSpeed = 6f;
=======
float moveSpeed = 8f;
>>>>>>> feature/speed-update

The section between <<<<<<< HEAD and ======= is what your current branch has. The section between ======= and >>>>>>> is what the branch being merged in has.

To resolve: edit the file to contain exactly what you want the final result to be — either one version, the other, or a combination — and remove all the conflict marker lines entirely. Then:

git add conflicted-filename.cs
git commit -m "Resolve merge conflict in player movement speed"

The first time I hit a merge conflict I closed the terminal and tried to undo everything I had done for the past hour because the markers looked like corrupted files. They are not — they are just Git's way of showing you the two competing versions and asking you to pick. Once you resolve and commit, the conflict is gone and the merge continues normally.

Part 8: Undoing Mistakes

Undo Last Commit (Keep Changes)

git reset --soft HEAD~1

Moves the last commit back to staged, keeping all the changes so you can re-commit with a corrected message or additional files.

Discard All Uncommitted Changes

git restore .

Discards all changes in the working directory and reverts to the last commit. This is permanent — changes discarded this way cannot be recovered.

View and Return to a Previous Commit

git log --oneline
git checkout abc1234

Replace abc1234 with the short hash of any commit from the log. This puts you in "detached HEAD" state — you can look around at that point in history, copy files, or create a new branch from it. Run git checkout main to return to the present.

Revert a Specific Commit

git revert abc1234

Creates a new commit that undoes the changes from the specified commit, without rewriting history. This is the safe way to undo a commit that has already been pushed to GitHub and potentially seen by others.

Troubleshooting Guide

Problem: "git" is not recognized as a command.

Likely cause: Git was not added to PATH during installation on Windows, or the terminal was not restarted after installation.

Fix: Close and reopen the terminal. If that does not work, reinstall Git and make sure "Add Git to PATH" is checked during the setup wizard.

Problem: git push asks for a username and password, then fails with authentication error.

Likely cause: GitHub stopped accepting account passwords for Git operations in 2021. A Personal Access Token is required instead.

Fix: Generate a Personal Access Token in GitHub Settings > Developer settings > Personal access tokens, and use that token in place of your password when prompted.

Problem: "Your branch is ahead of origin/main by N commits."

Likely cause: You have made local commits that have not been pushed to GitHub yet.

Fix: Run git push to send those commits to GitHub. This message is informational, not an error.

Problem: "fatal: not a git repository"

Likely cause: You are running a Git command from outside the project folder, or git init was never run in this folder.

Fix: Confirm you are inside the project folder (use pwd on Mac/Linux or cd on Windows to check the current path). If the folder has no .git directory, run git init.

Problem: I committed files I did not want to commit.

Likely cause: The files were not in .gitignore and were caught by git add .

Fix: If the commit has not been pushed: git reset --soft HEAD~1 to undo the commit while keeping changes, add the files to .gitignore, then recommit. If it was already pushed: add the files to .gitignore, run git rm --cached filename to stop tracking them, and commit the .gitignore update.

Problem: Merge conflict markers are still in the file after I tried to resolve.

Likely cause: The conflict marker lines (<<<<<<<, =======, >>>>>>>) were not completely removed from the file.

Fix: Open the file again and confirm every single marker line has been deleted — including the <<<<<<< HEAD line, the ======= line, and the >>>>>>> branchname line. Only the content you chose to keep should remain.

Key Takeaways

• Git tracks the full history of every change in your project, letting you undo mistakes, compare versions, and roll back to any previous state at any time.
• GitHub stores your repository online for backup and collaboration — it is a hosting service for Git, not Git itself.
• The core workflow is always: make changes → git add → git commit → git push.
• Branches let you experiment safely without touching working code — create one for every new feature or significant change.
• Merge conflicts are not errors — they are Git asking you to choose between competing changes. Edit the file, remove the markers, stage, commit.
• Start Git on every project from day one — adding it retroactively is always more work than starting with it.

Action Steps

1. Install Git and confirm with git --version in a terminal. Configure your name and email with git config --global.
2. Create a GitHub account if you do not have one.
3. Initialize a Git repository in your current project with git init and create a .gitignore before making any commits.
4. Make your first commit with git add . and git commit -m "Initial commit".
5. Create a new repository on GitHub, link it with git remote add origin, and push with git push -u origin main.
6. Create a branch for your next new feature instead of working directly on main.

Learning Roadmap

1. Get comfortable with the core daily workflow — status, add, commit, push, pull — before exploring advanced features.
2. Practice branching and merging on a personal project until switching branches and resolving conflicts feels routine.
3. Learn about pull requests on GitHub — the standard way to propose and review changes before merging, even on solo projects where you review your own work.
4. Explore GitHub Actions for automating builds, tests, and deployments triggered by commits or pull requests.
5. For game projects specifically, investigate Git LFS (Large File Storage) for managing large binary assets like textures, audio, and 3D models that exceed Git's standard file size recommendations.

Next Topics To Learn

• VS Code Setup for Developers — covering the most widely used code editor and its Git integration.
• GitHub Actions for Beginners — coming soon, covering automated workflows triggered by your commits.
• Claude AI for Game Developers — pair Git-managed projects with AI-assisted code review and debugging.