Vercel

Connect GitHub And Deploy Automatically

Vercel becomes much more useful when it is connected to a GitHub repository. Instead of uploading files manually or running a deployment command from your own machine, you push code to GitHub and let Vercel build a deployment from that commit. A push to the production branch can create a Production Deployment. A pull request or feature branch can create a Preview Deployment. That workflow turns deployment into part of normal source-control practice.

This lesson builds on the static site from the previous lesson. The site is still intentionally simple: index.html, styles.css, and app.js. The new skill is Git-based CI/CD. CI/CD means the platform responds to source-control changes, builds the project, reports status, and makes a deployable result available without a manual upload step each time.

The important warning from earlier lessons still applies. Use a personal, non-commercial project while learning. Do not connect a client, employer, paid, ad-supported, or production business project to your personal Hobby account unless the current Vercel plan terms, billing ownership, and organization ownership are correct.

The Git-Based Deployment Model

A Git-based Vercel deployment starts with a repository. Vercel installs or uses a Git integration, reads the selected repository, detects or receives build settings, and creates deployments when relevant Git events happen.

For a beginner project, the model looks like this:

GitHub repository
  main branch
  feature branches
  pull requests

Vercel project
  connected to the repository
  production branch: main
  build command: none for this static site
  output directory: project root

Deployments
  push to main -> Production Deployment
  pull request -> Preview Deployment
  branch push -> Preview Deployment

That model is more disciplined than manual uploads. The deployed site corresponds to a commit. The deployment has logs. The pull request can show whether Vercel built the change successfully. A reviewer can open the preview URL and test the exact code under review.

This is why Vercel is not only a host. It is also part of the delivery workflow.

Prepare The Repository

Start with the static site from the previous lesson. The folder should contain only public files meant to be deployed:

vercel-static-first-site/
  index.html
  styles.css
  app.js

Initialize Git locally if you have not already done so:

git init
git add index.html styles.css app.js
git commit -m "Create first static site"

Create a GitHub repository for the exercise. Keep it personal and non-commercial. If the repository is public, remember that everyone can read the source files. If it is private, Vercel still needs permission to read it through the GitHub integration.

Connect your local repository to GitHub and push the production branch:

git remote add origin https://github.com/your-user/vercel-static-first-site.git
git branch -M main
git push -u origin main

Replace the remote URL with your actual repository URL. Do not paste a token into the remote URL. Use GitHub's normal authentication flow, GitHub CLI, a credential manager, or SSH keys according to your local setup.

Before connecting Vercel, check that GitHub contains only files you intend to publish. Do not push .env, API keys, customer data, private screenshots, certificates, database exports, or raw client assets. Git history matters: deleting a secret in a later commit does not automatically remove it from earlier history.

Import The Repository Into Vercel

In the Vercel Dashboard, create or import a project from GitHub. If this is your first GitHub connection, Vercel will ask to install or authorize its GitHub integration. Grant access deliberately. For a learning exercise, prefer selecting only the repository you need instead of granting broad organization access.

When Vercel imports the project, confirm the settings:

Repository: your GitHub static site repository
Production branch: main
Framework preset: Other
Build command: empty / skipped
Output directory: root directory
Install command: not needed for this plain static project

The exact dashboard labels can change. The intent should not: this project has no package installation and no build step. Vercel should serve the root files directly.

After import, Vercel creates a deployment for the current production branch. Open the deployment URL and verify the same checks from the previous lesson: HTML loads, CSS applies, JavaScript works, and no private files are present.

Push To Deploy

Now make a small visible change. Edit the paragraph in index.html:

<p>This page deploys automatically when main changes.</p>

Commit and push:

git add index.html
git commit -m "Update deployment message"
git push

Because the repository is connected to Vercel and main is the production branch, Vercel should create a new Production Deployment. Open the Vercel project dashboard and look for the new deployment. When it finishes, open the production deployment URL or project URL and confirm the text changed.

This is the central habit: do not assume push worked because Git accepted the commit. Check the Vercel deployment status and the deployed page. Git stores the change; Vercel builds and serves it.

Use Pull Requests For Preview Deployments

A production branch should stay releasable. For most real work, create a branch, make a change, open a pull request, and review the Preview Deployment before merging.

Create a branch:

git switch -c update-button-copy

Edit index.html or app.js with a harmless change. For example, change the button label:

<button id="check-button" type="button">Test deployed JavaScript</button>

Commit and push the branch:

git add index.html
git commit -m "Clarify button label"
git push -u origin update-button-copy

Open a pull request from update-button-copy into main on GitHub. Vercel should create a Preview Deployment for the pull request and report deployment status back to GitHub. The GitHub integration can add checks, deployment statuses, and comments with preview information depending on the project and permissions.

Open the preview URL from the pull request or Vercel dashboard. Verify the changed button label there. The production site should not change until the pull request is merged into the production branch.

That separation is the point. Preview Deployments let you review work without using production as the test environment.

Understand The Production Branch

Vercel projects have a production branch. It is often main, but projects can choose a different branch. When code reaches that branch, Vercel treats the result as production and creates a Production Deployment.

The production branch should be boring. It should contain code that has already been reviewed, built, and tested enough for the project. For a course exercise, you might push directly to main because the risk is tiny. For real work, especially client or business work, use branches and pull requests.

A healthy small-team flow looks like this:

main
  current production source

feature/contact-form
  work in progress
  creates Preview Deployments
  reviewed through pull request
  merged into main when ready

If a project uses develop, release branches, or another workflow, configure Vercel deliberately. Do not rely on a branch name by accident. The team should know which branch creates production deployments and who can merge into it.

What Vercel Reports Back To GitHub

The GitHub integration is useful because deployment information appears near the code review. A reviewer does not need to hunt through a separate dashboard before they can test the change. The pull request can show whether the Vercel build passed, whether a preview exists, and which deployment URL to open.

Those signals are not the same as a complete test suite. A successful Vercel deployment means the project built and deployed according to its settings. It does not prove the design is good, the copy is correct, the form sends email, the API authorization is safe, or the business rules are right.

Use Vercel's status as one review input:

GitHub checks: Vercel deployment passed
Preview URL: opened and tested by reviewer
Code review: completed
Manual smoke test: page loads, interaction works
Merge decision: reviewer approves and branch is merged

For larger projects, combine Vercel with GitHub Actions, tests, linting, typechecks, accessibility checks, and deployment checks. Vercel is one part of the delivery evidence.

Permissions And Repository Access

Connecting GitHub gives Vercel permissions to read repository content and react to GitHub events. Official Vercel GitHub documentation lists permissions such as reading contents, adding checks, synchronizing deployments, reacting to webhooks, and commenting on pull requests. Those permissions exist so Vercel can build and report deployments, but they should still be granted thoughtfully.

For personal learning, connect only the repository you need. For organization work, use the organization's normal approval process. A team should know who installed the integration, which repositories it can access, and who can change that access.

Be especially careful with private repositories. A private repository may contain code, names, internal URLs, or configuration that should not be widely visible. Vercel needs enough access to deploy it, but preview URLs, logs, environment variables, and team membership still need review.

If you receive pull requests from forks, Vercel may require authorization before deploying them. That protection exists because untrusted fork code could otherwise try to expose sensitive information during a build. Treat forked pull request deployments as a trust decision, not as a harmless button.

Common Git Deployment Mistakes

The first mistake is connecting the wrong repository. If the Vercel project points at an old test repo, pushing to your current repo will do nothing. Check the repository name in the Vercel project settings.

The second mistake is expecting production to update from the wrong branch. If Vercel's production branch is main and you push to feature/homepage, you should expect a Preview Deployment, not a Production Deployment.

The third mistake is ignoring failed builds. A failed Vercel build is evidence. Open the build log, read the first meaningful error, and fix the underlying problem. Do not keep pushing random commits without understanding the failure.

The fourth mistake is committing secrets because the repository is private. Private repositories still feed build systems, collaborators, logs, and integrations. Secrets belong in Vercel Environment Variables or another appropriate secret system, not in Git.

The fifth mistake is using a personal account for someone else's production project. GitHub, Vercel, billing, domains, and credentials should be owned by the organization responsible for the project.

A Safe First Git Workflow

For a learning deployment, this is enough:

1. Create a personal GitHub repository.
2. Push the static site to main.
3. Import the repository into Vercel.
4. Confirm main is the production branch.
5. Verify the first Production Deployment.
6. Create a feature branch.
7. Open a pull request.
8. Verify the Preview Deployment.
9. Merge when ready.
10. Verify the new Production Deployment.

That workflow teaches the shape of modern deployment without requiring a framework. Later lessons will add environment variables, production versus preview configuration, custom domains, routing rules, and server-side functions. The Git habit stays the same: change code in a branch, review the preview, merge intentionally, and verify production.

Review Questions

  • What does Vercel do when a connected GitHub production branch changes?
  • Why are pull request Preview Deployments useful?
  • Why should the production branch be chosen deliberately?
  • What deployment information can Vercel report back to GitHub?
  • Why is a successful Vercel deployment not the same as a complete code review?
  • Why should client or employer projects use the correct organization-owned GitHub and Vercel accounts?

Official References