Git Force-Push Disaster — Stale Rebase Recovery

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.

# Step 1: Create a new project folder and navigate into it
mkdir my-first-project
cd my-first-project

# Step 2: Tell Git to start tracking this folder
# This creates the hidden .git folder inside my-first-project
git init

# Step 3: Confirm that Git is now watching this folder
# The .git folder only appears when you pass the -a flag (show hidden files)
ls -a

# Step 4: Check the current state of the repository
# At this point there are no files yet, so Git will say it's a fresh repo
git status

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.

# We're inside my-first-project (from the previous step)

# Step 1: Create a real file with some content
echo "# My First Project" > README.md
echo "This project is tracked by Git." >> README.md

# Step 2: Check what Git sees — it notices the new file but isn't tracking it yet
# Git calls untracked files 'untracked' — they exist in the folder but not in Git's history
git status

# Step 3: Stage the file — tell Git 'yes, include this file in the next snapshot'
# The dot (.) means 'stage everything in the current folder'
git add README.md

# Step 4: Check status again — README.md is now in the 'staging area'
git status

# Step 5: Commit the staged file with a descriptive message
# -m lets you write the message inline — always use present tense, e.g. 'Add' not 'Added'
git commit -m "Add README with project description"

# Step 6: View the commit history — you'll see your commit with its unique ID
git log --oneline

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.

# We're continuing inside my-first-project with our first commit already made

# Step 1: See all existing branches — the asterisk (*) shows your current branch
git branch

# Step 2: Create a new branch called 'add-contact-page'
# Naming convention: use lowercase, hyphens, descriptive names — never spaces
git branch add-contact-page

# Step 3: Switch to the new branch so our changes happen there, not on main
git switch add-contact-page

# (Older Git versions use 'git checkout add-contact-page' — both work)

# Step 4: Create a new file on this branch
echo "# Contact Page" > contact.md
echo "Email us at: hello@myproject.com" >> contact.md

# Step 5: Stage and commit the new file — this commit lives ONLY on add-contact-page
git add contact.md
git commit -m "Add contact page with email address"

# Step 6: Switch back to main and notice contact.md is GONE from your folder
# It's not deleted — it simply doesn't exist on the main branch yet
git switch main
ls

# Step 7: Merge the work from add-contact-page into main
# Now contact.md will appear in main and the commit history merges too
git merge add-contact-page
ls

# Step 8: Delete the branch — the work is merged, we don't need it anymore
git branch -d add-contact-page

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.

# ── PART 1: One-time global configuration ──────────────────────────────────

# Tell Git your name — this appears on every commit you ever make
git config --global user.name "Alex Johnson"

# Tell Git your email — use the same email as your GitHub account
git config --global user.email "alex.johnson@example.com"

# Set VS Code as your default editor (optional but recommended for beginners)
git config --global core.editor "code --wait"

# Confirm your settings look correct
git config --list

# ── PART 2: Connect your local repo to GitHub ───────────────────────────────
# Assumes you've created an empty repo on github.com called 'my-first-project'

# Add the remote — 'origin' is the conventional name for your primary remote
# Replace YOUR_USERNAME with your actual GitHub username
git remote add origin https://github.com/YOUR_USERNAME/my-first-project.git

# Verify the remote was added correctly
git remote -v

# ── PART 3: Push your local commits to GitHub ───────────────────────────────
# -u sets 'origin main' as the default so future pushes just need 'git push'
git push -u origin main

# ── PART 4: Pull the latest changes from GitHub (use this daily) ────────────
# This fetches + merges any changes your teammates pushed since your last pull
git pull origin main

Why Git Doesn’t Care About Your Feelings: The Object Model Explained

Most tutorials wave their hands saying Git stores 'snapshots.' That’s a lie. Git stores content-addressable objects—blobs, trees, commits, and tags—each hashed with SHA-1. The hash is the address. Change one bit and you get a different address. That’s how Git detects corruption instantly. It’s also why your branch pointers are just labels on these immutable objects.

When you run git add Git packs your file contents into a blob object and writes it to .git/objects. git commit stitches the current tree (think directory listing) with parent commit references and metadata into a commit object. No file is ever overwritten. Every commit creates new objects. That’s why you can time-travel without breaking history.

Understanding this kills the mystery behind detached HEAD, merge conflicts, and rebase. You’re not moving files—you’re reassigning labels to immutable snapshots. Stop thinking like a file system and start thinking like a content-addressable store. Your mental model is everything.

// io.thecodeforge — devops tutorial

# Inspect the raw object behind a commit
steps:
  - name: Show internal object type
    run: |
      git init
      echo "production_secret" > deploy_key.pem
      git add deploy_key.pem
      git commit -m "initial deploy key"
      # Get the commit's tree object hash
      git rev-parse HEAD:
      # Output: 4b825dc642cb6eb9a060e54bf899d153036d4a1f
  - name: View raw tree content
    run: |
      git cat-file -p 4b825dc642cb6eb9a060e54bf899d153036d4a1f
      # Output: 100644 blob a1b2c3d4 deploy_key.pem

The Three Trees You’re Actually Fighting: Working Directory, Staging, HEAD

You’re not just fighting one tree. You’re wrestling three: the working tree (your filesystem), the staging area (aka index), and the HEAD commit (last committed state). Most of Git’s confusing commands—reset, checkout, restore—just shuffle pointers between these three trees.

A git add copies a file from the working tree to the staging area. A git commit freezes the staging area into a new commit object and moves HEAD. git checkout HEAD -- config.yml overwrites your working tree from the staging area. If you understand this triangle, git reset --soft, git reset --mixed, and git reset --hard stop being magic incantations. Soft moves HEAD only. Mixed moves staging. Hard moves all three.

Next time you accidentally commit credentials to staging, you don’t need to panic. You need to unstage and rewrite. Knowing which tree is polluted tells you exactly which command to fire. Stop guessing.

// io.thecodeforge — devops tutorial

# Reset a mistakenly staged config file
steps:
  - name: Accidentally stage production config
    run: |
      echo "DB_PASSWORD=supersecret" >> staging.env
      git add staging.env
  - name: Unstage without deleting working copy
    run: |
      git reset HEAD staging.env
      # Staging (index) resets to HEAD. Working file untouched.
  - name: Verify the damage is contained
    run: |
      git status
      # Output: Changes not staged for commit: staging.env

Merging Is a Lie: How Git Actually Resolves Conflicts

Everyone tells you merging is automatic. It’s not. Git performs a three-way merge using the two branch tips and their common ancestor. It only auto-merges files where changes don’t touch the same lines. The second two people edit the same region, Git throws its hands up and says 'your turn.'

A merge conflict is just a file annotated with <<<<<<<, =======, >>>>>>> markers. Git doesn’t resolve semantics—it only cares about text. Your job is to pick the final version and strip the markers. Then git add the file to mark it resolved.

Pro move: use git merge --no-commit --no-ff to inspect the auto-merge before committing. If the diff looks wrong, you abort with git merge --abort. Never trust an automated merge on a production branch without code review. Merging is a mechanical step, not a thinking step. You’re the thinking step.

// io.thecodeforge — devops tutorial

# Simulate a conflict on a production config
steps:
  - name: Create divergent branches
    run: |
      git init
      echo "TIMEOUT=30" > app.cfg
      git add app.cfg && git commit -m "initial"
      git checkout -b experimental
      echo "TIMEOUT=60" > app.cfg
      git commit -am "increase timeout"
      git checkout main
      echo "TIMEOUT=90" > app.cfg
      git commit -am "even bigger timeout"
  - name: Attempt merge
    run: |
      git merge experimental
      # Output: Auto-merging app.cfg; CONFLICT
      cat app.cfg
      # Output: <<<<<<< HEAD\nTIMEOUT=90\n=======\nTIMEOUT=60\n>>>>>>> experimental

Networking: Git Over SSH vs HTTPS — What Actually Happens on the Wire

You type git push and magic happens. No. Git opens a TCP connection, negotiates a protocol, and transfers objects. If you don't understand the transport layer, you'll spend hours debugging auth failures and timeout errors in production.

SSH uses port 22, authenticates with keys, and gives you a persistent connection. HTTPS uses port 443, relies on credential helpers, and forces token rotation. Choose SSH for scripted pipelines where you control the key pair. Choose HTTPS for CI/CD systems that rotate tokens weekly. Your choice determines what breaks at 2 AM.

The real trap: Git's dumb transport protocol sends full objects over the wire. A 10 MB binary file in your repo gets transferred every push. No delta compression for that. Use .gitattributes with binary markers and git lfs for anything over 1 MB. Your network admin will thank you.

// io.thecodeforge — devops tutorial

# .gitconfig — force SSH for all remotes
[url "ssh://git@github.com/"]
  insteadOf = https://github.com/

# Set push buffer to avoid "Connection reset" on large repos
[http]
  postBuffer = 524288000  # 500 MB

# Binary file marker — no deltas
.gitattributes:
  "*.psd binary"
  "*.zip -delta"

Scripting: Automate Git Like It Owes You Money

You're not going to type git add . && git commit -m "fixes" for the 500th time. That's what shell scripts are for. A senior engineer automates the boring parts and gets out of the way.

The why: Git hooks run before commits, pushes, and merges. Use pre-commit to lint code, prepare-commit-msg to enforce ticket numbers, and post-merge to reinstall dependencies. Write them in Bash or Python, and check them into your repo under .git/hooks/. But remember — hooks are local by default. Use a shared hooks directory with git config core.hooksPath.

The real power: scripting multi-repo workflows. A production deploy touches five microservices across separate repos. Write a Bash loop that clones, checks out the tag, runs CI, and tags. No manual clicking. No forgetting a repo. Your CTO will assume you're a wizard. You're just a dev who writes for repo in "${REPOS[@]}"; do.

// io.thecodeforge — devops tutorial

# deploy.sh — multi-repo tag-and-push
repos=("api-gateway" "user-service" "payment-worker")
version="v$(date +%Y%m%d).${BUILD_NUMBER}"

for repo in "${repos[@]}"; do
  git clone "git@github.com:acme/${repo}.git" "/tmp/${repo}"
  cd "/tmp/${repo}"
  git tag -a "${version}" -m "auto-deploy ${version}"
  git push origin "${version}"
  echo "Tagged ${repo} with ${version}"
done

echo "All repos deployed to ${version}"

Docker as a Git-Like Version Control for Environments

Docker containers solve the same root problem as Git: reproducibility. Where Git freezes code in time, Docker freezes an entire operating environment. A Dockerfile is a declarative recipe, much like a Git commit history. Running docker build produces an immutable image, and docker run spawns a container from that image. The key insight: images are built in layers, and each layer is cached — identical to how Git caches objects. If a layer doesn't change, Docker reuses it. This means you can ship an environment that is byte-for-byte identical across dev, CI, and production. Without Docker, Git only guarantees code history, not behavior history. For DevOps, pair a Git tag with a Docker image tag: git tag v1.0; docker build -t app:v1.0 . Now you have time traveling for both code and its runtime.

// io.thecodeforge — devops tutorial

// Docker layers work like Git objects: cached until base changes
FROM node:18 AS base
COPY package*.json ./
RUN npm install          # layer 1, cached unless package.json changes

FROM base AS build
COPY src/ ./
RUN npm run build       # layer 2, cached unless src/ changes

FROM nginx:alpine AS runtime
COPY --from=build /build /usr/share/nginx/html
# Only ENTRYPOINT and port change trigger rebuild here
EXPOSE 80

Kubernetes: Git-Ops as the Only Sanity for Distributed Systems

Kubernetes extends Git's declarative model to infrastructure. You declare desired state in YAML files (Deployments, Services, ConfigMaps) and push them to a cluster. The control loop — like Git's merge mechanism — continuously reconciles actual state toward desired state. The missing link: GitOps. Store all Kubernetes manifests in a Git repository. When you merge a PR, a CI tool (ArgoCD, Flux) automatically applies that config to the cluster. This turns rollback into git revert and auditing into git log. Why this beats manual kubectl: every change is traceable, reviewable, and repeatable. If a node crashes, the cluster self-heals from the declarative state — no SSH, no shell scripts. Kubernetes deployments that lack Git history are like code without version control: eventually someone wonders, 'What changed last Tuesday at 3 AM?'

// io.thecodeforge — devops tutorial

// Git repo holds desired state; cluster pulls changes automatically
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
    git-commit: "a1b2c3d"   # track Git SHA for rollback
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: my-registry/web:a1b2c3d  # matching Git tag

Skills You’ll Gain

By mastering Git and GitHub, you’ll earn the ability to track every line of code change without fear — reverting mistakes, branching experiments, and merging with surgical precision. You’ll understand the object model so deeply that commands like rebase and cherry-pick become second nature. On the DevOps side, you’ll automate pipelines, manage secrets, and implement GitOps workflows that keep Kubernetes clusters honest. Collaborating via pull requests, resolving real merge conflicts, and signing commits will become routine. Crucially, you’ll stop relying on GUIs and start scripting Git like it owes you money — because in production, speed and accuracy are all that matter.

// io.thecodeforge — devops tutorial
skills:
  - Track and revert changes with git log, reset, reflog
  - Branch and merge without losing work
  - Configure SSH/HTTPS securely
  - Automate with hooks and aliases
  - GitOps for Kubernetes deployments
  - Resolve conflicts manually
  - Sign commits with GPG

Syllabus

This course is structured like your real workflow — not a boring list of commands. Start with configuring Git and connecting via SSH and HTTPS, then write your first commit while understanding the object model under the hood. Graduate to branching strategies, merge conflicts, and rebasing with real examples. Next, explore Git networking, scripting with hooks, and automating chores. The second half shifts to DevOps: Versioning Docker environments like Git snapshots, and implementing GitOps with ArgoCD for Kubernetes. Each module ends with a production-grade challenge, not a multiple-choice quiz. You’ll finish ready to script, debug, and deploy without hand-holding.

// io.thecodeforge — devops tutorial
modules:
  - Git Foundations: Config, SSH, First Commit
  - Object Model, Trees, and HEAD in Depth
  - Branching, Merging, and Conflict Resolution
  - Networking: SSH vs HTTPS Under the Wire
  - Scripting and Automation with Hooks
  - Docker as Version Control for Environments
  - Kubernetes GitOps with ArgoCD

Hands-On Learning & Certification

Theory is worthless without a terminal. Every concept here comes with a real Git repository you clone, break, and fix. You’ll create branches, simulate merge conflicts, and recover lost commits using reflog. For DevOps, you’ll automate a Git hook that rejects unclean commits, then deploy a Docker container with versioned tags. Finally, you’ll set up a GitOps pipeline that syncs a Kubernetes cluster with a GitHub repo. Complete all challenges, and you earn a certificate of completion from TheCodeForge — verifiable and shareable. Over 50 million learners have started with Git and GitHub. Join them, not as a beginner, but as someone who understands why Git works.

// io.thecodeforge — devops tutorial
hands_on:
  - Clone repo and fix simulated merge conflict
  - Recover lost commit with git reflog
  - Write a pre-commit hook for code standards
  - Tag Docker images with Git SHA
  - ArgoCD: sync app from GitHub to K8s
award: Certificate of Completion (verifiable)