Learning Git from the Primagen

This guide is a structured summary of ThePrimeagen’s complete Git course, originally presented as a 4-hour video. The content covers two main parts: using Git as a solo developer and using Git effectively within a team. The goal is to provide a clean, readable reference for the core concepts, commands, and workflows, from initial setup to advanced techniques like rebasing, stashing, and handling conflicts.

1. Getting Started: The Fundamentals

Before using Git, you must configure it and understand its basic structure.

What is Git?

• Git is a distributed version control system created by Linus Torvalds.
• It tracks changes to code over time by creating commits.
• A commit is a snapshot of your project at a specific point in time, tied to an author and a message.
• Git’s commands are divided into two categories:
  • Porcelain: High-level, user-friendly commands you use 99% of the time (e.g., git add, git commit).
  • Plumbing: Low-level commands that manipulate the underlying Git objects. Understanding the plumbing helps make sense of the porcelain.

Initial Git Configuration (git config)

Git configuration is stored in files. You can set configuration at different levels, but the most common are:

• --global: Applies to every repository on your system. Stored in your home directory.
• --local: Applies only to the current repository. Stored in the .git/config file of that repository.

Essential Configuration Commands:

# Set your name globally
git config --global user.name "Your Name"

# Set your email globally
git config --global user.email "[email protected]"

# Set the default branch name to 'main' (modern standard)
git config --global init.defaultBranch main

Creating a Repository (git init)

A Git repository (or “repo”) is a project directory that Git tracks.

1. Create a directory for your project:

   mkdir my-project
   cd my-project
   

2. Initialize it as a Git repository:

   git init
   

   This command creates a hidden .git directory. This directory contains the entire history and state of your project. Everything Git knows about your project is inside .git.

2. The Core Solo Workflow

The daily workflow for a solo developer revolves around three main commands.

File States

A file in a Git repo can be in one of three main states:

1. Untracked: Git sees the file, but doesn’t track its changes.
2. Staged: You have marked the file’s current version to be included in the next commit. This is also known as the “index”.
3. Committed: The file’s changes have been saved in a snapshot to the Git history.

The Workflow Commands

1. git status: Shows the current state of your repository, including which files are untracked, modified, or staged. It’s the first command you should run to understand what’s happening.

2. git add <file>: Moves a file from the untracked/modified state to the staged state. This prepares it for the next commit.

   # Stage a specific file
   git add contents.md
   
   # Stage all changes in the current directory and subdirectories
   git add .
   

3. git commit -m "Your message": Takes all staged files and creates a new commit (snapshot) with them. The -m flag allows you to provide a descriptive message.

   git commit -m "feat: Add initial table of contents"
   

   After committing, git status will show a “clean working tree,” meaning no changes are pending.

3. Understanding Git’s Internals

To truly master Git, you need to understand how it stores information.

Viewing History (git log)

The git log command displays the commit history. It has many useful flags:

• --oneline: Shows a condensed, one-line view of each commit.
• --graph: Draws an ASCII graph showing the branch and merge history.
• --decorate: Shows where branch and tag pointers (HEAD, main, etc.) are located.
• --parents: Shows the parent commits for each commit, which is useful for identifying merge commits.

Objects: Commits, Trees, and Blobs

Git’s data is stored as objects in the .git/objects/ directory. The three main object types are:

• Blob: Stores the raw content of a file. Git deduplicates blobs; if two files have the exact same content, they point to the same blob.
• Tree: Represents a directory. It contains pointers to blobs (files) and other trees (subdirectories).
• Commit: Points to a single tree object (the root of your project at that time), the parent commit(s), author info, and the commit message.

Key Insight: Git stores snapshots, not diffs. Each commit points to a full tree of the project’s state. It remains efficient by pointing to existing, unchanged blobs and trees from previous commits.

You can inspect these objects with the plumbing command git cat-file -p <hash>:

# 1. Find the hash of your latest commit
git log --oneline

# 2. View the commit object
git cat-file -p <commit_hash>
# This will show the tree hash, parent hash, author, and message.

# 3. View the tree object
git cat-file -p <tree_hash>
# This will show the blobs and other trees in that directory.

# 4. View the blob (file content)
git cat-file -p <blob_hash>

4. Branching and Merging

Branches are what allow for parallel development.

What is a Branch?

A branch is simply a lightweight, movable pointer to a commit. It is not a copy of your project.

• git branch: Lists all local branches.
• git switch -c <branch-name>: Creates a new branch from your current location (HEAD) and switches to it. (The older command is git checkout -b <branch-name>).
• git switch <branch-name>: Switches to an existing branch.

git merge

Merging integrates the changes from one branch into another.

• Fast-Forward Merge: If the target branch has not diverged (i.e., the branch you’re merging is a direct descendant), Git simply moves the target branch’s pointer forward. No new commit is created.
• Merge Commit: If the branches have diverged, Git creates a new merge commit. This special commit has two parents—one from each of the merged branches—and combines their histories.

How to Merge:

# 1. Switch to the branch you want to merge INTO
git switch main

# 2. Merge the other branch
git merge feature-branch

5. Rebasing: A Cleaner History

Rebasing is an alternative to merging for integrating changes.

What is git rebase?

Instead of creating a merge commit, git rebase rewrites history. It takes the commits from your feature branch and replays them on top of the target branch’s latest commit.

The Process:

1. Go to the tip of the target branch (e.g., main).
2. Apply each of your feature branch’s commits one by one.
3. Move your feature branch pointer to the new tip.

The result is a linear history, which can be easier to read and revert.

How to Rebase:

# 1. Switch to the branch you want to update
git switch feature-branch

# 2. Rebase it ONTO the target branch
git rebase main

CRITICAL RULE: Never rebase a public branch that others are using (like main). Since it rewrites history, it will cause massive problems for anyone who has pulled the old version. Only rebase your own local, private branches.

6. Undoing and Fixing Mistakes

Git provides powerful tools for undoing changes.

• git reset: Moves the current branch pointer to a different commit.

  • --soft <commit>: Moves the pointer but leaves all changes from the undone commits in the staging area. Useful for squashing or fixing the last commit.
  • --hard <commit>: Moves the pointer and discards all changes in both the staging area and the working directory. This is destructive and can cause data loss if not used carefully.

• git revert <commit>: Creates a new commit that is the exact inverse of the specified commit. It undoes the changes without rewriting history, making it safe for public branches.

7. Working with Remote Repositories & Teams

Most development involves collaborating via a central remote repository like GitHub.

Remotes and Forking

• A remote is a pointer to another repository, usually hosted on a server. The default name is origin.
• A fork is your own personal copy of someone else’s repository on a platform like GitHub.

Standard Collaboration Workflow:

1. Fork the main project repository on GitHub.
2. Clone your fork to your local machine: git clone <your_fork_url>.
3. Add the original repository as a remote called upstream: git remote add upstream <original_repo_url>.
4. Create a feature branch, make commits, and then git push origin <your-branch>.
5. Open a Pull Request (PR) on GitHub to merge your changes from your fork into the original upstream repository.

Fetch, Pull, and Push

• git fetch <remote>: Downloads all changes from a remote repository but does not integrate them into your local branches.
• git pull <remote> <branch>: Is equivalent to git fetch followed by git merge. It downloads and merges changes in one step.
• git push <remote> <branch>: Uploads your local branch’s commits to the remote repository.

reflog: Your Safety Net

git reflog (reference log) tracks every movement of HEAD. If you accidentally reset --hard and think you’ve lost a commit, reflog will show you where HEAD was, allowing you to find the “lost” commit hash and recover it (e.g., by cherry-picking or resetting back to it).

8. Handling Conflicts

Conflicts occur when Git cannot automatically merge changes because the same lines in the same file were modified on diverging branches.

Resolving a Conflict:

1. Git will pause the merge/rebase and mark the conflicting files.

2. Open the file(s). You will see conflict markers:

   <<<<<<< HEAD (Your changes)
   // Code from your current branch
   =======
   // Code from the branch you are merging/rebasing from
   >>>>>>> <branch_name_or_hash>
   

3. Manually edit the file to resolve the differences and remove the conflict markers.

4. For a merge: git add <resolved_file> and then git commit.

5. For a rebase: git add <resolved_file> and then git rebase --continue.

ours vs. theirs:

• In a merge, ours is your current branch; theirs is the branch being merged in.
• In a rebase, this is inverted. Because rebase checks out the target branch first, ours refers to the target branch (e.g., main), and theirs refers to the commits from your feature branch being replayed.

9. Advanced Commands for a Clean Workflow

• git stash: A temporary clipboard for uncommitted changes. git stash saves your working directory and staging area changes, git stash pop reapplies them. It works like a stack (Last-In, First-Out).

• Squashing (git rebase -i): Combining multiple commits into a single commit. This is done with an interactive rebase (-i). You mark commits with pick (keep) or s (squash into previous).

• git cherry-pick <commit>: Applies a single commit from another branch onto your current branch.

• git bisect: A powerful debugging tool that uses a binary search to find the exact commit that introduced a bug. You start it with git bisect start, mark a known good commit and a known bad commit, and Git will check out commits in between, asking you to mark each as good or bad until it isolates the culprit.

• git worktree: Allows you to have multiple branches checked out in different directories at the same time, avoiding the need to constantly switch branches or stash changes.

• git tag: Creates an immutable (unchangeable) pointer to a specific commit, typically used for versioning releases (e.g., git tag -a v1.0.0 -m "Version 1.0.0").

Key Takeaways

• Core Workflow: git status -> git add -> git commit.
• Branches are Pointers: They are cheap and fundamental to parallel work.
• Merge vs. Rebase: Merge preserves exact history with merge commits. Rebase rewrites history for a cleaner, linear log. Never rebase public branches.
• Safety Nets: git reset (local), git revert (public), and git reflog (recovery) are essential for fixing mistakes.
• Team Collaboration: The fork-and-pull-request model is standard. Use upstream to keep your fork in sync.
• Cleanliness Tools: stash, squash, and cherry-pick help maintain a clean and understandable commit history.
• Debugging: git bisect is an incredibly efficient way to find the origin of a bug.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.