Git Getting Started Tutorial: Learn Version Control from Zero

If you are just starting to learn programming or beginning collaborative development, Git is the first hurdle you need to clear.

Many people think Git is hard, but the problem is not Git itself -- it is that nobody explains the core concepts clearly. Once you understand the "why," the "how" follows naturally. This article starts from scratch and walks you through the complete Git workflow.

What Problem Does Git Solve

When writing code, you have probably experienced this: you fixed a bug and accidentally broke another feature. You want to go back, but you do not know which files you changed or what you changed in each file.

Git solves this problem. It records every change you make, lets you view history at any time, and lets you roll back whenever you want. Think of it as a game save feature, but far more powerful -- it does not just save a snapshot of one point in time, it records every single change itself.

Git also serves another critical purpose: collaboration. When multiple people edit the same file, Git can automatically merge changes. Where there are conflicts, Git flags them for you to decide. Before Git, people sent code via email and named folders v1_final_really_final, which was genuinely painful.

Beyond these two primary functions, Git provides:

• Branching: work on multiple features simultaneously without interference
• History: track who changed what and when, for accountability and understanding
• Backup: every clone is a full backup of the entire project history

Installing Git

On Mac, open Terminal and type git --version. If it is not installed, you will be prompted to install it. On Windows, go to git-scm.com and download the installer. After installation, open your terminal and type:

git --version

Seeing a version number means it is installed.

Next, configure your name and email. These will appear in every record:

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

You should also configure your default branch name and preferred text editor:

git config --global init.defaultBranch main
git config --global core.editor "code --wait"    # VS Code

For Windows users, configure line ending handling:

git config --global core.autocrlf true

For Mac/Linux users:

git config --global core.autocrlf input

Three Core Concepts

Before diving into commands, understand Git three areas.

The working directory is the folder you see on your computer. Creating files, editing code, deleting files -- all happen here.

The staging area is Git intermediate zone. You "put changes in" and tell Git these are the changes I want to record. You can stage part of a file, or part of your changes. This is a unique and powerful feature of Git -- you do not have to commit everything at once. You can stage only the changes that belong together.

The repository is where Git permanently stores history. When you "commit" the staged content to the repository, Git creates a permanent record.

The relationship: working directory -> git add -> staging area -> git commit -> repository.

First Time Using Git

Create a new folder, enter it, and initialize Git:

mkdir my-project
cd my-project
git init

This creates a hidden .git directory that Git uses to manage all version information. You now have an empty Git repository.

Create a file, for example README.md, and write some content. Then type:

git status

Git will tell you README.md is "untracked" -- Git sees the file but is not managing it yet.

Now put the file into the staging area:

git add README.md

Run git status again and README.md turns green, meaning it is staged.

Commit the staged content to the repository:

git commit -m "First commit: add README"

The -m is followed by a message describing what you did. Write it clearly so you know what happened when you look back at history later.

Viewing History

After committing a few times, type:

git log

Git lists every commit in reverse chronological order. Each record has the author, timestamp, message, and a string of characters (the commit ID). This ID is the unique identifier for that commit. You can use it later to view details or roll back to this point.

If the output is too much, use git log --oneline to show one line per commit. Other useful options:

git log --graph          # show branch structure
git log --stat           # show file changes per commit
git log -p               # show full diff for each commit
git log --since="2026-01-01"  # filter by date

Connecting to a Remote Repository

Right now your Git only lives on your computer. If you want to back it up online or collaborate with others, you need to connect to a remote repository. GitHub is the most popular choice. Register an account and create a new repository.

Back in your terminal, link your local repository to the remote one:

git remote add origin https://github.com/your-username/repo-name.git

origin is the name for the remote repository. You can call it anything, but everyone defaults to origin.

Then push your local content up:

git push -u origin main

The -u is short for --set-upstream. It links your local main branch to the remote main branch so you can just type git push in the future.

Daily Workflow

Once Git is installed and the remote repository is linked, your daily workflow is just four steps.

Step one, pull the latest code: git pull. If someone changed the remote repository, this downloads the latest content.

Step two, make your changes. Write code, edit documents, fix bugs -- whatever.

Step three, stage your changes: git add filename. To stage everything, use git add . (the dot means all files in the current directory).

Step four, commit and push: git commit -m "message" followed by git push.

Four steps. That is the loop most people run all day.

Handling Multiple File Changes

When you have changes to multiple files that belong to different commits, use git add selectively:

git add file1.js file2.js       # stage specific files
git add src/                    # stage entire directory
git add -p                      # stage changes interactively

The -p flag opens an interactive mode where you can choose which hunks (sections) to stage. This is incredibly useful for separating unrelated changes into different commits.

An Easy-to-Miss Detail

Not everything should be committed. Compiled programs, dependency packages, passwords and keys in configuration files -- these should not go into Git.

Create a file called .gitignore in the project root and list the file types you do not want Git to track:

node_modules/
.env
*.log
dist/

Git will automatically ignore these files. This file itself should be committed so everyone cloning your project uses the same exclusion rules.

Other common .gitignore entries:

# OS files
.DS_Store
Thumbs.db

# IDE files
.vscode/
.idea/
*.swp
*.swo

# Build artifacts
build/
*.pyc
__pycache__/

Undoing Things

Git provides several ways to undo changes, depending on where they are in the workflow:

• Unstage a file: git reset filename (moves from staging area back to working directory)
• Discard working directory changes: git checkout -- filename
• Amend the last commit: git commit --amend (adds staged changes to the previous commit)
• Revert a commit: git revert <commit-id> (creates a new commit that undoes the specified commit)
• Reset to a previous commit: git reset --hard <commit-id> (dangerous -- discards all commits after the specified one)

Use reset --hard with extreme caution, especially on shared branches. It permanently discards history and can cause data loss.

Wrapping Up

Git has a low entry barrier -- just init, add, commit, and push. What takes time to understand is the design philosophy behind it: every change is a snapshot, history is immutable (unless you deliberately rewrite it), and the distributed nature means every computer has a full backup.

Once you understand this philosophy, learning branches, merges, and rollbacks becomes much easier. The key insight is that Git is not just a backup tool -- it is a collaboration tool and a time machine for your code.

Next Steps: What to Learn After the Basics

Once you're comfortable with the daily workflow (init, add, commit, push, pull), here's what to learn next:

Branching and merging. The real power of Git emerges when you create separate branches for features, fixes, and experiments. Learn git branch, git checkout, and git merge to work on multiple features simultaneously without conflicts.

Pull requests. On platforms like GitHub and GitLab, pull requests are how code gets reviewed and merged into the main branch. Understanding the PR workflow is essential for any team environment.

Rebase vs. merge. These two approaches to integrating branches have different trade-offs. Rebase creates a cleaner history; merge preserves the original branch structure. Learn both and choose based on your team's preferences.

Git hooks. Scripts that run automatically before or after specific Git operations. Use them to run tests before pushing code, enforce commit message formats, or automate any repetitive task.

Interactive rebase. The ability to rewrite, reorder, or squash commits before sharing them with others. This is how you turn a messy development history into a clean, understandable commit log.

These intermediate topics will take your Git skills from functional to professional.