Deploy Website Updates from GitHub with Netlify

How GitHub and Netlify Work Together

When you connect a GitHub repository to Netlify, every commit becomes a website update. The repository stays the source of truth (the main copy of the site). You, a teammate or a script commits a change. Netlify sees the change, builds the site if it has a build step, and publishes the result. Pull requests get their own preview address before anything reaches the live site.

The connection runs in one direction. Netlify reads the repository and deploys it. It never writes files back to GitHub. Make every change in Git, and treat the live site as output.

Choose the Setup That Matches Your Starting Point

Starting point	What to do first	Result
The site is already in a GitHub repository	Import it into Netlify directly	Each push to the chosen branch deploys the site
The site is a folder on your computer	Create a GitHub repository and add the files	You get version history. Then you connect it as above
The site runs on GitHub Pages today	Import the same repository into Netlify, then move your domain	GitHub stays the source, and Netlify serves the site

Before You Start

You need:

• A GitHub account with access to the repository, and permission to install apps on it. In some organizations, an owner must approve the Netlify app.
• A Netlify account.
• To know whether the site needs a build step. Plain HTML, CSS and JavaScript files do not need one. A site made with a framework or a static site generator (a tool that builds HTML pages from templates) usually does. For that site, you need its build command and output folder.
• A list of the environment variables (named settings that the build reads) that the build needs, such as an API base URL. Keep secret values out of the repository.

1. Put the Site in a GitHub Repository

If the code is already on GitHub, skip this step.

1. On GitHub, create a new repository. A private repository is fine. Netlify can deploy a private repository if you give Netlify access to it.
2. Add the site files. In the browser, open the repository and select Add file > Upload files. Drag in the files and commit them. GitHub limits browser uploads to 25 MiB per file and 100 files at a time (GitHub’s upload guide). For larger projects, push from your computer with Git or GitHub Desktop.
3. Add a .gitignore file that excludes node_modules/, build output folders and .env files. Then dependencies, generated files and secrets stay out of the repository.

For a plain HTML site, put index.html at the root of the repository. Or put it in a clearly named folder such as site/.

2. Import the Repository Into Netlify

1. In your Netlify team dashboard, select Add new project > Import an existing project.
2. Choose GitHub as the Git provider. Follow the authorization prompts.
3. When GitHub asks where to install the Netlify app, choose all repositories or only the ones that you select. The tidier choice is to select only this repository.
4. Pick the repository from the list.

If the repository does not appear, you probably did not give Netlify access to it when you installed the app. Select Configure Netlify on GitHub in the empty list, or change the app’s repository access in your GitHub app settings. Netlify’s repository linking guide covers organization repositories and other edge cases.

3. Set the Build Settings

Netlify tries to detect the framework and fill in the settings. Before the first deploy, make sure that these settings are correct. A wrong publish directory is the most common reason for a blank page or a 404 on a first deploy.

Field	What it means	Plain HTML site	Typical framework site
Base directory	Where Netlify installs dependencies and runs the build	Leave empty (repository root)	Leave empty unless the site is in a subfolder
Build command	The command that produces the finished files	Leave empty	For example npm run build
Publish directory	The folder that holds the finished HTML and assets	The folder with index.html, or the root	The generator’s output folder

Common output folders are dist for Vite and Astro, public for Hugo, and _site for Jekyll and Eleventy. Netlify’s build configuration overview defines each field. Netlify does not deploy files outside the publish directory.

You can also keep these settings in a netlify.toml file at the root of the repository. Then the settings stay with the code:

[build]
  command = "npm run build"
  publish = "dist"

Settings in netlify.toml override the ones in the Netlify interface. If you change a setting in the dashboard and nothing happens, look at this file first.

Add environment variables during setup, or later in the project settings. Then start the first deploy. In Netlify’s import guide, the button reads Deploy site.

The production branch is the branch whose commits go live. To change it later, go to Project configuration > Developer settings > Continuous deployment > Branches and deploy contexts. Select Configure.

4. Test the First Deploy

Open the deploy from the project’s Deploys list. Read the log. A successful deploy ends with the site published at an address such as your-project.netlify.app.

Then test the live site:

• Open the home page, a nested page and a page that loads images, CSS and JavaScript.
• Open the browser’s developer tools and look for failed requests in the Network panel.
• Test the forms and API calls that the site makes.
• Make sure that the deploy used the commit that you expect. The deploy summary shows the commit and branch.

Netlify’s repository quickstart notes a team setting called “private by default”. If your team turned it on, a new project starts private. Only your team can open it until you change its visibility. Before you send the link to anyone, make sure that the visibility is correct.

How Updates Flow After Setup

The deploy overview describes three kinds of deploys for a linked repository:

• A production deploy runs at every merge or push to the production branch. It builds and publishes the live site.
• A Deploy Preview runs for every pull request. It gives the pull request its own build at an address such as deploy-preview-42--your-project.netlify.app. With it, you can review a change before you merge it. Netlify also reports the deploy status on the pull request through GitHub checks.
• A branch deploy gives a branch such as staging its own address, for example staging--your-project.netlify.app. Branch deploys are off by default. To turn them on, go to Project configuration > Developer settings > Continuous deployment > Branches and deploy contexts. Then select Configure.

Deploys are atomic (all or nothing). The new version goes live only after all of its files upload. Visitors never see half an update.

To test the update cycle, make a small visible change, such as a word in the footer. Commit it to the production branch. Watch the new deploy appear in the Deploys list. When it finishes, reload the live site.

Roll Back or Pause a Bad Change

Netlify keeps every successful deploy. If a commit breaks the site, open an earlier deploy from the Deploys list. Select Publish Deploy. The rollback is instant, because Netlify does not build anything again (managing deploys).

If auto publishing is on, the next push to the production branch replaces the rolled-back version. To stop that while you fix the code, select Lock to stop auto publishing on the Deploys page. New commits still build. But none goes live until you turn auto publishing back on from the same page, or publish one by hand.

The cleaner long-term fix is still a new commit. Revert the bad change in Git, so that the repository and the live site agree again.

Keep Secrets Out of the Repository and the Browser

• Store API keys and tokens as environment variables in Netlify, not in the repository. Values that you write in netlify.toml are in the repository, like any other file.
• Every visitor can read anything that your build puts in client-side JavaScript, from any source. Keep secret keys in serverless functions (server code that the host runs on request), not in the browser bundle.
• Before the first commit, make sure that .gitignore lists .env files and private notes. If you remove a secret in a later commit, the secret stays in Git history.

Common Workflows

Move from GitHub Pages without leaving GitHub

Import the repository into Netlify. Test the deploy at its netlify.app address. Then move your custom domain and switch off GitHub Pages. The repository, its history and your editing workflow stay the same. The GitHub Pages to Netlify guide has the full checklist.

Let a script or an AI coding agent update the site

Give the tool write access to the repository, not to the hosting account. Have it commit to a branch and open a pull request. You review the Deploy Preview and merge the pull request when it looks right. Then Netlify publishes the site. If an error gets through, roll back in Netlify and revert in Git.

Let developers and content editors use different tools

Developers work with branches, pull requests and local editing tools. Content editors can change Markdown or HTML files directly in GitHub’s web editor. Both paths end in a commit, and each commit starts the same deploy.

Checklist Before You Share the Site

• The production branch and publish directory are the ones that you intended.
• The live site loads CSS, JavaScript, images and nested pages.
• A test commit produced a new deploy with the expected commit.
• No .env files, tokens or private material are in the repository.
• The project’s visibility matches the audience: public for a public site, protected for a client preview.

For client work, set up Netlify access protection before you send preview links.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.