Git is the version control system that runs the software world. Every team uses it, every open-source project depends on it, and every developer needs to understand it — not just the happy path, but the messy reality of merge conflicts, detached heads, and force pushes gone wrong. This guide covers Git from the ground up: how it works, how to use it effectively, and how to fix things when they break. Every section links to deeper posts, cheat sheets, and fix guides so you can jump to exactly what you need.
Getting Started with Git
If you’re new to Git or want a refresher on the fundamentals, start with what is Git? It explains the core mental model: Git is a distributed version control system that tracks snapshots of your project over time. Every developer has a full copy of the repository, which means you can work offline, branch freely, and merge changes without a central server bottleneck.
The command set is large, but you’ll use maybe 15 commands daily. Our Git cheat sheet distills those essentials — clone, add, commit, push, pull, branch, merge, log, and the flags that make them useful. Keep it open until the muscle memory kicks in. And if you’ve ever wondered what Git is actually doing when you run these commands — how it stores data, what a commit really is, how branches are just pointers — our post on how Git tracks changes explains the internals without drowning you in theory.
One thing that trips up beginners: Git doesn’t automatically ignore build artifacts, node_modules, .env files, or OS junk like .DS_Store. You need a .gitignore file, and getting it right matters. Our .gitignore cheat sheet covers the syntax and common patterns, and the .gitignore generator creates a tailored file for your stack in seconds.
Branching, Merging, and Rebasing
Branching is where Git shines. Creating a branch is instant and cheap — it’s just a pointer to a commit. This means you can experiment freely, work on features in isolation, and keep main clean. The real skill is knowing how to bring branches back together.
Merging is the default strategy: Git creates a merge commit that combines two branches. It’s safe and preserves history, but it can make your commit log noisy. Rebasing rewrites history to create a linear sequence of commits, which looks cleaner but requires more care — especially on shared branches. Both have their place, and most teams use a mix.
The pain point is conflicts. When two branches modify the same lines, Git can’t auto-merge and drops you into conflict resolution. Our merge conflict fix guide walks you through resolving conflicts step by step, including how to use tools like VS Code’s built-in merge editor. If you’re rebasing instead of merging, the process is slightly different — our rebase conflict fix covers that workflow specifically. And if Git refuses to merge because the branches have no common ancestor, you’re dealing with unrelated histories, which usually happens after a repo restructure or when combining two separate projects.
Stashing: Saving Work Without Committing
Sometimes you’re mid-feature and need to switch branches — maybe to review a PR or fix a bug. You’re not ready to commit, but you can’t switch branches with uncommitted changes. That’s what git stash is for. It saves your working directory and index state, gives you a clean slate, and lets you reapply the changes later.
Stashing sounds simple, but it has enough nuance to warrant its own reference. Our Git stash cheat sheet covers stash, stash pop, stash list, stash drop, applying specific stashes, and stashing untracked files. The most common gotcha is conflicts when popping a stash — if the branch has changed since you stashed, Git might not be able to cleanly apply your changes. Our stash pop conflict fix explains how to resolve that without losing work.
Working with Remotes: Push, Pull, and Sync
Git is distributed, which means your local repository and the remote (usually GitHub or GitLab) can diverge. Keeping them in sync is straightforward when you’re the only one working on a branch, but gets complicated with a team.
The most common sync issue is a push rejected error — someone else pushed to the branch before you, and Git won’t let you overwrite their work. The fix is usually git pull --rebase followed by another push. If your branch is behind origin, you need to pull the latest changes before you can push. And if Git warns that local changes would be overwritten by a pull, you need to stash or commit your work first.
Authentication issues are another common blocker. If you’re getting permission denied (publickey) errors, your SSH key isn’t set up correctly — or you’re using HTTPS when you should be using SSH (or vice versa). And if Git simply can’t access the remote, it could be a network issue, a firewall, or an expired token.
GitHub, GitLab, and CI/CD
Git is the tool; GitHub and GitLab are the platforms built on top of it. They add pull requests, code review, issue tracking, and — critically — CI/CD pipelines. Choosing between them matters for your workflow. Our GitHub vs. GitLab comparison breaks down the differences in features, pricing, and philosophy.
If you’re on GitHub, Actions is the CI/CD system you’ll use. Our GitHub Actions cheat sheet covers workflow syntax, triggers, jobs, steps, and the YAML quirks that trip people up. For a practical starting point, our guide on building a CI pipeline with GitHub Actions walks through a real-world setup with linting, testing, and deployment steps.
CI/CD is where Git discipline pays off. Clean commit messages, small PRs, and a consistent branching strategy make pipelines reliable. Sloppy Git habits — force pushes to shared branches, massive merge commits, inconsistent .gitignore files — make pipelines flaky and debugging miserable.
Git Tools That Save Time
The command line is powerful, but the right tools make Git faster and less error-prone. Our Git command builder helps you construct complex commands without memorizing every flag — useful for operations you don’t run often, like interactive rebases or cherry-picks across repositories.
For code review and debugging, the Git diff viewer gives you a cleaner way to inspect changes than the default terminal output. Side-by-side diffs, syntax highlighting, and the ability to navigate between files make it easier to catch issues before they hit a PR.
Pair these tools with the Git cheat sheet for daily commands and the .gitignore generator for project setup, and you’ve got a workflow that minimizes friction.
Troubleshooting Git: Common Errors and Fixes
Git errors range from mildly confusing to genuinely panic-inducing. Here’s a quick reference for the most common ones, each linking to a detailed fix guide.
Repository and state errors are the scariest because they feel like you’ve broken something fundamental. If you see fatal: not a git repository, you’re running a Git command outside a repo — or your .git directory is damaged. A detached HEAD means you’ve checked out a specific commit instead of a branch, which is fine for looking around but dangerous if you start committing. And if Git says your branch is already up to date but you know it shouldn’t be, you’re probably comparing the wrong branches or haven’t fetched the latest changes.
Staging and commit errors are more common and less scary. If Git says changes not staged for commit, you just need to git add the files you want to include. If you can’t lock a ref, our cannot lock ref fix explains how stale lock files and packed refs cause this and how to clean them up.
Merge and rebase errors are the ones that eat the most time. We covered merge conflicts, rebase conflicts, and unrelated histories above. The key to all of them: don’t panic, read the error message carefully, and use git status to understand what state you’re in before trying to fix anything.
Network and auth errors block you from collaborating. Permission denied and unable to access are the big two. Both are usually configuration issues, not Git issues — check your SSH keys, tokens, and remote URLs.
What to Read Next
If you’re just starting out, follow this path:
- What is Git? — understand the mental model
- Git cheat sheet — learn the essential commands
- .gitignore cheat sheet — set up your project correctly
- How Git tracks changes — understand the internals
- GitHub Actions CI pipeline — automate your workflow
If you’re debugging a specific error, use the troubleshooting section above to jump straight to the fix. And if you’re setting up a new team workflow, start with GitHub vs. GitLab to pick your platform, then build your CI/CD pipeline from there.
Git has a reputation for being hard, but most of that difficulty comes from not understanding the mental model. Once you grasp that commits are snapshots, branches are pointers, and the staging area is your pre-commit buffer, everything clicks. Bookmark this page and come back whenever you need a refresher, a cheat sheet, or a fix.