---
title: "Save Your First Edit"
description: "Check the heading edit with git diff and git status. Learn how staging and commits work as you save the change with git add and git commit, then publish through GitHub with git push."
canonical_url: "https://vercel.com/academy/build-and-launch-with-ai/save-your-first-edit"
md_url: "https://vercel.com/academy/build-and-launch-with-ai/save-your-first-edit.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-09-25T16:42:53.761Z"
content_type: "lesson"
course: "build-and-launch-with-ai"
course_title: "Build and Launch with AI"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Save Your First Edit

# Save your first edit

The heading looks right locally. Before publishing, we'll review the edited lines and save a Git commit that records the change. Its identifier will let us check which version reaches the live site.

Use a second terminal in the website folder. Keep the development server running in its original window:

```sh
cd ~/projects/small-hours-studio
git status
git diff
```

`status` lists changed files. `diff` shows the edited lines, with removed lines marked `-` and added lines marked `+`. If the output opens in a scrolling viewer, press `q` to return to the prompt.

## Outcome

Review the heading edit, save it as a Git commit, and verify its deployment through GitHub.

## Hands-on exercise 2.5

### Review the change

Look for the heading file from 2.4. In the reference app, it is `app/page.tsx`. The diff should show the change from “Make time” to “Make something with your own hands.”

If other files appear, inspect them before continuing. A dependency installation or editor extension may have changed something else. We can leave unrelated work unstaged while saving this heading, but we need to understand any change that could affect the page we're testing.

A *commit* is a saved change in the repository's history. It has an identifier and a message describing the work. Git first collects the changes selected for that commit in a *staging area*. This lets us choose what belongs together.

### Set the author identity

Git records an author name and email with each commit. These settings are separate from the GitHub sign-in we completed earlier. Check the current values:

```sh
git config user.name
git config user.email
```

If a command prints nothing, that setting hasn't been configured for this repository. Use your preferred name and an email associated with your GitHub account. GitHub's **Settings → Emails** provides a private no-reply address if you don't want your personal address in commit history.

Set the identity for this repository, replacing the example values with yours before running:

```sh
git config --local user.name "YOUR NAME"
git config --local user.email "YOUR GITHUB COMMIT EMAIL"
```

`--local` limits the setting to this project. Don't use the literal example text as your identity. Check the two values again before making the first commit.

### Select and save the heading

Stage the file containing the heading. The reference path is below; substitute `src/app/page.tsx` or the component path you found if needed:

```sh
git add app/page.tsx
git diff --cached
```

`git add` selects the file's current changes. `git diff --cached` shows what the next commit will contain. Review this output even if we already reviewed the unstaged diff; a file can change again after it is staged.

If the selection contains the intended heading edit, save it:

```sh
git commit -m "feat(home): clarify the workshop heading"
git status
git log -1 --oneline
```

The message describes the visible change. The log prints the new commit's identifier beside that message. Copy the identifier into your notes so we can compare it with the deployment.

### Publish through the connected repository

Before pushing, open the existing Vercel project from Section 1. In its Git settings, confirm the connected repository is this website and note the **Production Branch**. Compare it with `git branch --show-current` locally.

For this personal course project, the current branch should be the production branch we cloned in 2.2, usually `main`. A push to that branch can trigger a production deployment. If the project uses protected branches or required reviews, follow its pull-request process; don't remove those rules for the exercise.

When the branch and repository match the intended destination, send our saved commit to GitHub:

```sh
git push
git status
```

A *push* uploads commits. Vercel then builds the connected branch and deploys the result. These are separate operations: a successful push can still be followed by a failed deployment. The [Vercel Git integration](https://vercel.com/docs/git) connects those steps.

## Try It

Open the repository on GitHub and find the heading commit. Then open the Vercel deployment triggered by that commit. Compare its source identifier with the one we recorded, and wait for a successful deployment before checking the production URL.

Refresh the production homepage. The new heading should appear, and the catalog link should still reach both workshops. Keep the deployment page available if the website still shows older content.

### Git asks for authentication or rejects the push

Check `gh auth status`. Repeat the browser authentication from 2.2 if necessary, then run `gh auth setup-git --hostname github.com`. A branch-protection rejection needs the repository's review workflow. A non-fast-forward rejection means remote history has changed; inspect it before combining work. Don't force-push to clear either error.

### GitHub has the commit, but the website is unchanged

Check the Vercel repository connection, production branch, and deployment status. Open the deployment for this exact commit. A build error needs a code or configuration fix before production can update; refreshing the browser won't repair it.

## Commit

The commit for this lesson is `feat(home): clarify the workshop heading`. We already created and pushed it above. There's no need for another commit.

## Done-When

- [ ] The saved commit contains the intended heading edit.
- [ ] Its author identity is correct.
- [ ] GitHub and the successful Vercel deployment reference that commit.
- [ ] The production homepage displays the heading and working catalog link.

## Solution

For the reference file, the reviewed sequence is:

```sh
git diff
git add app/page.tsx
git diff --cached
git commit -m "feat(home): clarify the workshop heading"
git push
```

Run it only once, after setting the author identity and checking the connected production branch. Match the deployment to the commit identifier, then check the heading on the published site.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)