Git Force-Push Disaster — Stale Rebase Recovery
A force-push with stale refs deleted merged features from main.
- Every commit is a permanent, timestamped snapshot with a unique SHA.
- Git is local-first — all operations (branching, committing, history) work without a network.
- Branches are lightweight pointers — creating one costs almost nothing.
- Working directory: your actual files.
- Staging area (index): what you've selected for the next commit.
- Repository (.git): the complete history graph.
- Remote: a shared copy hosted elsewhere (GitHub, GitLab).
- Git stores content as snapshots, not diffs — this is why branching is instant and history traversal is fast.
- The reflog is your safety net — it records every HEAD movement for 90 days, allowing recovery of "deleted" commits.
- Force-pushing to shared branches destroys history and breaks teammates' local repos.
Git is the version control system underlying virtually every software project. It solves three problems: tracking who changed what and when, enabling parallel development through branches, and providing a mechanism to recover from mistakes.
The common misconception is that Git is just a backup system. It is not. Git is a content-addressable DAG (directed acyclic graph) of snapshots. Understanding this mental model separates engineers who blindly run commands from those who can recover from any state, resolve complex conflicts, and design efficient branching strategies.
This guide covers the fundamentals, then layers on production-grade insights: when rebases go wrong, how to recover from force-push disasters, and why your branching strategy directly impacts deployment velocity.
What Is a Repository and Why Does Git Need One?
Before you run a single Git command, you need to understand the word 'repository' — because it comes up constantly. A repository (usually shortened to 'repo') is just a folder on your computer that Git is actively watching and tracking. That's it. The moment you tell Git to watch a folder, that folder becomes a repository.
Inside every Git repository, Git creates a hidden folder called .git. This is Git's private notebook where it stores the entire history of your project — every version of every file, every message you attached to your saves, and every branch you've ever created. You'll almost never need to touch that .git folder directly, but knowing it exists explains the magic: as long as that folder is there, your full history is safe.
Think of the repository as a library and the .git folder as the librarian's filing cabinet in the back room. Your actual files are the books on the shelves that you read and edit. The filing cabinet tracks every edition of every book ever checked in, who edited it, and what changed between editions. You work with the books; Git manages the filing cabinet automatically.
Creating a repository is the very first step in any Git workflow. You'll either initialise a fresh one from scratch, or clone (download) an existing one from a platform like GitHub. Let's start from scratch.
Your First Commit: How Git Actually Saves Your Work
In Git, saving your work isn't called 'saving' — it's called 'committing'. A commit is a permanent snapshot of your project at a specific moment in time. Think of it like taking a photograph of your entire project folder. You can take as many photographs as you want, and you can always look back at any photo from any point in the past.
Here's the part that trips up every beginner: Git uses a two-step process to save work, and for good reason. First you 'stage' your changes (step 1), then you 'commit' them (step 2). Staging is like putting items into a box before you seal and label it. It lets you choose exactly which changes go into a commit — maybe you changed three files but only want to snapshot two of them right now. That's completely valid.
The command for staging is git add. The command for committing is git commit. Every commit requires a message — a short human-readable note explaining what changed and why. These messages are invaluable six months later when you're trying to remember why a certain change was made. Write them like you're leaving a note for your future self, because you are.
The analogy: staging is packing the box, committing is sealing it, labelling it, and putting it on the archive shelf permanently.
Branches: How to Experiment Without Breaking Anything
Here's where Git goes from 'useful' to 'genuinely magical'. A branch is an independent line of development that runs parallel to your main code. You can create a branch, make all kinds of experimental changes in it, and your main code is completely untouched. If the experiment works, you merge the branch back in. If it doesn't, you delete the branch and it's as if it never happened.
Every Git repository starts with one default branch, usually called main (older projects may call it master). This is your stable, production-ready code. Nobody should push broken code directly to main. Instead, every new feature or bug fix gets its own branch.
Picture a river. The main river is your main branch — it keeps flowing steadily. When you want to try something new, you dig a side canal (a new branch). You do all your experimental digging in the canal. If the canal works great, you reconnect it to the main river (merge). If it floods and turns into a swamp, you just fill it back in (delete the branch) — the main river never knew anything happened.
This is the exact workflow used at every professional software company on earth. Features developed on branches, reviewed, then merged. Understanding this is what separates someone who 'knows some Git commands' from someone who actually understands Git.
Configuring Git and Connecting to GitHub — The Full Picture
Git runs entirely on your local machine — everything we've done so far lives only on your computer. That's great for personal version control, but most real projects need a remote home so your team can access the code, or so you don't lose everything if your laptop dies. That's where platforms like GitHub, GitLab, and Bitbucket come in.
Think of your local repository as your personal notebook and GitHub as the shared whiteboard in the office. You do your thinking and drafting in your notebook, then when you're ready, you share your updates to the whiteboard. Your colleagues can pull your updates from the whiteboard into their own notebooks.
Before any of this works, Git needs to know who you are. Every commit is stamped with a name and email address so your team knows who made each change. This is a one-time setup on your machine. After that, you point Git at your remote repository with git remote add, push your work up with git push, and pull your teammates' work down with git pull.
You don't need a GitHub account to learn Git locally, but you'll want one before you share any project or apply for jobs — your GitHub profile is your public portfolio.
| Concept | What It Is | Real-World Analogy |
|---|---|---|
| Repository | A folder Git is tracking, with full history stored in .git | A library with a complete archive of every past edition of every book |
| Commit | A permanent snapshot of your project at a specific moment | A dated photograph of your entire project folder, sealed forever |
| Branch | An independent parallel line of development | A side canal dug from the main river — experiments happen there, not in the river |
| Staging Area | A holding zone where you choose what goes into the next commit | Packing items into a box before you seal and label it |
| Merge | Combining the history of one branch into another | Reconnecting the side canal back to the main river |
| Remote (GitHub) | An online copy of your repository that your team can access | The shared whiteboard in the office — everyone reads from and writes to it |
| git push | Sending your local commits up to the remote repository | Copying your notebook updates onto the shared whiteboard |
| git pull | Downloading commits from the remote into your local repo | Copying the shared whiteboard updates back into your notebook |
| Merge vs Rebase | Merge preserves branch history with a merge commit; rebase rewrites history to be linear | Merge is tying two ropes together with a knot; rebase is untying one rope and splicing it onto the end of the other |
| git fetch vs git pull | Fetch downloads remote changes without modifying working directory; pull fetches then merges | Fetch is reading the whiteboard without touching your notebook; pull is reading and immediately copying changes in |
| Reflog | A local log of every HEAD movement — your safety net for recovery | A GPS tracker on your car — even if you drive somewhere and forget how to get back, it remembers every turn |
Key Takeaways
- A Git repository is just a normal folder with a hidden .git directory inside it — that directory is Git's entire memory, storing every snapshot of your project ever taken.
- Committing is a two-step process by design: 'git add' stages the exact changes you want, and 'git commit' permanently seals that snapshot with a message — this intentional separation gives you precision control over what goes into each save.
- Branches let you experiment in complete isolation from your working code — the industry-standard workflow is to never commit directly to main, always branch, then merge after review.
- Git is local-first: everything works on your machine without internet access. GitHub is a remote host — it's not Git itself, it's a platform that stores a copy of your Git repository online so teams can collaborate.
- The reflog is your ultimate recovery tool — it records every HEAD movement for 90 days, meaning almost any 'lost' commit can be recovered as long as you act before garbage collection runs.
- Merge preserves history faithfully; rebase rewrites it to be linear. The choice is a trade-off between auditability (merge) and readability (rebase). Never rebase commits that others have based work on.
Interview Questions on This Topic
- QWhat is the difference between 'git fetch' and 'git pull', and when would you use each one?
- QCan you explain the difference between merging and rebasing in Git, and what are the trade-offs of each approach?
- QIf you accidentally committed a file containing a database password to a public GitHub repository, what would you do immediately and why?
- QExplain the Git object model. What are blobs, trees, commits, and tags, and how do they relate to each other?
- QYour team's repository has grown to 5GB and cloning takes 30 minutes. How would you diagnose and fix this?
- QWhat is a detached HEAD state, how do you get into it, and how do you recover if you made commits while detached?
Frequently Asked Questions
What is the difference between Git and GitHub?
Git is the version control software that runs on your local computer and tracks changes to your files. GitHub is a website that hosts Git repositories online so teams can share and collaborate on code. You can use Git without GitHub, but you need Git installed to work with GitHub repositories. Think of Git as the engine and GitHub as the parking garage where everyone stores and shares their cars.
Do I need to pay for Git or GitHub?
Git itself is completely free and open-source. GitHub offers a free tier that covers everything individual developers and most small teams need, including unlimited public and private repositories. Paid plans exist for larger organisations that need advanced access controls, audit logs, and enterprise features. For learning and most professional use, the free tier is more than enough.
What happens if two people edit the same file at the same time — does Git break?
Git handles this remarkably well through a concept called merging. If two people change different parts of the same file, Git automatically combines both changes without any conflict. If two people change the exact same line, Git flags a 'merge conflict' and asks a human to decide which version (or combination) to keep. This is a normal, routine part of collaborative development — Git shows you exactly which lines conflict and you resolve them manually, then commit the resolution.
What is the difference between merge and rebase, and when should I use each?
Merge creates a new commit that ties together two branch histories, preserving the exact timeline of when each change was made. Rebase takes your commits and replays them on top of another branch, creating a linear history. Use merge when you want to preserve the true history of how development happened (important for auditing). Use rebase on feature branches before merging to main to keep the project history clean and linear. The critical rule: never rebase commits that have been pushed to a shared branch, as this rewrites history that others may have based work on.
How do I undo a commit that I already pushed to the remote?
If the commit is the most recent one, use git revert <sha> — this creates a new commit that undoes the changes without rewriting history, making it safe for shared branches. If you must completely erase the commit (e.g., it contains secrets), use git reset --hard HEAD~1 locally then git push --force-with-lease, but only if no one else has pulled the commit. For commits further back in history, git revert is still the safest option on shared branches.
That's Git. Mark it forged?
4 min read · try the examples if you haven't