After you've made your Project publicly available on your Domain of choice, it is time to begin making changes and evolve it further. Thanks to Vercel's automatic Deployments, this won't require any extra effort.
By default, if your Project is connected to a Git repository, Vercel will deploy every commit that is pushed to the Git repository, regardless of which branch you're pushing it to.
If you've created your Project from an existing Git repository or a Template, this connection was established for you automatically, so all you have to do is push commits, and you will start receiving links to Deployments right on your Git provider.
Whenever new commits are pushed to the Git repositories associated with your Vercel Projects, the last commit of every push will automatically trigger a new Deployment within that respective Project.
For every branch, Vercel then provides an Automatic Branch URL that reflects the latest pushes to that branch. In a pull request, it will then show it like this:
What you see next to the word "Inspect" is a page you can visit to see the detailed progress of your Deployment, before it finishes.
All URLs will continue to exist forever, so you can use them as a way to retroactively understand what changes you've made in the past. It's essentially a revision history that will never cease to exist.
If you want to, you can learn more about the concept of Git on Vercel.
Regardless of which branch you're pushing to, the Deployments you will receive are Preview Deployments, which can be used for previewing changes before delivering them to visitors, as the name suggests.
The only exception is the Production Branch. Any pushes to this branch will result in Production Deployments, which are delivered to visitors. Therefore, be careful which changes you make to that branch.
Visit the Project on the dashboard to see which Production Branch is configured for it:
If needed, you can also configure a custom Production Branch, in the case that the default one doesn't suit your needs.
In general, it is recommended to never push directly to the Production Branch. Instead, push to other branches, create pull requests for those branches, let your team review them, and then merge them onto the Production Branch.
Once merged, your changes will then be served to your visitors.
If you want to, you can learn more about the concept of Environments on Vercel.
If the case that your Vercel Project was created via the command-line or if you'd simply like to update it from here going forward, you can use Vercel CLI — the official command-line interface for interacting with the platform.
Once you've installed Vercel CLI, you can use it to make changes to your Project by issuing new Deployments, or manage other resources like Domains and DNS Records — all without leaving your terminal.
To create a new Deployment, for example, run the following command in the directory that contains your Project's source code:
The first time you run it, you will be prompted to link your local directory with a Vercel Personal Account or Team, and then select a Project:
Subsequent runs will then use the same configuration.
Running the above command will create a Preview Deployment, which you can use for testing changes before delivering them to visitors.
If you're comfortable with making your changes available to everyone, you can then proceed with creating a Production Deployment like so:
From here on out, you can repeat this process whenever you want to update your application: Preview your changes, then ship them to Production.
Regardless of whether you're receiving automatic Deployments on your Git repository (which is recommended), Vercel CLI is useful for quick one-off Deployments in cases where you need to test something, or show a small change to someone quickly.
But it also works as a primary way of deploying: If you don't want to use Vercel for Git, you can use purely the command-line interface.
If you want to, check out the Vercel CLI reference to learn more about it.
Continue getting started on Vercel: