Dev's Dread
A Git Horror Story
An interactive tutorial disguised as existential dread
Meet Kael
Kael, a developer whose optimism died during his first JavaScript framework tutorial, has somehow landed a job. He's fueled by cold brew and the quiet terror of being exposed as a fraud. His primary career goal is to avoid breaking the main branch.
Today, he learns about Git, the source of all his future suffering.
🔮 Git Commands You'll Master
git config - Set your identitygit clone - Steal someone's workgit init - Start the nightmare.gitignore - Ignore the evidencegit status - See what you've brokengit add - Stage your mistakesgit commit - Make it permanentgit log - Review your failuresgit branch - Create parallel sufferinggit switch - Jump between realitiesgit stash - Hide your messgit merge - Combine the chaosgit remote - Connect to the cloudgit push - Share your paingit fetch - Scout the changesgit pull - Import others' paingit reset - Undo local mistakesgit revert - Undo public mistakesgit diff - Inspect your changesgit clean - Nuke untracked filesgit rebase - Rewrite historygit cherry-pick - Steal a commitgit reflog - The time machinegit blame - Find the culpritgit tag - Mark a releasegit bisect - Hunt the buggit worktree - Clone your workspace
🔧 Seraphina's Pro-Tips: `git config` Variations
git config --global user.name "Name": Sets your name
globally for all repositories.
git config --local user.email "email": Sets email for
just the current repository. Useful for work vs personal projects.
git config --list: Shows all your current Git settings.
Good for checking what you've configured.
git clone. It downloads
a complete copy of someone else's repository. It's like photocopying a
book, but for code. And yes, you get all their mistakes too."
🔧 Seraphina's Pro-Tips: `git clone` Variations
git clone <url>: Clones into a folder named after
the repository.
git clone <url> my-folder: Clones into a folder
with a custom name.
git clone --depth 1 <url>: "Shallow clone" - gets
only the latest commit, not the full history. Faster for huge
repositories.
git init creates a new
repository right where you are. It's like saying 'Git, please start
judging my work from this moment forward.'"
🔧 Seraphina's Pro-Tips: `git init` Variations
git init: Initializes in the current directory.
git init my-project: Creates a new directory called
'my-project' and initializes Git inside it.
.gitignore. It's a plain text file where you list
patterns for files and folders that Git should pretend don't exist.
This is the absolute first thing you should do after
git init."
.gitignore file
tells Git which files or folders to ignore in a project. Ignored files
won't show up in `git status` and can't be added to the staging area.
File: .gitignore
🔧 Seraphina's Pro-Tips: `.gitignore` Power-ups
/logs: Ignores only the root `logs` directory, not
`src/logs`.
docs/**/*.md: Ignores all markdown files in any
subdirectory of `docs`.
!important.log: An exclamation mark negates a pattern.
This file will *not* be ignored even if `*.log` is listed above it.
Check out gitignore.io to automatically generate `.gitignore` files for your project type.
git status is your panic
button. It shows you exactly what you've touched and what Git thinks
about it."
🔧 Seraphina's Pro-Tips: `git status` Variations
git status -s or git status --short:
Compact one-line-per-file format. You'll use this constantly once
comfortable.
git add to select
which changes deserve to be permanent."
🔧 Seraphina's Pro-Tips: `git add` Variations
git add .: Stages all changes in current directory and
subdirectories. Your go-to "stage everything" command.
git add -p: Interactive mode - lets you stage parts of
files. Perfect for crafting clean commits.
commit. That creates
a permanent snapshot of your staged changes. The message describes
what you did, so future you (or your teammates) can understand why
this commit exists. Write something useful, not 'fixed stuff'."
🔧 Seraphina's Pro-Tips: `git commit` Variations
git commit: Opens your text editor for a longer, more
detailed commit message. Better for complex changes.
git commit --amend: Modifies the last commit instead of
creating a new one. Perfect for fixing typos in commit messages.
git log, your personal
museum of regret. It shows every commit in reverse chronological
order. You can see what you changed, when, and what excuse you made in
the commit message."
🔧 Seraphina's Pro-Tips: `git log` Variations
git log --oneline: Compact one-line-per-commit view.
Much easier to scan.
git log --graph: Shows ASCII art of branch structure.
Essential for understanding complex histories.
branch.
Think of it as a parallel timeline where you can experiment without
affecting the main universe. Create one with git branch,
then jump into it with git switch."
🔧 Seraphina's Pro-Tips: `git branch` and `git switch`
git branch: Lists all local branches.
git switch <name>: Switches to an existing
branch.
git switch -c <name>: Creates a new branch and
switches to it in one command. This is the one you'll use most
often.
git stash. It's like stuffing your messy work into a
drawer so you can deal with the emergency. Your changes disappear
temporarily, giving you a clean workspace. You can bring them back
later with git stash pop."
🔧 Seraphina's Pro-Tips: `git stash` Variations
git stash: Saves your uncommitted changes (staged and
unstaged) and cleans your working directory.
git stash list: Shows you all the stashes you have
saved. Each one has an index (e.g., `stash@{0}`).
git stash apply stash@{1}: Applies a specific stash
from the list without deleting it. Useful if you need to apply the
same changes to multiple branches.
git stash pop: Applies the most recent stash (same as
`apply stash@{0}`) and then immediately deletes it from the list if
there are no conflicts.
git stash drop stash@{1}: Deletes a specific stash from
the list.
git remote add to link your local repo to the cloud. Then
your code becomes everyone else's problem too."
🔧 Seraphina's Pro-Tips: `git remote` Variations
git remote -v: Lists all remotes with their URLs.
git remote set-url origin <new-url>: Changes the
URL of an existing remote.
git push to upload your
commits. The first time, use git push -u origin main to
set the upstream. After that, just git push works. And
relax - you probably won't break everything. Probably."
🔧 Seraphina's Pro-Tips: `git push` Variations
git push -u origin <branch>: Sets the upstream
and pushes. Do this the first time for each branch.
git push --force-with-lease: Safer force push. Won't
overwrite if someone else pushed in the meantime.
git fetch first. It downloads the latest changes but
doesn't merge them yet. Think of it as reconnaissance. You can inspect
what changed with git log origin/main before deciding to
merge."
🔧 Seraphina's Pro-Tips: `git fetch` Variations
git fetch: Fetches from the default remote (usually
origin).
git fetch --all: Fetches from all configured remotes.
git pull to download and
merge in one command. It's basically git fetch followed
by git merge. Most of the time it works smoothly. When it
doesn't... well, that's what makes this job interesting."
🔧 Seraphina's Pro-Tips: `git pull` Variations
git pull --rebase: Instead of merging, replays your
commits on top of the pulled changes. Creates cleaner history.
git pull --no-rebase: Forces a merge even if
fast-forward is possible.
git merge to bring in your feature
branch. If you're lucky, it'll be a 'fast-forward' merge and just
work. If not... we'll deal with conflicts."
🔧 Seraphina's Pro-Tips: `git merge` Variations
git merge --no-ff <branch>: Forces creation of a
merge commit even for fast-forward merges. Preserves branch history.
git merge --abort: Cancels a merge in progress and
returns to the pre-merge state. Your escape hatch.
- You push your feature branch to the remote repository.
- In the web interface (like GitHub), you "Open a Pull Request".
- You select your branch (`feature/login`) to be merged into the base branch (`main`).
- You write a description of your changes and assign teammates to review your code.
- They will read your code, leave comments, and request changes.
- You'll make changes locally and push new commits to the *same* feature branch to update the PR.
- Once your team approves, the PR is merged into `main`—often via the web interface.
🔧 Seraphina's Pro-Tips: Surviving Code Review
Keep PRs Small: A PR that changes 50 lines is easy to review. A PR that changes 2,000 lines will be approved without being read, and you'll have to fix the bugs later.
Write Good Descriptions: Explain *what* the PR does and *why* it does it. Link to the ticket or issue number.
Don't Take it Personally: Feedback on your code is not feedback on you as a person. It's about making the product better. Separate your ego from your code.
<<<<<<<,
=======, and >>>>>>>.
Edit the file to keep what you want, remove the markers, then
git add and git commit."
Automatic merge failed; fix conflicts and then commit the result.
File: index.html (You must fix this)
git diff to see exactly
what changed line by line. It shows additions in green and deletions
in red. Think of it as your personal change inspector before you make
anything permanent."
🔧 Seraphina's Pro-Tips: `git diff` Variations
git diff: Shows unstaged changes in your working
directory.
git diff --staged: Shows changes that are staged for
commit.
git reset to erase it from history. It's like it
never happened. Just don't ever do this to commits that others already
have."
git reset moves the
branch pointer, effectively removing commits from your local history.
It's powerful but dangerous if used on shared branches.
🔧 Seraphina's Pro-Tips: The Three Modes of `reset`
git reset --soft HEAD~1: Moves the branch pointer back
one commit, but leaves your changed files in the "staged" area. It's
as if you undid the commit but kept everything ready for a new one.
git reset --mixed HEAD~1 (or just
git reset HEAD~1): This is the default. It moves the
branch pointer back and unstages your files, leaving them in your
working directory as modified but "unstaged".
git reset --hard HEAD~1:
DANGEROUS. Moves the branch pointer back and
permanently deletes all changes in both the staging area and your
working directory. The changes are gone forever (unless you find
them in the `reflog`).
git revert. It doesn't erase history. It creates a *new*
commit that is the exact opposite of the bad one. It's the safe,
responsible way to undo public changes."
git revert creates a new
commit that undoes the changes from a previous commit. It's the safe
way to fix mistakes on shared branches.
git clean is your nuclear
option for untracked files. ALWAYS run git clean -n first
to see what it would delete. Then git clean -f to
actually do it. It's irreversible, so don't be an idiot."
🔧 Seraphina's Pro-Tips: `git clean` Variations
git clean -n: Dry run. Shows what would be deleted
without doing anything.
git clean -f: Force. Deletes all untracked files.
git rebase -i lets you rewrite your local history. You
can squash commits, reword them, reorder them... anything. It makes
your history clean and professional. Just promise me you'll never,
ever rebase a branch that other people are using. That't how you
summon unspeakable horrors."
git rebase reapplies
your commits on top of another branch, creating a clean, linear
history. The interactive mode (-i) is a powerful tool for
cleaning up your local commits before sharing them.
Tip: Change 'pick' to 'squash' (or 's') on the second commit to combine it with the first.
git cherry-pick. It plucks a commit from anywhere and
applies it to your branch. It's like a surgical strike for code."
git reflog. It's a secret log of
everything you've done. Find the state before you messed up, and you
can reset back to it. It's your real undo button."
git blame. It shows you who last touched each line of a
file. It's not for blaming people, it's for... 'knowledge discovery'."
git tag. It creates a permanent bookmark for a specific
commit, like v1.0."
git bisect. You give it one 'good' commit where things
worked, and one 'bad' commit where they don't. It then performs a
binary search of your history, checking out the midpoint each time.
You just test and tell it 'good' or 'bad'. In a few steps, it will
pinpoint the exact commit that introduced the bug."
git bisect is a
debugging tool that automates a binary search through your commit
history to find a specific change.
git worktree.
It lets you check out another branch into a completely separate folder
without touching your current one. It's like having two project
folders for the price of one. Clean, separate, and no stashing
required."
git worktree lets you
manage multiple working directories for one repository.