Why Did the Website Crash Overnight When It Was Working Fine Yesterday?

After successfully deploying your project to Vercel and binding it to a cool custom domain, you might feel invincible.
The next day, you spot a typo on the webpage, fix it on your local machine, and happily type in the terminal:
git commit -m "Fixed typo"
git push

Five minutes later, your client calls screaming: "Why does the website show a blank white screen now?!"
Panicked, you log into Vercel's dashboard and see the latest deployment marked with a glaring red "Build Failed" indicator.

This is the nightmare scenario in modern DevOps (Development and Operations integration).
Remember the magic we learned in Chapter 2: CI/CD (Continuous Integration/Continuous Deployment)? When you push code, Vercel automatically builds and deploys it.
But this double-edged sword has a downside: "If you push broken code, your site will die publicly in the cloud."

What should you do now?

Lifesaver Technique #1: Vercel's "Time Travel (Rollback)"

When facing a live crash, the golden rule is: "Restore functionality first, debug later!"
Don’t waste time fixing code in a broken live environment—every second costs money.

Vercel offers a feature that makes traditional engineers drool: Instant Rollback.

Log into Vercel and navigate to your project.
Switch to the Deployments tab.
Here, you’ll see a history of every push. The top entry with the red light is your latest failed attempt.
Scroll down to find the last green checkmark (successful) deployment.
Click the three dots ... on the right side of that entry.
Select "Assign Custom Domain" or "Promote to Production" (the exact wording may vary with Vercel updates, but the idea is to redeploy this older, working version).
In less than a second, your site reverts to yesterday’s version—typos and all, but at least it works!

With the client calmed and the boss appeased, you can now safely return to your computer and play detective.

Why Did It Fail? Deciphering Vercel's Build Logs

Why does code that runs perfectly on your local machine (localhost) explode when pushed to Vercel?
The two most common culprits are:

Missing environment variables: You added a new database password to your local .env but forgot to update Vercel’s settings.
TypeScript/ESLint validation failures: Vercel is strict. If your code has unused variables or type errors, your local machine might let it slide, but Vercel’s cloud robots will reject it outright!

Vibe Prompt Debugging: Let AI Read the Red Text

Don’t guess blindly! Open the Build Logs for the failed deployment—you’ll see a wall of black-and-white (and red) text.
Copy it all and paste it into Cursor’s AI:

【Vercel Deployment Debugging Prompt】
My project failed to build when pushed to Vercel.
Here’s the full Build Logs:
[Paste the logs here]

What’s the exact cause of failure? Did I forget an environment variable, or is it a syntax check error?
Tell me how to fix the code to pass Vercel’s compilation.

The AI will instantly pinpoint the culprit: "In app/page.tsx line 45, user_id lacks a type definition, triggering a TypeScript error that Vercel caught."
Follow the AI’s instructions, push again, and watch the green light appear!

The Ultimate Boss: Git Merge Conflicts

When collaborating with others (or even switching between your own devices), you’ll meet Git’s scariest monster: Merge Conflicts.

Here’s the scenario:
Yesterday, on your office computer, you changed a button’s color to "red" and pushed it to GitHub.
Today, on your home laptop, you forgot to git pull the latest changes and edited the same button to "blue."
When you happily type git push... Boom!

The terminal spits out red text: Merge conflict in src/app/page.tsx

GitHub is confused. Should the button be "red" (from the office) or "blue" (from home)? It rejects your push and forces you to decide.

Resolving Conflicts with Cursor’s Superpowers

Open the conflicted file page.tsx, and you’ll see terrifying gibberish:

<<<<<<< HEAD
<button class="bg-blue-500">Blue Button (home edit)</button>
=======
<button class="bg-red-500">Red Button (office edit)</button>
>>>>>>> origin/main

In the past, engineers had to manually delete the <<<< and ==== markers, often breaking the code.
But in Cursor IDE, opening the file reveals intuitive buttons:

Accept Current Change (keep the home’s blue version)
Accept Incoming Change (keep the office’s red version)
Accept Both Changes (keep both buttons)

Click one, and Cursor instantly cleans up the mess, merging the code perfectly!

Then, just run:
git add .
git commit -m "Resolved conflict"
git push

Conflict resolved! Crisis averted!

Conclusion: The Path to DevOps Mastery

After these five chapters, you’re no longer just a "code farmer."
You’ve mastered modern software engineering essentials: Git version control, GitHub cloud backups, Vercel auto-deployments, custom domain binding, and live disaster recovery.

With these tools, your projects aren’t just toys for your local machine—they’re commercial-grade products ready for real-world traffic.
Congratulations on completing this deployment series! Ready to announce your site to the world?

Why CI/CD and Git Conflict Resolution Matters

Every team using Git for deployment will encounter merge conflicts. They are a normal part of collaborative development. Knowing how to resolve them quickly and correctly is essential for team productivity.

Why this matters for your career:

Merge conflicts happen daily in team environments
Incorrect conflict resolution can delete code or break features
CI/CD pipelines prevent broken code from reaching production
Vercel preview deployments let you test changes before merging

CI/CD with Vercel

Vercel automatically deploys every Git branch:

| Branch | Deployment Type | URL | |--------|----------------|-----| | main | Production | https://myapp.com | | develop | Preview | https://develop-myapp.vercel.app | | feature/login | Preview | https://feature-login-myapp.vercel.app | | Any PR branch | Preview | https://pr-123-myapp.vercel.app |

Preview Deployment Workflow

Developer creates a branch (feature/login-form)
Developer pushes code to GitHub
Vercel automatically creates a preview deployment
Vercel posts the preview URL to the PR
Team reviews the live preview
PR is merged to main
Vercel deploys to production

Git Conflicts

What Causes Conflicts

A merge conflict occurs when two branches modify the same part of the same file in different ways.

Scenario:
- Branch main: README.md has "Welcome to My App"
- Branch feature/update: changes it to "Welcome to My Amazing App"
- Branch hotfix/fix-typo: changes it to "Welcome to My App!"

When merging both into main, Git cannot automatically decide which change to keep.

Conflict Markers

<<<<<<< HEAD
Welcome to My App!
=======
Welcome to My Amazing App
>>>>>>> feature/update

<<<<<<< HEAD: Start of the current branch's version
=======: Separator between the two versions
>>>>>>> feature/update: End of the incoming branch's version

Resolving

Read both versions
Decide which to keep or how to combine them
Edit the file to remove the conflict markers and keep the correct code
Save the file
git add <file>
git commit (completes the merge)

Preventing Conflicts

| Practice | How It Helps | |----------|-------------| | Pull main before creating a branch | Start from the latest code | | Keep branches short-lived | Less time = less chance of conflicts | | Communicate with teammates | Tell others about files you are working on | | Use smaller PRs | Fewer changes = fewer conflicts | | Rebase frequently | git rebase main keeps your branch up to date | | Use a monorepo tool (Nx, Turborepo) | Better dependency management | | Define code ownership | Different teams own different files |

Vercel CI/CD Integration

// vercel.json — configure CI/CD behavior
{
  "github": {
    "silent": true,  // Don't comment on every commit
    "autoJobCancelation": true,  // Cancel outdated deployments
    "deploymentEnabled": {
      "main": true,
      "develop": true,
      "preview": true
    }
  }
}

GitHub Actions + Vercel

name: Deploy to Vercel
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          working-directory: ./
          vercel-args: '--prod'

Best Practices

| Practice | Reason | |----------|--------| | Use preview deployments for every PR | Catch issues before merging | | Keep PRs small (under 400 lines) | Faster review, fewer conflicts | | Pull latest main before starting work | Start from the most recent code | | Resolve conflicts promptly | Stale branches cause more conflicts | | Use git rebase for feature branches | Cleaner history, easier conflict resolution | | Communicate with the team | Avoid overlapping work on the same files | | Review preview URLs in PR comments | See changes live before approving | | Cancel outdated deployments | Save build minutes and compute |

Summary

CI/CD with Vercel automatically deploys every branch. Preview deployments let you test changes before merging. Git conflicts arise when two branches change the same code — resolve them by editing conflict markers and committing. Prevent conflicts with short-lived branches, good communication, and frequent rebasing.

Key takeaways:

Vercel auto-deploys every branch (production for main, preview for others)
Preview deployments enable live testing before merge
Merge conflicts happen when two branches change the same file
Conflict markers: <<<<<<< HEAD / ======= / >>>>>>> branch
Resolve by editing, removing markers, then git add + git commit
Prevent conflicts: short branches, rebase, communicate, small PRs
GitHub Actions can automate Vercel deployments
Cancel outdated deployments to save resources

What's Next: Storage Limits and Packaging

The next chapter covers Vercel storage limits, serverless function size limits, and strategies for packaging your application efficiently.