Track a Portfolio with Git and GitHub

Build a portfolio page and learn Git branching, commits, and pull requests.

Introduction

30 Second Summary

Everyone has renamed a file "final_v2_FINAL.doc" at some point. Version control solves that chaos by tracking every change you make, letting you rewind to any point in time.

In this project, you will build a personal portfolio webpage and track it with Git from the very first file. You will push it to GitHub, work on a feature branch, resolve a merge conflict, and land your changes through a pull request.

What You'll Build

Run git log and see a full timeline of your portfolio's evolution, complete with branching history and a merged pull request that looks like real team collaboration.

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

A commit history showing exactly what changed each time you edited your portfolio, so you can rewind or review any past version.
A merged pull request on GitHub that demonstrates the workflow professional development teams use daily.
A resolved merge conflict in your history, proving you can handle the situation that makes most beginners nervous.
Secret Mission: Recover "deleted" work using Git's hidden safety net, the reflog.

Are there any prerequisites?

None. This project includes full setup instructions for Git, VS Code, and GitHub. All you need is a Mac with internet access.

Before We Start

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

Set Up Git and Configure Your Identity

Git is a version control system that tracks every change you make to your code. For it to work, it needs to be installed on your machine and configured with your identity.

Before you can track anything, Git needs to know who you are. Every commit you make gets stamped with your name and email, so let's get that set up now.

In this step, get ready to:

Confirm Git is installed on your machine.
Configure your name and email for Git.
Set the default branch name to main.

Check if Git is installed

macOS often ships with Git pre-installed via Xcode Command Line Tools. You might already have it without knowing.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal and press Enter to open it.
Check if Git is already installed by running this command:

git --version

Look at what Terminal printed and pick the tab that matches what you see.

✔️ I see a version number

If you see something like git version 2.55.0 (or any version number), Git is already installed and ready to go.

Skip ahead to the next substep below.

ⓧ Command not found

If Terminal says the command was not found, you need to install Git. The fastest way on macOS is through Xcode Command Line Tools.

Install Git by running this command:

xcode-select --install

What happens next?

A macOS dialog will pop up asking if you want to install the Command Line Tools. Click Install and wait for the download to finish. This can take a few minutes depending on your internet speed.

Once the installation completes, run git --version again to confirm Git is now available.

git --version

You should now see a version number printed in your terminal.

Still seeing command not found?

Close Terminal completely and reopen it, then try git --version again. If you have Homebrew installed, you can also install Git by running brew install git as an alternative.

Help me troubleshoot my Git installation on macOS.

Configure your Git identity

Git stamps every commit with a name and email so your team (and future you) can see who made each change. These values are stored in your global Git configuration.

Set your name, email, and default branch name by running these commands:

git config --global user.name "[[YOUR_NAME=\"Your Name\"]]"
git config --global user.email "[[YOUR_EMAIL=\"your@email.com\"]]"
git config --global init.defaultBranch main

What do these commands do?

user.name sets the name that appears on every commit you make.
user.email sets the email attached to your commits. Use the same email as your GitHub account so your commits link to your profile.
init.defaultBranch main ensures new repositories start with a branch called main. This matches GitHub's default and is the modern standard.

Verify your configuration

Before you run the next command, what do you expect it to print back?

Confirm your configuration is saved by running these commands:

git config --global user.name
git config --global user.email

The first command prints back the name you set. The second prints back your email. If both values match what you entered, Git is fully configured and ready to track your work.

Seeing a blank response?

A blank line means the value was not saved. Re-run the git config --global user.name command from the previous substep, making sure to include the quotes around your name.

Double-check that you used --global (two dashes) and not a single dash.

Help me fix my Git config setup.

Your machine now knows who you are. Next up, you'll create your first repository and start tracking real files with Git.

Create Your First Repository and Make Commits

Git is installed and it knows who you are. Now it is time to see it in action.

In this step, you will create a project folder, tell Git to start tracking it, and make your first commits. A commit is a snapshot of your files at a specific moment. By making multiple commits, you build a timeline that shows exactly how your project evolved.

In this step, get ready to:

Initialize a Git repository in a new project folder.
Create your portfolio homepage files.
Make two commits to build a history timeline.

Create a project folder and initialize a Git repository

Every Git project starts with a single command that turns an ordinary folder into a tracked repository. Once initialized, Git watches for changes inside that folder.

Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir my-portfolio
cd my-portfolio

Initialize a Git repository by running:

git init

Git responds with Initialized empty Git repository in ...my-portfolio/.git/. This folder is now a tracked repository.

What did git init do?

It created a hidden .git folder inside my-portfolio. This hidden folder is where Git stores your project's entire history. You never need to touch it directly.

Seeing 'not a git repository'?

Make sure you ran git init from inside the my-portfolio folder. Run pwd to check your current location.

Help me figure out why git init isn't working in my terminal.

Now you need a code editor to create your project files. You will use VS Code for this.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Visual Studio Code and press Enter to open it.
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 Open.

You should see my-portfolio in the VS Code sidebar with no files inside yet.

Create a new file by clicking the new file icon in the Explorer sidebar (or press Cmd+N).
Name the file index.html and paste the following code 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>
    <!-- Link to our stylesheet for page styling -->
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <header>
        <h1>Your Name</h1>
        <p>Aspiring Developer</p>
    </header>
    <!-- Main content area -->
    <main>
        <section>
            <h2>About Me</h2>
            <p>I'm learning to code and building cool things.</p>
        </section>
        <section>
            <h2>Skills</h2>
            <ul>
                <li>HTML</li>
                <li>CSS</li>
                <li>Git</li>
            </ul>
        </section>
    </main>
</body>
</html>

What does this HTML do?

This is a simple portfolio page with three parts: a header with your name and tagline, an About Me paragraph, and a Skills list showing what you know so far.

The <link> tag in the <head> connects a stylesheet that you will create next.

Save index.html with Cmd+S (macOS) or Ctrl+S (Windows).
Create another new file and name it style.css. Paste the following page layout styles into it:

/* Page layout - centers content with readable width */
body {
    font-family: sans-serif;
    max-width: 600px;
    margin: 0 auto;
    padding: 20px;
    line-height: 1.6;
}

/* Header styling with bottom border separator */
header {
    text-align: center;
    border-bottom: 2px solid #333;
    padding-bottom: 20px;
    margin-bottom: 20px;
}

h1 {
    margin-bottom: 5px;
}

h2 {
    color: #333;
}

Below those styles, add these list styles to the same file:

/* Remove default bullet points from lists */
ul {
    list-style: none;
    padding: 0;
}

/* Style each list item as a card */
li {
    background: #f4f4f4;
    margin: 5px 0;
    padding: 10px;
    border-radius: 4px;
}

What do these styles do?

The body rules center your content and set a comfortable reading width. The header gets a bottom border to separate it from the page content.

The list styles remove the default bullet points and turn each <li> into a small card with a gray background.

Save style.css with Cmd+S (macOS) or Ctrl+S (Windows).
Back in your Terminal, check what Git sees by running:

git status

You should see both index.html and style.css listed in red as untracked files. Git can see them, but is not tracking them yet.

Not seeing your files listed?

Make sure you saved both files in VS Code. Unsaved files only exist in the editor, not on disk where Git can find them.

Also confirm your Terminal is still inside the my-portfolio folder by running pwd.

Help me figure out why git status doesn't show my files.

Stage and commit your files

Git does not automatically save every change into history. You choose which changes to include in a commit by staging them first. Think of it like putting items in a box before sealing it shut.

Stage all files in the folder by running:

git add .

What does the dot mean?

The dot (.) means "everything in this folder." Running git add . stages all new and changed files at once. You could also add files one at a time with git add index.html.

Run git status again to see the difference:

git status

Your files now appear in green under "Changes to be committed." They have moved from untracked to staged.

Seal this snapshot into history by running:

git commit -m "Add portfolio homepage with styling"

What does this command do?

The git commit command takes everything in the staging area and saves it as a permanent snapshot. The -m flag lets you write a message describing what changed, so you can understand the history later.

Git prints a summary showing your commit message and how many files changed. You just made your first commit.

Seeing 'nothing to commit'?

This means you ran git commit without staging first. Run git add . and then try the commit command again.

Help me understand why my commit didn't work.

Make a second commit to see the history grow

One commit is a starting point. Two commits give you a timeline. Let's edit the portfolio and commit the change so you can see how Git tracks differences over time.

In VS Code, open index.html and find this line in the About Me section:

<p>I'm learning to code and building cool things.</p>

Replace that line with this updated version that adds your learning goals:

<p>I'm learning to code and building cool things. Currently focused on mastering version control and collaborative development workflows.</p>

Save index.html.
Back in Terminal, see exactly what changed by running:

git diff

Git shows the old line in red (removed) and the new line in green (added). This is how Git tracks differences between the current state and the last commit.

Stage and commit this change by running:

git add index.html
git commit -m "Update About Me section with learning goals"

Before you check the history, what do you think git log will show? How many entries, and in what order?

View your full commit history by running:

git log

You should see two commits listed in reverse chronological order. Each one shows your name, email, timestamp, and commit message. You now have a real timeline of your project.

How do I exit the log view?

If git log fills your terminal and shows a : at the bottom, press q to quit and return to the normal terminal prompt.

Only seeing one commit?

Make sure you ran git add index.html before the second git commit. Without staging, the edit is not included in the snapshot.

Help me figure out why my second commit is missing from git log.

✔️ Awesome, I've got everything!

Great. Double check you have saved both index.html and style.css in VS Code.

ⓧ I'd like to double check the full code

Here is what index.html should look like after both commits:

<!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>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <header>
        <h1>Your Name</h1>
        <p>Aspiring Developer</p>
    </header>
    <main>
        <section>
            <h2>About Me</h2>
            <p>I'm learning to code and building cool things. Currently focused on mastering version control and collaborative development workflows.</p>
        </section>
        <section>
            <h2>Skills</h2>
            <ul>
                <li>HTML</li>
                <li>CSS</li>
                <li>Git</li>
            </ul>
        </section>
    </main>
</body>
</html>

For style.css, confirm it contains the page layout styles (body, header, h1, h2) followed by the list styles (ul, li) from the two chunks above. The order matters.

Your portfolio now has a real history. Next up, you will push this repository to GitHub so it lives online and is safe from laptop disasters.

Push to GitHub

Your repository only exists on your machine right now. If your laptop dies, everything is gone.

Pushing to GitHub creates a remote backup and makes your work visible to others. In this step, you'll connect your local repository to a new GitHub repository and upload your commits.

In this step, get ready to:

Create a new repository on GitHub.
Connect your local repository to GitHub using a remote URL.
Push both commits so your code lives in two places.

Create a new repository on GitHub

You need a place on GitHub to receive your code. You'll create an empty repository there, then tell your local Git where to send its commits.

Switch to your browser where you're signed into GitHub.
Click the + icon in the top-right corner of the page.
Select New repository from the dropdown menu.
Enter my-portfolio in the Repository name field.
Leave the repository set to Public.
Do NOT check any of the initialization options (no README, no .gitignore, no license).
Click Create repository.

Why leave the repository empty?

You already have two commits locally. If GitHub adds a README or any other file, your local history and GitHub's history would conflict immediately. Starting empty lets you push your existing work cleanly.

GitHub now shows a "Quick setup" page with commands for connecting an existing repository. That's exactly what you'll do next.

Connect your local repo to GitHub and push

With the empty GitHub repository waiting, you need to tell your local Git where to send its commits. This connection is called a remote.

Return to your Terminal (which is still in the my-portfolio directory).
Add GitHub as a remote by running this command:

git remote add origin https://github.com/[[GITHUB_USERNAME="your-github-username"]]/my-portfolio.git

What does this command do?

This tells Git "the online version of this project lives at this URL." The word origin is the nickname for that remote URL. You'll use it every time you push or pull.

Push your commits to GitHub by running this command:

git push -u origin main

What does this command do?

The -u flag sets up tracking between your local main branch and the remote main branch on GitHub. After this, future pushes only need git push with no extra arguments.

Git uploads your two commits to GitHub and prints progress showing objects being counted, compressed, and written.

Seeing an authentication prompt?

This is your first push, so Git needs to verify your identity with GitHub. On macOS, a browser window typically opens asking you to sign in to your GitHub account and authorize the connection. Follow the prompts to authenticate.

Once you authenticate, your credentials are stored in the macOS Keychain. Future pushes will go through without asking again.

You should see output ending with a line like main -> main, confirming your branch was pushed successfully.

Push failed or authentication error?

Double check the remote URL matches your GitHub username exactly. Run git remote -v to see what's saved. If it's wrong, remove it with git remote remove origin and add it again with the correct URL.
If you see "repository not found", make sure the repository name on GitHub is my-portfolio (exact spelling, including the hyphen).
If authentication keeps failing, make sure you are signed in to the correct GitHub account in your browser.

Help me fix my git push authentication error.

Verify your code is on GitHub

Before you check, take a guess: what do you expect to see when you visit your repository on GitHub?

Switch to your browser.
Navigate to your repository page (the URL is https://github.com/ followed by your username and /my-portfolio).
Confirm you can see both index.html and style.css listed in the file view.
Click Commits (or the commit count link near the top).
You should see both commit messages listed: "Add portfolio homepage with styling" and "Update About Me section with learning goals".

Your code now lives in two places: your machine and GitHub. If anything happens to your laptop, your work is safe.

Your portfolio has a home on GitHub now. Next up, you'll learn how professional teams work by creating a feature branch and building new content independently from main.

Work on a Feature Branch

Your portfolio is on GitHub with a solid commit history. Now it is time to learn the workflow that professional teams use every single day.

In a real team, nobody edits main directly. Instead, you create a separate branch for each feature so main always stays stable and deployable. Your portfolio is missing a Projects section. You will add it on a feature branch, the way a teammate would.

In this step, get ready to:

Create a feature branch and switch to it.
Add new content to your portfolio on the branch.
Push the branch to GitHub so it exists in both places.

Create and switch to a new branch

A branch is like a parallel timeline for your project. Changes you make on a branch do not affect main until you explicitly merge them back.

Create a new branch and switch to it by running this command:

git checkout -b feature/add-projects

What does this command do?

The -b flag creates the branch and switches to it in one step. Without -b, git checkout only switches to an existing branch.

The name feature/add-projects describes what you are working on. The feature/ prefix is a common naming convention that keeps branches organized.

You should see: Switched to a new branch 'feature/add-projects'.

Confirm which branch you are on by running:

git branch

You should see two branches listed. The asterisk (*) marks feature/add-projects as your current branch.

Don't see the new branch?

Make sure you included the -b flag. Without it, Git looks for an existing branch with that name and fails.

Help me troubleshoot my branch creation

Make changes on your feature branch

Now that you are on your feature branch, any changes you commit here will not touch main. You will add a Projects section and update your Skills list.

Switch back to index.html in VS Code.
Find the Skills list. Add a new line after <li>Git</li> with the following:

                <li>GitHub</li>

Below the closing </section> tag of the Skills section, add this new Projects section:

        <section>
            <h2>Projects</h2>
            <ul>
                <li>Portfolio Website - Built with HTML and CSS, tracked with Git</li>
            </ul>
        </section>

What did you just add?

You made two changes to index.html. First, you added "GitHub" to your Skills list because you have earned it. Second, you added a Projects section to showcase what you have built.

Both changes live only on your feature/add-projects branch. If you switched back to main right now, these changes would disappear from the file.

Save index.html in VS Code.
Check what Git sees by running:

git status

You should see index.html listed in red as modified. Git knows the file changed but has not staged it yet.

Stage and commit your changes by running these commands:

git add .
git commit -m "Add projects section and update skills"

What does staging do?

The git add . command moves your changes to the staging area. Think of it as placing items in a box before sealing it. The git commit command seals the box with a descriptive message.

Your terminal shows a confirmation with the commit message and a summary of changes (insertions and file changed).

Seeing 'nothing to commit'?

This means you either forgot to save index.html in VS Code, or the file was not modified. Go back and confirm your edits are saved, then run git status to verify the file shows as modified.

Help me figure out why my changes are not being detected

Push your feature branch to GitHub

Your feature branch only exists on your machine right now. Pushing it to GitHub makes it visible to collaborators and backs up your work.

Push your feature branch to GitHub by running:

git push -u origin feature/add-projects

What does -u do here?

The -u flag sets up tracking between your local branch and the remote branch on GitHub. After this, future pushes from this branch only need git push with no extra arguments.

Open your repository on GitHub in your browser.
Click the branch dropdown (it says main). You should see feature/add-projects listed as a second branch.

You may also see a banner saying your branch had recent pushes, with a Compare & pull request button. Do not click it yet. You will use it in the next step.

Push rejected or authentication error?

If you see a permissions error, GitHub may need you to authenticate. Make sure you are signed into GitHub in your browser and that the remote URL matches your repository.

Run git remote -v to check that the URL points to your repository. If the URL is wrong, remove and re-add it with the correct address.

Help me troubleshoot my push to GitHub

Before you run the next command, what do you think you will see if you ask Git to show commits from all branches at once?

Verify your branches and commits by running:

git log --oneline --all

You should see commits on both main and feature/add-projects. Your new commit appears at the top with its short message.

Why branches instead of Git Flow?

You may have heard of complex branching models like Git Flow with develop, release, and hotfix branches. The feature branch workflow you just used is simpler and is what most teams rely on daily.

The pattern is: branch from main, do your work, open a pull request, merge back. That is the entire loop.

✔️ Awesome, I've got everything!

Great. Confirm you have saved index.html and that git log --oneline --all shows your new commit on feature/add-projects.

ⓧ I'd like to double check the full code

Scroll up and confirm these two changes are present in your index.html:

In the Skills <ul>, after <li>Git</li>, you have <li>GitHub</li>.
Below the Skills </section>, you have a new <section> with an <h2>Projects</h2> heading and a single list item: Portfolio Website - Built with HTML and CSS, tracked with Git.

Your style.css is unchanged from the previous step.

You now have a feature branch with real changes, living on both your machine and GitHub. Next up, you will simulate what happens when a teammate edits main while you are working. You will intentionally create a merge conflict and learn how to resolve it.

Resolve a Merge Conflict and Open a Pull Request

Your feature branch is on GitHub, ready to go. Now comes the moment that separates confident Git users from nervous ones: the merge conflict.

In a real team, teammates push changes to main while you work on your branch. When two people edit the same lines, Git cannot decide which version to keep. You are about to create this situation intentionally so you can practice resolving it in a safe environment.

In this step, get ready to:

Simulate a teammate's edit on main using GitHub's web editor.
Resolve a merge conflict by keeping both sets of changes.
Open and merge a pull request on GitHub.

Simulate a teammate editing main

Right now, your local branch and GitHub are in sync. To create a conflict, you will play the role of a teammate who edits main directly on GitHub while you were working on your feature branch.

Switch to your browser where GitHub is open.
Navigate to your my-portfolio repository.
Make sure you are on the main branch using the branch dropdown in the top-left of the file list.
Click on index.html to open it.
Click the pencil icon (edit button) in the top-right of the file view.

You are now editing the version of index.html on main. On main, the Skills list only has HTML, CSS, and Git (your feature branch added GitHub, but main does not have that yet).

Find the Skills list and add <li>JavaScript</li> on a new line after the <li>Git</li> item.
Click Commit changes... in the top-right.
Enter the commit message: Add JavaScript to skills.
Select Commit directly to the main branch.
Click Commit changes.

You should see the commit appear on the main branch. The file now shows JavaScript in the Skills list.

Why does this create a conflict?

Your feature branch added <li>GitHub</li> after the Git item. Main now has <li>JavaScript</li> in the same spot. Both branches edited the same area of the same file differently. Git will not guess which one to keep.

Pull the updated main and merge into your branch

Now you will bring main's changes into your feature branch and face the conflict head-on.

Switch back to Terminal.
Confirm you are on your feature branch by running:

git checkout feature/add-projects

Download the latest changes from GitHub (without changing your local files) by running:

git fetch origin

What does git fetch do?

The git fetch command downloads new commits from GitHub but does not apply them to your files. Think of it as checking your mailbox without opening any letters yet.

Before you run the next command, think about what will happen. You are about to merge main (which now has JavaScript in the Skills list) into your branch (which has GitHub in the Skills list). Do you think Git can figure this out automatically?

Attempt to merge main's changes into your branch by running:

git merge origin/main

Git reports a conflict in index.html. You will see a message containing CONFLICT (content): Merge conflict in index.html followed by Automatic merge failed; fix conflicts and then commit the result..

What do the conflict markers look like?

Open index.html in VS Code. Inside the Skills list you will see three special markers Git inserted:

<<<<<<< HEAD marks the start of YOUR version (the feature branch).
======= separates the two versions.
>>>>>>> origin/main marks the end of the INCOMING version (from main).

Open index.html in VS Code.
Find the conflict markers in the Skills section. It will look like this:

                <li>Git</li>
<<<<<<< HEAD
                <li>GitHub</li>
=======
                <li>JavaScript</li>
>>>>>>> origin/main

Resolve the conflict by keeping BOTH skills. Delete all the marker lines and leave the file looking like this:

                <li>Git</li>
                <li>GitHub</li>
                <li>JavaScript</li>

Save index.html.

Resolving means choosing

You are not limited to picking one side. You can keep both, rewrite the section entirely, or pick just one version. The key is removing all three marker lines so Git knows you have made a decision.

Stage the resolved file by running:

git add index.html

Commit the resolution by running:

git commit -m "Resolve merge conflict: keep both new skills"

Git creates a merge commit. This commit records that you combined two diverging histories and made a conscious decision about the conflict.

Push your resolved branch to GitHub by running:

git push origin feature/add-projects

Your feature branch on GitHub now includes the merge commit with the resolved conflict.

Seeing 'error: you need to resolve your current index first'?

This means you tried to commit or push before staging the resolved file. Run git add index.html first, then commit again.

If VS Code still shows conflict markers in the file, make sure you deleted all three marker lines (<<<<<<<, =======, and >>>>>>>) and saved the file before staging.

Help me resolve my merge conflict in index.html

Open and merge your pull request

Your feature branch is complete, conflict-free, and pushed to GitHub. A pull request is a formal way to propose merging your branch into main, giving teammates a chance to review your changes before they land.

Switch back to your browser on GitHub.
You should see a yellow banner saying your branch had recent pushes. Click Compare & pull request.

No banner showing?

Go to the Pull requests tab and click New pull request. Set base: main and compare: feature/add-projects.

Confirm the base branch is main and the compare branch is feature/add-projects.
Enter the title: Add projects section and update skills.
In the description box, write a brief explanation of what you changed and why (for example: added a Projects section and updated Skills list with new items).
Click Create pull request.

Your pull request page now shows the diff of all changes. In a team, reviewers would comment here before approving.

Click Merge pull request.
Click Confirm merge.

The pull request now shows a purple Merged icon. Your feature branch changes are officially part of main.

Switch back to Terminal.
Switch to your local main branch by running:

git checkout main

Pull the merged changes from GitHub by running:

git pull origin main

Clean up the merged feature branch locally by running:

git branch -d feature/add-projects

Git confirms the branch is deleted with a message like Deleted branch feature/add-projects.

Why delete the branch?

Once a branch is merged, it has served its purpose. Deleting it keeps your repository tidy. The commits are preserved in main's history forever.

Before you check the final state, what do you expect git log --oneline to show? Think about how many commits should be on main now.

Verify everything landed correctly by running:

git log --oneline

You see the merge commit, the conflict resolution commit, your feature branch commits, and your original commits all listed in the history. Every piece of work is tracked.

Not seeing the merge commits?

Make sure you ran git pull origin main after merging the pull request on GitHub. Without pulling, your local main is still behind.

Help me sync my local main branch with GitHub

You have just completed the full feature branch workflow that professional teams use every single day. Next up, you will unlock Git's hidden safety net in the Secret Mission.

Secret mission

Recover "Deleted" Work with Git Reflog

The scariest moment for any developer is thinking they have permanently lost work. In this mission, you will deliberately delete a branch and then bring it back from the dead using Git's hidden safety net. Most developers do not learn this skill until months into their careers.

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 with a free GitHub repository, so there are no ongoing costs.

Resources you used:

Local my-portfolio folder on your Desktop.
GitHub repository my-portfolio (remote).
Git global configuration (user name, email, default branch).

Keep everything running

No action needed. Choose this if you plan to keep building on your portfolio or want to reference your commit history later.

Your my-portfolio folder stays on your Desktop, ready for new commits whenever you want to add content.
Your GitHub repository stays public so you can share the link with others.
Your Git configuration remains set for any future projects.

Pause - I'll come back to this later

Close open tools to free up memory. Your files and repository stay intact for when you return.

Close the Terminal window.
Close VS Code.
Your local files and GitHub repository remain exactly as you left them. No data is lost.

Delete - I don't want to use this again

Remove all project resources and start fresh. This cannot be undone.

Delete the local project folder:

Run this command in Terminal to remove the folder:

rm -rf ~/Desktop/my-portfolio

Delete the GitHub repository:

Go to your my-portfolio repository on github.com.
Click Settings in the repository navigation bar.
Scroll down to the Danger Zone section.
Click Delete this repository.
Click I want to delete this repository.
Click I have read and understand these effects.
Type my-portfolio to confirm, then click Delete this repository.

Remove Git global configuration (optional):

Only do this if you do not plan to use Git again. Run these commands to clear your identity settings:

git config --global --unset user.name
git config --global --unset user.email
git config --global --unset init.defaultBranch

Confirm removal by running:

git config --global user.name

If the config was removed successfully, this command prints nothing.

Nice Work!

You just built a personal portfolio page tracked with Git from scratch, pushed it to GitHub, and experienced the full feature branch workflow that professional teams use every day.

You've learned how to:

Make commits that track every change to your code, and connect a local repository to GitHub so your work lives in two places.
Intentionally cause and resolve a merge conflict, the skill that separates confident Git users from nervous ones.
Open and merge a pull request using the feature branch workflow that professional development teams rely on daily.
Secret Mission: Recovered "deleted" work using git reflog, proving that Git is your safety net and almost never truly loses committed data.

Ready to quiz yourself?