Git Workflow for Deployment

1. What We Are Learning

This lesson's goal is to apply the Git workflow (commit, push) to save updates and trigger a new deployment.

You'll learn how to take the changes you've approved locally, save them permanently into your project's history, and send them off to the cloud, which will automatically update your live website. This is the final and most rewarding step in our development loop.

2. Why This Matters

This workflow is the heartbeat of modern software and web development. Understanding it is crucial for managing any project, no matter the size.

Let's use a design analogy you're very familiar with: working with a shared Figma library.

• Editing files locally: This is like editing a component in your personal draft file in Figma. The changes are just for you, for now.
• git commit: This is like using Figma's Version History to save a snapshot with a specific name (e.g., "v2.1 - Updated primary button style"). You are creating a permanent, named save point on your own machine that you can always look back on or revert to.
• git push: This is the equivalent of clicking Publish changes on your Figma library. You're sending your saved versions (your commits) to the central, shared location (GitHub). This makes your updates available to the rest of the team and, crucially for us, to our deployment service.
• Automatic Deployment: This is where the magic happens. When our deployment service, Vercel, sees that you've "published" an update to GitHub, it automatically grabs the new version, rebuilds your website, and updates the live URL. It's as if publishing a Figma library update would instantly update the live, clickable prototype that your stakeholders are viewing.

To get a clearer picture of this flow, let's establish a mental model. During this process, your code moves between four distinct places.

Here is a diagram that visualizes that exact process:

3. Step-by-Step Instructions: From Local Edit to Live Site

Let's walk through the entire process, using the friendly interface of VS Code.

First, make sure you have a change to save.

1. Open your project in VS Code.
2. Open index.html.
3. Find the main headline (<h2> from our last exercise) and change the text to something new. For example: "My First Live Website Update!".
4. Save the file (Cmd+S or Ctrl+S). You'll see the change in your local Live Server preview.

Now, let's save and deploy this change.

Step 1: Stage Your Changes (Working Directory → Staging Area)

Staging is the act of selecting which changes you want to include in your next save point.

1. In the Activity Bar on the left, click the Source Control icon (it looks like a branching path).
2. You'll see index.html listed under a "Changes" section. This means the file has been modified in your Working Directory.
3. Hover over the index.html file name and click the + (Stage Changes) icon.
4. The file will move up to a new section called "Staged Changes". It is now in the Staging Area, ready to be saved.

Why do we stage? It gives you control. Imagine you've edited three files but only want to save the changes for one of them as a single, logical update. Staging lets you do just that.

Step 2: Commit Your Changes (Staging Area → Local Repository)

A "commit" is the act of creating that permanent snapshot (the named version) in your local history.

1. At the top of the Source Control panel, you'll see a Message box. This is where you name your version. It's a critical habit to write clear, concise commit messages describing what you changed.
2. Type a message like: Update hero section headline.
3. Click the Commit button (the checkmark icon).

The file will disappear from the Staged Changes area. You have now successfully created a commit in your Local Repository. Your change is saved safely on your machine.

To reinforce this, let's look at how to perform these same steps in a guided video.

Step 3: Push Your Commit (Local Repository → Remote Repository)

Your commit is saved locally, but GitHub and Vercel don't know about it yet. We need to "push" it to the cloud.

1. Look at the bottom-left of your VS Code window in the blue status bar. You should see an icon with circular arrows and a number next to an up arrow (e.g., ↑ 1). This tells you that you have 1 local commit that is ready to be pushed to the remote repository.
2. Click that button. It may say "Sync Changes" or "Publish Changes".
3. A dialog might pop up asking for confirmation. Click OK.

VS Code will now upload your new commit to your repository on GitHub.

Step 4: Watch the Automatic Deployment

This is the payoff. Because you connected Vercel to your GitHub account, your push just triggered a new deployment.

1. Open your Vercel dashboard in a browser.
2. Click on your project.
3. You should see a new deployment at the top of the list with a status of "Building".

This process is explained very clearly in the Vercel documentation.

After a minute or two, the status will change to "Ready". Now, open your live website URL. Congratulations, your change is live!

4. What Could Go Wrong

• Push fails / "Sync Changes" is needed.

  • Reason: This is the most common issue. It happens when the remote repository on GitHub has changes that your local machine doesn't have yet. Git stops you from pushing to prevent you from accidentally overwriting someone else's work.
  • Fix: VS Code makes this simple. If you see numbers next to both the up and down arrows in the status bar (e.g., ↓ 1 ↑ 1), it means you need to sync. Just click the Sync Changes button. This will first pull (download) the remote changes and merge them with your local work, and then push your changes up. This pull-then-push is the normal rhythm of collaborative work.

• You made a typo in your commit message.

  • Reason: You clicked "Commit" too fast.
  • Fix: If you haven't pushed yet, you can easily amend it. In the Source Control panel, click the ... (three dots) menu, go to Commit > Amend. This will let you edit the message of your very last commit. If you've already pushed, it's best to just leave it. Correcting it is an advanced topic.

5. Mini Exercise

Let's practice the full loop one more time.

1. Open your styles/style.css file.
2. Change the background-color of the body to a different color, like lightgoldenrodyellow. Save the file.
3. Go to the Source Control panel.
4. Stage the styles/style.css file by clicking the +.
5. Write a clear commit message: Change page background color.
6. Click Commit.
7. Click the Sync Changes button in the status bar to push your commit.
8. Open your Vercel dashboard and watch the deployment process.
9. Once it's "Ready", open your live URL and admire your new background color!

6. Checklist Before Moving Ahead

Please confirm you can do the following:

• I understand that commit saves a snapshot of my work locally, and push sends those saved snapshots to GitHub.
• I can use the VS Code Source Control panel to stage, commit, and push a change.
• I understand that pushing a commit to my main branch on GitHub is what triggers a new deployment on Vercel.
• I know where to look in my Vercel dashboard to see if a deployment is building or ready.

Conclusion

You've done it! You have now completed the entire, end-to-end modern development workflow: making a local change, saving it with version control, and deploying it to a live website. This commit-and-push cycle is the fundamental process you'll use to update your site from now on.

In our next lesson, we'll discuss strategy. Now that you know how to regenerate code with AI and how to make minor edits manually, we'll learn how to distinguish between situations that require full regeneration vs. minor manual edits. This will help you become even more efficient as you build out your landing page.