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:

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:

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:

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:

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:

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:

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 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.

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:

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.