Ship Your Portfolio with GitHub

Build a portfolio page and learn the GitHub Flow used by real dev teams.

Introduction

30 Second Summary

Every group project has the same problem. Multiple people editing the same files leads to overwritten work, lost changes, and nobody knowing who did what.

In this project, you will build a personal portfolio page and manage it using Git and GitHub. You will follow the same professional workflow that dev teams use every day to collaborate safely on code.

What You'll Build

Picture opening your GitHub profile and showing an employer a real repository with meaningful commits, a merged pull request, and a portfolio page they can click through.

By the end of this project, you'll have:

  • A portfolio page you can open in your browser and view the source code on GitHub.
  • A commit history that tells the story of your changes, showing exactly how you built your page step by step.
  • A merged pull request proving you know how to propose, review, and approve changes the professional way.
  • A GitHub profile with real activity (commits, branches, merged PRs) visible to employers.
  • Secret Mission: Create and resolve a merge conflict like a pro.

Do I need anything before I start?

You need a GitHub account and Git already installed on your computer. Both are free.

This project walks you through installing VS Code and configuring Git with your identity in Step 1. No other setup is needed.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up VS Code and Configure Git

Git needs to know who you are before it can label your commits.

VS Code gives you a single place to edit code and run terminal commands. In this step, you will install VS Code and tell Git your name and email so every commit carries your identity.

In this step, get ready to:
  • Install VS Code and open the integrated terminal.
  • Configure your Git identity (name and email).
  • Verify the configuration works.
Download and install VS Code
  • Download VS Code from the official site by visiting:
https://code.visualstudio.com
  • Click the download button for your operating system.
  • Run the installer once the download finishes.

Windows

  • On the Select Additional Tasks screen, check the box that says Add to PATH (requires shell restart).
  • Click Next through the remaining screens and click Install.

Why add to PATH?

Adding VS Code to your PATH lets you open it from the terminal by typing code. This is handy when you want to open a project folder quickly.

macOS

  • Open the downloaded .dmg file and drag VS Code into your Applications folder.

Adding VS Code to PATH on macOS

After VS Code launches, press Cmd+Shift+P to open the Command Palette. Type Shell Command: Install 'code' command in PATH and press Enter. This lets you open VS Code from the terminal later.

  • Open VS Code by pressing Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Visual Studio Code and press Enter to launch it.

You should see the VS Code Welcome tab appear. That confirms the installation worked.

VS Code not showing up in search?

On Windows, try restarting your computer so the PATH update takes effect. On macOS, make sure you dragged VS Code into the Applications folder (not your Downloads).

Still stuck? Help me open VS Code after installing it.

Configure your Git identity

Every Git commit records who made the change. You need to tell Git your name and the email address linked to your GitHub account so your commits match your profile.

  • Open the integrated terminal in VS Code by clicking Terminal in the top menu bar, then clicking New Terminal.

A terminal panel appears at the bottom of VS Code. This is where you will run all your Git commands.

  • Set your name by running this command:
git config --global user.name "[[YOURNAME="Your Name"]]"
  • Set your email by running this command (use the same email address that is on your GitHub account):
git config --global user.email "[[GITHUB_EMAIL="your-github-email@example.com"]]"

What do these commands do?

The --global flag saves these settings for every Git project on your computer. Your name and email will appear in the log every time you make a commit.

Using the same email as your GitHub account means GitHub can link your commits to your profile. This is how employers see your green activity squares.

Verify the configuration

Before you run the next command, what do you think it will print back?

  • Check that Git saved your identity by running:
git config --global --list

You should see your name and email printed back in the output, looking something like this:

user.name=Your Name
user.email=your-github-email@example.com

Not seeing your name or email?

If the output is empty or missing your details, re-run the two git config commands above. Make sure you include the --global flag and wrap your name in quotes.

Help me fix my git config output.

Your editor is ready and Git knows who you are. Next up, you will create your first repository on GitHub and push real code to it.

Create Your Repository and First Page

Your Git identity is configured and ready to label every change you make. Now you need somewhere to store those changes.

A repository is the container that holds your project's files and remembers every version of them. In this step, you will create one on GitHub, clone it to your computer, build your first portfolio page, and push it back up to prove the full round trip works.

In this step, get ready to:
  • Create a public repository on GitHub and clone it to your machine.
  • Build a portfolio page with a styled header section.
  • Push your code to GitHub and confirm it arrived.
Create a repository on GitHub and clone it locally

You need a remote home for your code before you start writing it. Creating the repository on GitHub first means you get a ready-made remote that your local copy can push to.

  • Open your browser and go to github.com. Sign in to your account.
  • Click the + icon in the top-right corner of the page.
  • Select New repository from the dropdown.
  • In the Repository name field, type my-portfolio.
  • Leave the visibility set to Public.
  • Check the Add a README file checkbox.
  • Click Create repository.

GitHub takes you to your new repository page. You should see a single README.md file listed.

What is a repository?

A repository (or "repo") is a folder that Git tracks. It stores every file in your project along with the complete history of changes. The version on GitHub is the "remote" copy. The one on your computer is the "local" copy.

  • Switch back to VS Code and open the integrated terminal by clicking Terminal in the top menu bar, then New Terminal.
  • Move to your Desktop by running this command:
cd ~/Desktop
  • Clone your repository to your computer by running this command:
git clone https://github.com/[[GITHUB_USERNAME="YOUR-USERNAME"]]/my-portfolio.git
  • Move into the new folder by running:
cd my-portfolio
  • Confirm the clone worked by running:
ls

You should see README.md listed in the output. That file came from GitHub when you cloned.

Not seeing README.md?

  • Make sure you checked Add a README file when creating the repo. If you missed it, delete the repo on GitHub (Settings > Danger Zone > Delete) and recreate it with the checkbox ticked.
  • Double-check the clone URL matches your GitHub username exactly. A typo in the URL gives a "not found" error.
  • help me fix my git clone
Build the HTML structure of your portfolio page

With the repository cloned, you can start adding files. Your portfolio page starts with a simple HTML skeleton that shows your name and tagline.

  • In VS Code, click File in the top menu bar.
  • Click Open Folder.
  • Navigate to your Desktop and select the my-portfolio folder, then click Select Folder.

Seeing a trust prompt?

VS Code may show a banner or dialog asking if you trust the authors of the folder. Since you created this repository yourself, click the Trust button to enable full functionality.

  • In the Explorer panel on the left, right-click in the empty space below README.md.
  • Select New File and name it index.html.
  • The file opens in the editor. Paste the following HTML structure into it:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Portfolio</title>
</head>
<body>
    <header>
        <h1>Your Name</h1>
        <p>Aspiring Developer | Learning Every Day</p>
    </header>
</body>
</html>

What does this code do?

  • The <!DOCTYPE html> line tells the browser this is a modern HTML5 page.
  • The <header> section contains your name and a short tagline. This is what visitors see first.
  • The <meta viewport> tag makes the page look correct on mobile devices.
  • Save the file by pressing Ctrl+S.
  • Open index.html in your browser. In the VS Code terminal, run:
start index.html

You should see your name and tagline displayed as plain, unstyled text. The page works, but it looks bare.

Browser didn't open?

  • Make sure your terminal is inside the my-portfolio folder. Run pwd to check your current location.
  • If start does not work, you can right-click index.html in the VS Code Explorer and select Reveal in File Explorer, then double-click the file from there.
  • help me open my HTML file in a browser
Add styles to your portfolio header

The plain text works, but a portfolio should look polished. Adding CSS inside a <style> block gives the header a dark background, centered text, and clean typography.

  • In index.html, find the line that says <title>My Portfolio</title>.
  • Directly below that line, paste the following style block:
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }
        body {
            font-family: Arial, sans-serif;
            line-height: 1.6;
            color: #333;
        }
        header {
            background: #2c3e50;
            color: white;
            text-align: center;
            padding: 60px 20px;
        }
        header h1 {
            font-size: 2.5rem;
            margin-bottom: 10px;
        }
        header p {
            font-size: 1.2rem;
            color: #bdc3c7;
        }
    </style>

What do these styles do?

  • The * reset removes default browser spacing so your layout starts from a clean slate.
  • The header styles create a dark navy background with white centered text and generous padding.
  • The header p rule makes the tagline a lighter grey so it sits comfortably beneath your name.
  • Save index.html with Ctrl+S.
  • Switch to your browser and refresh the page.

You should now see a dark navy banner filling the top of the page with your name in large white text and your tagline in lighter grey below it.

Still seeing plain unstyled text?

  • Confirm you pasted the <style> block between <title>My Portfolio</title> and </head>. If it is inside <body> it may not apply correctly.
  • Check that the closing </style> tag is present. A missing closing tag breaks all the styles.
  • help me fix my CSS styles

✔️ Awesome, I've got everything!

Great. Double-check you have saved index.html and your browser shows the styled header.

ⓧ I'd like to double check the full code

Your index.html should contain two sections you pasted above, in this order:

  • The HTML skeleton (the first code block) providing the page structure with <head>, <body>, and the <header> content.
  • The style block (the second code block) placed between <title> and </head>.

Scroll up and confirm both blocks are present and in order. The <style> tag should sit inside <head>, not inside <body>.

Stage, commit, and push your code to GitHub

Your portfolio page looks great locally. Now you need to record this change in Git's history and send it up to GitHub so it lives in both places.

  • In the VS Code terminal, stage all new files and commit them by running these commands:
git add .
git commit -m "Add portfolio page with header"

What do these commands do?

  • `git add .` stages every new or changed file in the folder. Staging means marking files to be included in the next commit.
  • `git commit -m "..."` takes a snapshot of the staged files and saves it with a descriptive message. This snapshot lives in your local Git history.

You should see output confirming the commit, including the file index.html was created.

  • Push your commit to GitHub by running:
git push

Seeing a sign-in prompt?

The first time you push, Git Credential Manager opens a browser window asking you to sign in to GitHub. This is normal. Sign in and authorize the request. After this one-time authorization, future pushes will work without prompting.

Before you check GitHub, predict what you expect to see on your repository page. Will index.html appear alongside README.md?

  • Open your browser and visit your repository page at https://github.com/YOUR-USERNAME/my-portfolio.

You should see index.html listed alongside README.md. Click index.html to confirm your HTML code is there.

Don't see index.html on GitHub?

  • Run git status in your terminal. If it says "nothing to commit, working tree clean" then your push succeeded. Refresh the GitHub page.
  • If git status shows untracked files, you may have forgotten git add . before committing. Run the add, commit, and push sequence again.
  • If you see a "failed to push" error mentioning authentication, make sure you signed in when the browser prompt appeared. Run git push again.
  • help me push my code to GitHub

Your code now lives on GitHub for the world to see. Next up, you will add more content to the page and experience firsthand why pushing directly to main offers no safety net.

Push Changes Directly to Main

Your repository is live on GitHub with your first page. Now you are going to add a new feature the fastest way possible: editing code and pushing it straight to main.

This is the simplest Git workflow. You make a change, commit it, and push. But pay attention to what is missing from this approach, because that gap is exactly what the next steps will fix.

In this step, get ready to:
  • Add a Projects section to your portfolio page.
  • Push the change directly to main with no review.
  • Observe what is missing from this workflow.
Add a Projects section to your page

Your portfolio currently only has a header. You are going to add a Projects section with some placeholder content so there is a visible change to push.

  • In VS Code, open index.html from the Explorer sidebar.
  • Find the closing header p style block (the one ending with } just before </style>). Add these new styles directly below it:
        section {
            padding: 40px 20px;
            max-width: 800px;
            margin: 0 auto;
        }
        section h2 {
            font-size: 1.8rem;
            margin-bottom: 20px;
            color: #2c3e50;
        }
        .project {
            background: #f9f9f9;
            border-left: 4px solid #2c3e50;
            padding: 15px;
            margin-bottom: 15px;
        }
        .project h3 {
            margin-bottom: 5px;
        }

What do these styles do?

These CSS rules create a centered content area with a max width of 800 pixels. Each project card gets a light background and a bold left border to make it stand out from the page.

  • Now find the closing </header> tag in the body of your HTML. Add this Projects section directly below it (before the closing </body> tag):

    <section>
        <h2>Projects</h2>
        <div class="project">
            <h3>Portfolio Website</h3>
            <p>My first project built while learning GitHub workflows.</p>
        </div>
        <div class="project">
            <h3>Coming Soon</h3>
            <p>More projects on the way as I keep learning!</p>
        </div>
    </section>

What does this HTML do?

This adds a <section> element with two project cards inside it. Each card is a <div> with the class project, which picks up the left-border styling you just added.

  • Save index.html.
  • Open index.html in your browser (right-click the file in VS Code's Explorer and select Reveal in File Explorer on Windows, then double-click the file). You should see your header and two project cards with a dark left border.

Don't see the project cards?

Make sure you saved the file. Check that the new CSS styles are between the </style> tags and the new HTML is between </header> and </body>.

help me figure out why my Projects section is not showing up

✔️ Awesome, I've got everything!

Great. Double check you have saved your file before moving on.

ⓧ I'd like to double check the full code

Scroll up and confirm your file has all of these pieces in order:

  • The original CSS styles for *, body, header, header h1, and header p.
  • The new CSS styles for section, section h2, .project, and .project h3.
  • The <header> block with your name and tagline.
  • The new <section> block with two .project divs inside it.
Stage, commit, and push to main

Your change is saved locally. Now you will send it straight to the main branch on GitHub in one sequence.

  • Stage all your changes by running this command in the VS Code terminal:
git add .
  • Commit with a descriptive message by running:
git commit -m "Add projects section"
  • Push the commit to GitHub by running:
git push

Your terminal should confirm the push with a message showing objects being sent to the remote.

Seeing 'nothing to commit'?

This means you did not save index.html before running git add .. Save the file in VS Code, then run all three commands again.

help me push my changes to GitHub

Observe what is missing from this workflow

Your change is live on main instantly. Before you check GitHub, think about this: was there any step where someone (or you) could have reviewed the change before it hit the main codebase?

  • Switch to your browser and refresh your repository page on GitHub.
  • Click on index.html to confirm your Projects section code is now showing on main.
  • Now click the Pull requests tab at the top of your repository.

The Pull requests tab shows zero results. There is no record of anyone reviewing this change. There is no way to compare before and after. There is no option to reject it. The change went straight from your computer to the main codebase with zero oversight.

Why is this a problem?

On a team, main is the branch that represents the live, working version of the project. If someone pushes a bug directly to main, the whole team is affected immediately.

Professional teams solve this with branches and pull requests. You will learn both in the next two steps.

You have felt the gap firsthand. Your code went from your editor to the main branch with no checkpoint in between. Next up, you will learn how to isolate changes on a branch so they never touch main until you are ready.

Branch Your Work

In the last step, you pushed a change directly to main with no review step and no way to reject it. On a real team, that kind of workflow is risky.

Branching solves this problem. A branch creates a parallel copy of your code where you can make changes freely. The stable version on main stays untouched until you deliberately choose to merge.

In this step, get ready to:
  • Create a feature branch to isolate your next change from main.
  • Add a Contact section to your portfolio page on the new branch.
  • Push the branch to GitHub so it is ready for a pull request.
Create a feature branch

A feature branch lets you develop a new piece of your page without touching the code on main. If something goes wrong, main is still safe.

  • Create and switch to a new branch by running this command:
git checkout -b add-contact-section

What does this command do?

The -b flag tells Git to create a new branch AND switch to it in one step.

Without -b, git checkout only switches to an existing branch. Adding -b combines "create" and "switch" into one command.

  • Confirm you are on the new branch by running:
git branch

You should see an asterisk next to add-contact-section, like this:

* add-contact-section
  main

The asterisk tells you which branch you are currently working on.

Still on main?

If the asterisk is next to main, the checkout command may have had a typo. Run git checkout add-contact-section to switch to the branch you created.

If you see an error saying the branch does not exist, run git checkout -b add-contact-section again.

Help me figure out why my branch didn't switch.

Add a Contact section to your page

Now that you are on a separate branch, any changes you make here will not affect main. You will add a Contact section with your GitHub link and email.

  • In VS Code, open index.html and find the closing brace of the .project h3 rule in the <style> section.
  • Add the following styles directly below it:
        .contact-list {
            list-style: none;
        }
        .contact-list li {
            padding: 8px 0;
            font-size: 1.1rem;
        }
  • Now scroll down to the closing </section> tag after the Projects section (just above </body>).
  • Add this Contact section below it:
    <section>
        <h2>Contact</h2>
        <ul class="contact-list">
            <li>GitHub: github.com/yourusername</li>
            <li>Email: your.email@example.com</li>
        </ul>
    </section>

What does this code do?

The CSS removes default bullet points from the list and adds comfortable spacing between each contact item.

The HTML creates a new page section with a heading and an unordered list styled by the contact-list class.

  • Save index.html (Ctrl+S).
  • Open index.html in your browser by right-clicking the file in VS Code's Explorer sidebar and selecting Reveal in File Explorer, then double-clicking the file.

You should see a Contact heading below your Projects section with your GitHub link and email listed.

Don't see the Contact section?

Make sure you pasted the HTML outside the existing </section> tag, not inside it. The Contact section needs its own <section> wrapper.

Check that the CSS is inside the <style> block (before </style>), not in the <body>.

Help me figure out why my Contact section isn't showing up.

  • Stage and commit your changes by running these commands:
git add .
git commit -m "Add contact section"

You should see a message confirming 1 file changed with insertions.

✔️ Awesome, I've got everything!

Great. Double check you saved index.html before moving on.

ⓧ I'd like to double check the full code

Scroll up and confirm your index.html has all of the following in order:

  • The original CSS styles (from * through .project h3).
  • The new .contact-list and .contact-list li styles directly below .project h3.
  • The header and Projects <section> in the body.
  • The new Contact <section> after the Projects section, before </body>.
Push your branch to GitHub

Your branch and commit only exist on your computer right now. Pushing sends it to GitHub so others can see it and you can open a pull request.

  • Push the branch to GitHub by running:
git push --set-upstream origin add-contact-section

What does --set-upstream mean?

The first time you push a new branch, Git does not know where to send it on GitHub. --set-upstream origin add-contact-section tells Git to link your local branch to a matching branch on GitHub (origin).

After this first push, future pushes on this branch only need git push with no extra flags.

Before you check GitHub, what do you think you will see on the repository page?

  • Switch to your browser and refresh your repository page on GitHub.

You should see a yellow banner at the top saying your branch had recent pushes and offering to Compare & pull request.

  • Click the branch dropdown (it says main) and confirm add-contact-section appears in the list.
  • In your terminal, run git branch one more time to confirm the asterisk is next to add-contact-section.

Don't see the banner on GitHub?

The banner disappears after a few minutes. If you do not see it, click the branch dropdown at the top of the repo page to verify your branch is listed.

If the branch is not in the dropdown, check that the push command completed without errors in your terminal. Look for a line that says * [new branch] in the output.

Help me figure out why my branch didn't push to GitHub.

Your feature branch is live on GitHub and ready for review. In the next step, you will open a pull request to propose merging this Contact section into main. This is where the whole workflow clicks together.

Open a Pull Request and Merge

Your Contact section is committed and pushed to its own branch, safely isolated from main. Now it's time to propose those changes back to the main codebase through a pull request.

A pull request shows exactly what changed, gives space for review, and only updates main when you explicitly approve. This is the second half of the fix for the "push straight to main" problem you experienced in Step 3.

In this step, get ready to:
  • Create a pull request proposing your branch's changes to main.
  • Review the diff to see exactly what your branch adds.
  • Merge the pull request and sync your local main branch.
Create the pull request on GitHub
  • Switch back to your my-portfolio repository page on GitHub.
  • Click the Compare & pull request button in the yellow banner at the top of the page.

Banner disappeared?

If you don't see the yellow banner, click the Pull requests tab, then click New pull request. Set the base branch to main and compare to add-contact-section.

  • Confirm the base branch is set to main and the compare branch is add-contact-section.
  • In the title field, type Add contact section.
  • In the description box, write a short explanation of what you added and why (e.g., "Added a Contact section with my GitHub link and email so visitors can reach me.").
  • Click Create pull request.

Your pull request is now open. GitHub shows you a conversation page with your title, description, and commit history.

What is a pull request?

A pull request is a proposal to merge your branch's changes into another branch (usually main). It creates a dedicated page where you can see the exact diff, discuss the changes, and decide whether to accept them.

On a team, this is where code review happens before anything reaches production. Nobody's code reaches main without someone else seeing it first.

Review the diff in Files changed
  • Click the Files changed tab at the top of the pull request page.

You see a view with green-highlighted lines showing everything you added. This is the exact Contact section HTML you wrote on your branch.

What do the colors mean?

Green lines are additions (new code you wrote). Red lines are deletions (code you removed). In this PR, you should only see green because you only added new HTML to the file.

  • Scroll through the diff and confirm the changes match what you intended to add.

Why review your own code?

On a real team, this is what a colleague would see before approving your code. They can leave comments on specific lines, request changes, or approve. Reviewing your own diff is a good habit because you often spot typos or accidental changes you didn't intend.

Merge the pull request and sync locally
  • Click the Conversation tab to return to the main pull request page.
  • Click the green Merge pull request button at the bottom of the page.
  • Click Confirm merge.

Your branch's changes are now part of main. GitHub displays a purple "Merged" message on the pull request.

  • Click Delete branch to clean up the remote branch. It has been merged, so you don't need it anymore.

Now switch your local repository back to main and pull the merged changes down from GitHub.

  • Switch to the main branch locally by running this command:
git checkout main
  • Pull the merged changes from GitHub by running:
git pull

Why git pull after merging on GitHub?

The merge happened on GitHub's servers. Your local main branch doesn't know about it yet. Running git pull downloads the merge commit and updates your local files to match what's on GitHub.

Before you run the next command, what do you expect to see at the top of your commit history? A regular commit message, or something different?

  • Check your commit history by running:
git log --oneline

You see a merge commit at the top of the list. Its message looks something like "Merge pull request #1 from YOUR-USERNAME/add-contact-section". This is different from your regular commits because it represents two branches joining together.

  • Switch back to your browser and click the Pull requests tab on your repository page.
  • Click Closed to filter to closed pull requests.

You see 1 closed pull request with a purple Merged badge. This is proof that your change went through a proper review workflow before reaching main.

Compare this to Step 3

In Step 3, you pushed directly to main and the Pull requests tab was empty. Now you have a documented record of what changed, when it merged, and why.

This is the professional workflow that dev teams rely on every day. The branch isolates your work. The pull request makes it visible and reviewable. The merge makes it official.

Pull request not showing as merged?

Make sure you clicked Confirm merge after clicking Merge pull request. The merge button has a two-step confirmation.

If git pull shows "Already up to date", make sure you ran git checkout main first. You need to be on the main branch to pull changes into it.

Why isn't my pull request showing as merged on GitHub?

Secret mission

Create and Resolve a Merge Conflict

Merge conflicts are inevitable on real teams. Two people edit the same line, and Git cannot decide which version wins. In this mission, you will intentionally create that exact situation, then resolve it like a pro using GitHub's conflict editor.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally and on GitHub's free tier, so there are no ongoing costs.

Resources you used:

  • Public GitHub repository my-portfolio (remote, on GitHub.com).
  • Local project folder my-portfolio on your Desktop.
  • VS Code (installed on your machine).
  • Git global configuration (your name and email).

Keep everything running

No action needed. Choose this if you plan to keep building on your portfolio page or want to show employers your GitHub activity.

  • Your my-portfolio repository stays public on your GitHub profile at no cost.
  • Your commit history, branches, and merged pull requests remain visible to anyone who visits your profile.
  • You can keep adding HTML sections, link it to GitHub Pages for a live URL, or use it as a sandbox for practicing Git workflows.

Pause - I'll come back to this later

Free up local disk space while keeping the remote repository intact on GitHub. You can re-clone it anytime.

  • Delete the local folder by running this command in your terminal (macOS/Linux):
  • Your GitHub repository stays online and free. You can clone it again later with git clone.
rm -rf ~/Desktop/my-portfolio

On Windows, run this instead:

rmdir /s /q "$HOME\Desktop\my-portfolio"
  • VS Code and your Git configuration stay on your machine for future projects.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is permanent.

  • Delete the GitHub repository:
  • Go to your my-portfolio repository on GitHub.com.
  • Click Settings (the tab near the top of the repository page).
  • Scroll down to the Danger Zone section at the bottom.
  • Click Delete this repository.
  • Click I want to delete this repository, then type the repository name to confirm and click Delete this repository again.
  • Delete the local folder (macOS/Linux):
rm -rf ~/Desktop/my-portfolio

On Windows:

rmdir /s /q "$HOME\Desktop\my-portfolio"
  • Remove your Git global configuration if you do not plan to use Git again:
git config --global --unset user.name
git config --global --unset user.email
  • To uninstall VS Code on Windows, open Settings then Apps then Installed apps. Find Microsoft Visual Studio Code and click Uninstall.
  • On macOS, drag the Visual Studio Code app from your Applications folder to the Trash.

Nice Work!

Nice Work!

Nice work! You just built a personal portfolio page and shipped it to GitHub using the exact same workflow that professional development teams use every day.

Here's what you learned:

  • Created a GitHub repository from scratch, made commits with meaningful messages, and pushed code to build a visible commit history that tells the story of your changes.
  • Experienced the limitation of pushing directly to main with no review step, then leveled up to the branch-and-pull-request workflow that keeps real codebases safe.
  • Built a public GitHub profile with real commit history and merged PRs that employers can see.
  • (Secret Mission) Created and resolved a merge conflict using GitHub's web conflict editor.

Ready to quiz yourself?