Git Basics Tutorial: Version Control from Scratch

If you have ever lost work because you overwrote a file or struggled to merge changes from a teammate, this git basics tutorial is for you. Git is the most widely used version control system in the world, and understanding its fundamentals is essential for every developer. In this guide we will start from zero and build a solid, practical foundation in Git and GitHub that you can apply to any project, large or small.

Version control is not just for large teams. Even solo developers benefit from tracking changes, experimenting safely in branches, and rolling back mistakes. By the end of this tutorial you will know how to initialize a repository, stage and commit changes, create and merge branches, resolve conflicts, and collaborate with others on GitHub using pull requests.

What is Version Control?

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Think of it as a time machine for your code. Without version control, developers resort to naming files like final_v2_really_final.txt, which quickly becomes unmanageable and error-prone.

There are two main types of version control: centralized (like Subversion) and distributed (like Git). In a centralized system, there is one central server that holds all the history. In a distributed system, every developer has a full copy of the repository, including its entire history. This means you can work offline, commit changes locally, and sync with a remote server when you are ready.

A git basics tutorial would be incomplete without mentioning why Git dominates the industry: it is fast, branching is cheap and instantaneous, and it handles everything from small scripts to massive codebases like the Linux kernel, which was the original project Git was built to manage.

Key concepts to understand before we start writing commands:

• Repository (repo): A directory that Git tracks. It holds all your files and their complete history.
• Commit: A snapshot of your files at a given point in time, along with a message describing what changed.
• Branch: A parallel line of development that diverges from the main line, letting you work independently.
• Remote: A version of your repo hosted on a server, like GitHub, that lets you collaborate with others.
• HEAD: A pointer to the current branch and commit you are working on.

Installing Git

Before running any commands, you need to install Git. On macOS, Git is often preinstalled or available through Xcode Command Line Tools. On Linux, use your package manager:

# Debian / Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# macOS (via Homebrew)
brew install git

Verify the installation and configure your identity. Every commit records the author name and email, so set these once globally:

git --version
git config --global user.name "Jane Developer"
git config --global user.email jane@example.com

You can also set your default editor and enable color output for better readability:

git config --global core.editor "code --wait"
git config --global color.ui auto

Core Git Commands: A Git Basics Tutorial Walkthrough

Now we get to the heart of this git basics tutorial: the commands you will use every single day. Mastering these will make you productive immediately.

Start by creating a new repository in an existing folder:

mkdir my-project && cd my-project
git init

This creates a hidden .git directory that stores all the metadata and history. To copy an existing remote repository instead, use clone:

git clone https://github.com/user/repo.git

The typical day-to-day workflow is: edit files, stage them, commit, and push. Here is the cycle you will repeat countless times:

git status              # see what changed
git add file.txt        # stage one file
git add .               # stage everything in the directory
git commit -m "Add login page"
git push origin main

Two important areas to understand, because they confuse many beginners:

• Working directory: The files on your disk as you edit them. These changes are not yet tracked by Git until you stage them.
• Staging area (index): A holding zone where you gather and review changes before committing. This two-step process gives you control over exactly what goes into each commit.

The git status command is your best friend. Run it constantly to see which files are modified, staged, or untracked. Use git log --oneline --graph to visualize your commit history as a compact graph, and git diff to review your changes before committing. You can also use git diff --staged to see only the changes you have staged for the next commit.

Branching and Merging

Branches let you work on features or fixes without affecting the main code. Creating and switching branches is nearly instant in Git because branches are just lightweight pointers, not copies of files:

git branch feature-login    # create a branch
git checkout feature-login  # switch to it
# or do both at once:
git checkout -b feature-login

When the feature is done, merge it back into the main branch:

git checkout main
git merge feature-login

Sometimes two branches change the same lines and Git cannot merge automatically. This is a merge conflict. You will see conflict markers (<<<<<<<, =======, >>>>>>>) in the file. Open the file, choose which changes to keep, remove the markers, then git add and git commit to complete the merge.

A common branching strategy is Git Flow: main holds production code, develop holds integration, and feature branches branch off develop. For smaller teams, trunk-based development where everyone commits to main or short-lived branches is simpler and faster. Choose a strategy that matches your team size and release cadence.

Working with GitHub

GitHub is a hosting platform for Git repositories. It adds collaboration features like pull requests, issues, code review, and project boards. To connect your local repo to GitHub:

git remote add origin https://github.com/user/repo.git
git push -u origin main

A typical collaboration workflow on GitHub looks like this:

1. Fork the upstream repo on GitHub to create your own copy on your account.
2. Clone your fork locally so you can edit files.
3. Create a branch for your change, keeping it focused on one feature or fix.
4. Push the branch to your fork on GitHub.
5. Open a pull request on GitHub so maintainers can review your code, leave comments, and merge it.

Use git fetch to download remote changes without merging them, and git pull to fetch and merge in one step. The difference matters: fetch is safe and non-destructive, while pull can create unexpected merges if your local branch has diverged.

Two commands that beginners often confuse are reset and revert:

• git reset --hard HEAD~1 moves the branch pointer back, effectively erasing the last commit. Use with caution because it discards changes.
• git revert <commit> creates a new commit that undoes the changes of a previous commit, preserving history. This is safer for shared branches.

Need to shelve uncommitted work temporarily? Use the stash:

git stash        # save and remove changes from working dir
git stash pop    # restore them later

Best Practices for Git

To wrap up this git basics tutorial, here are habits that will save you headaches and make your history clean and useful:

• Write clear commit messages. Use the imperative mood: "Fix login redirect" not "Fixed login redirect." A good message answers what and why, not just what file changed.
• Commit small and often. Each commit should represent one logical change. This makes it easier to review, revert, and understand history.
• Use branches for everything. Never develop directly on main in a shared project. Short-lived branches keep the main line stable.
• Add a .gitignore file to exclude build artifacts, dependencies, and secrets from the repository.
• Pull before you push to avoid conflicts and keep history clean.
• Review diffs before committing with git diff and git diff --staged.

Here is a practical .gitignore example:

# .gitignore
node_modules/
.env
dist/
*.log
.DS_Store

Mastering Git takes practice, but the fundamentals in this git basics tutorial will carry you through almost any project. Start by cloning a repo, making a few commits, and pushing to GitHub. Ready to test your knowledge? Take the quiz below to see how much you learned about repositories, commits, branches, and collaboration.