Build Your Developer Profile with Git

Build a GitHub profile README using real Git workflows: branch, commit, PR, merge.

Introduction

30 Second Summary

Every developer needs a way to track changes to their code and collaborate with others. Git is the tool that makes this possible, and GitHub is where the world's developers share and build software together.

In this project, you will build a personal developer profile README on GitHub using the professional Git workflow that real development teams use every day. You'll create branches, make commits, open pull requests, and even resolve a merge conflict.

What You'll Build

A GitHub profile README repository built entirely through the command line using branches, commits, pull requests, and merge conflict resolution.

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

  • A GitHub profile README that displays on your public profile page for anyone who visits it.
  • Hands-on experience with the complete GitHub Flow workflow (branch, commit, push, pull request, merge) from the command line.
  • A resolved merge conflict in your git history, proving you can handle competing changes with confidence.
  • Secret Mission: Add dynamic GitHub stats badges and a "Currently Learning" section to your profile.

Are there any prerequisites?

You'll need a free GitHub account to complete this project. If you don't have one yet, head to github.com and sign up before starting Step 1.

Install and Configure Git

Every project you build as a developer needs a way to track changes, collaborate with others, and keep a history of your work. Git is the tool that makes all of this possible.

In this step, you'll install Git on your machine, configure it with your identity, and connect it to your GitHub account so you can push and pull code.

In this step, get ready to:
  • Install and verify Git on your machine.
  • Configure your Git identity (name, email, and default branch).
  • Authenticate with GitHub using an SSH key.
Install Git on macOS

macOS often comes with Git pre-installed through Xcode Command Line Tools. Let's check whether you already have it.

  • Check your current Git version by running this command in your Terminal:
git --version

✔️ I see version 2.23 or higher

You're all set. Your Git installation is ready to go.

Why 2.23 or higher?

This project uses the git switch command, which was introduced in Git 2.23. Any version from 2.23 onward will work perfectly.

ⓧ I see a version lower than 2.23

You have Git installed, but it's an older version. You'll need to upgrade to use the modern commands in this project.

  • Install the latest version of Git via Homebrew by running:
brew install git

What if I don't have Homebrew?

Homebrew is a package manager for macOS. If the brew command is not found, install Homebrew first by visiting https://brew.sh and following the one-line install command on the homepage.

  • After installation, close and reopen your Terminal so the new version takes priority.
  • Verify the upgrade by running:
git --version

You should now see a version of 2.23 or higher.

ⓧ Command not found

Git is not installed on your machine yet. You can install it using either Homebrew or Xcode Command Line Tools.

  • Install Git via Homebrew by running:
brew install git

If you don't have Homebrew, you can alternatively install Git through Xcode Command Line Tools by running:

xcode-select --install

What happens when I run xcode-select?

A dialog box will pop up asking you to install the Command Line Tools. Click Install and wait for the download to complete. This includes Git along with other developer tools.

  • Once installation finishes, verify Git is ready by running:
git --version

You should see a version number starting with 2. in the output.

Configure your Git identity

Every Git commit is stamped with a name and email address. This is how other developers know who made each change.

  • Set your Git identity and default branch by running these three commands:
git config --global user.name "[[YOUR_NAME="Your Name"]]"
git config --global user.email "[[GITHUB_EMAIL="your-github-email@example.com"]]"
git config --global init.defaultBranch main

What do these commands do?

The first command sets the name that appears on your commits. The second sets the email. Use the same email address you used to sign up for GitHub so your commits link to your profile.

The third command sets main as the default branch name for any new repository you create. GitHub uses main by default, so this keeps your local Git in sync.

  • Confirm your settings by running:
git config --global --list

You should see your name, email, and init.defaultBranch=main listed in the output.

Don't see your settings listed?

Double check that you included the --global flag in each command. Without it, settings are only applied to a specific repository, not system-wide.

help me fix my git config settings

Authenticate with GitHub

Your local Git needs a way to prove your identity to GitHub when pushing code. The most common method is an SSH key, which acts like a secure digital handshake between your machine and GitHub.

SSH key (recommended)

  • Generate a new SSH key by running this command (use the same email as your GitHub account):
ssh-keygen -t ed25519 -C "[[GITHUB_EMAIL="your-github-email@example.com"]]"

What will this command ask me?

You'll see three prompts. Press Enter to accept the default file location. Then press Enter twice more to skip setting a passphrase (or type a passphrase if you prefer extra security).

  • Start the SSH agent in the background by running:
eval "$(ssh-agent -s)"
  • Add your new SSH key to the agent by running:
ssh-add ~/.ssh/id_ed25519
  • Copy the public key to your clipboard by running:
pbcopy < ~/.ssh/id_ed25519.pub

Now you need to add this key to your GitHub account.

  • Open GitHub in your browser and click your profile picture in the top right corner.
  • Click Settings.
  • In the left sidebar, click SSH and GPG keys.
  • Click New SSH key.
  • Give it a title like My Mac and paste your key into the Key field.
  • Click Add SSH key.
  • Test the connection by running:
ssh -T git@github.com

You should see a message that says "Hi [your-username]! You've successfully authenticated". This confirms your machine can talk to GitHub securely.

What if it asks about fingerprints?

The first time you connect, SSH may ask if you trust GitHub's server. Type yes and press Enter to continue. This only happens once.

Seeing 'Permission denied'?

Make sure you copied the .pub file (the public key), not the private key file. The public key file ends in .pub.

Also check that the key you pasted into GitHub matches what's in ~/.ssh/id_ed25519.pub on your machine.

help me fix my SSH connection to GitHub

Personal access token (alternative)

If you prefer HTTPS over SSH, you can use a personal access token instead. This token acts as a password when Git talks to GitHub.

  • Open GitHub in your browser and click your profile picture in the top right corner.
  • Click Settings.
  • In the left sidebar, click Developer settings.
  • In the left sidebar under Personal access tokens, click Tokens (classic).
  • Click Generate new token, then click Generate new token (classic).
  • In the Note field, type Git CLI access.
  • Set an expiration date (30 days is fine for learning).
  • Under scopes, check the repo checkbox. This grants full access to your repositories from the command line.
  • Click Generate token.
  • Copy the token immediately. You won't be able to see it again after leaving the page.

Save your token somewhere safe

Store this token in a password manager or a secure note. You'll paste it as your password the first time Git asks you to authenticate with GitHub over HTTPS.

Having trouble creating a token?

Make sure you're clicking Tokens (classic) in the sidebar, not Fine-grained tokens. The classic token type is simpler for this project.

help me create a GitHub personal access token

Your machine is now set up with Git and connected to GitHub. Next up, you'll create your profile repository and start building your README.

Create Your Profile Repository on GitHub

Your Git environment is ready. You have Git installed, your identity configured, and your connection to GitHub verified.

Now it's time to create the repository that will become your developer profile. GitHub has a special feature: if you create a repository with the exact same name as your username, the README file inside it appears directly on your profile page for anyone to see.

In this step, get ready to:
  • Create a special profile repository on GitHub.
  • Clone the repository to your local machine.
  • Explore the initial state of the repository with Git commands.
Create the special profile repository

A profile README is a special repository on GitHub that displays its contents directly on your profile page. The only requirement is that the repository name matches your GitHub username exactly.

  • Open your web browser and navigate to github.com.
  • Sign in to your GitHub account.
  • In the upper-right corner of the page, click the + icon.
  • Click New repository.
  • In the Repository name field, type your exact GitHub username. For example, if your username is "octocat", type octocat.
  • Select Public for the repository visibility.
  • Toggle Add a README file to On.
  • Click Create repository.

You should now see your new repository page with a README.md file listed.

What is a profile README?

GitHub displays your profile README at the top of your profile page when three conditions are met: the repository name matches your username, the repository is public, and it contains a README.md file with content.

This is different from a regular repository README. A regular README describes a project. A profile README describes you as a developer.

Don't see the option to add a README?

Make sure you're creating a brand new repository, not importing one. The Add a README file toggle only appears for new repositories that aren't initialized from a template or import.

Also confirm the repository name matches your username exactly. GitHub is case-sensitive here.

Why isn't my profile README repository working?

Clone the repository to your machine

Your repository exists on GitHub, but you need a local copy to work with. Cloning creates a full copy of the repository on your computer, linked back to the original on GitHub.

  • On your repository page, click the green Code button.
  • Copy the URL shown (use the SSH tab if you set up SSH keys, or the HTTPS tab if you created a personal access token).
  • Switch back to your Terminal and navigate to your Desktop by running this command:
cd ~/Desktop
  • Clone your repository by running this command:
git clone [[REPO_URL="your repository URL from the green Code button"]]

What does this command do?

The git clone command downloads a full copy of your repository from GitHub to your computer. It also sets up a connection (called a "remote") so Git knows where to push and pull changes later.

  • Move into your new project folder by running this command:
cd [[GITHUB_USERNAME="your GitHub username"]]
  • Confirm you're inside the project folder by running:
ls

You should see README.md listed in the output.

Seeing a permission denied or authentication error?

If you used SSH, make sure you copied the SSH URL (starts with git@github.com:) and that your SSH key is added to your GitHub account.

If you used HTTPS, make sure you copied the HTTPS URL (starts with https://github.com/) and enter your personal access token when prompted for a password.

Why am I getting a permission denied error when cloning?

Explore the initial state

Before you start making changes, take a moment to understand what Git sees right now. These three commands are ones you'll use constantly as a developer to check the state of your project.

  • Check the status of your working directory by running:
git status

You should see a message saying you're on branch main with nothing to commit and a clean working tree.

  • View the commit history by running:
git log

You should see one commit. This is the initial commit that GitHub created when it added the README.md file.

  • Check which branch you're on by running:
git branch

You should see * main listed. The asterisk indicates your current branch.

What do these commands tell you?

  • `git status` shows whether you have any uncommitted changes. A "clean working tree" means everything is saved and tracked.
  • `git log` shows the history of commits (saved snapshots) in this repository.
  • `git branch` shows all local branches and highlights which one you're currently on.

Your repository is cloned and ready. Next up, you'll create your first branch and start building out your profile with real content.

Build Your Profile with Branches and Commits

Your repository is cloned and ready to go. Now it's time to start building your profile README using the workflow that professional developers follow every day.

Instead of editing directly on main, you'll create a separate branch to isolate your work. This keeps the main branch clean while you experiment. Once your changes are ready, you'll push them to GitHub and merge them through a pull request.

In this step, get ready to:
  • Create a feature branch and write your profile introduction.
  • Add a Skills section with additional commits.
  • Push your branch and merge it through a pull request on GitHub.
Create a feature branch and add your introduction

A branch is like a parallel timeline for your project. You can make changes freely without affecting main until you're ready to merge.

  • Create a new branch called add-introduction and switch to it by running this command:
git switch -c add-introduction

What does this command do?

The git switch -c command does two things at once: it creates a new branch with the name you provide, and immediately switches you onto that branch. Your terminal prompt or git branch output will now show add-introduction as your current branch.

You should see a message confirming you switched to the new branch.

Seeing an error about the branch already existing?

If you see a message that the branch already exists, it means you ran this command before. Switch to the existing branch instead with git switch add-introduction (without the -c flag).

Help me fix this branch creation error

Now you'll write the content for your profile README. This is a Markdown file, so you'll use formatting like # for headings and plain text for paragraphs.

  • Open README.md in a text editor. You can use any editor you prefer. To open it with your default text editor from Terminal, run:
open -t README.md
  • Delete everything currently in the file and replace it with a personal introduction. Use this as a starting template, replacing the details with your own:
# Hi, I'm [[YOURNAME="your name"]]

I'm a developer learning to build things with code. I'm currently exploring web development and cloud computing.

What is Markdown?

Markdown is a lightweight formatting language used across GitHub. The # symbol creates a top-level heading, and plain text below it becomes a paragraph. GitHub renders this formatting automatically on your profile page.

Feel free to write anything you want about yourself. The important thing for this step is practicing the Git commands, not what you write.

  • Save the file in your text editor.
  • Back in Terminal, stage your changes by running:
git add README.md
  • Commit your staged changes with a descriptive message by running:
git commit -m "Add personal introduction section"

What is staging and committing?

The staging area is a holding zone where you choose exactly which changes go into your next commit. Running git add README.md moves your file changes into this zone.

A commit is a permanent snapshot of your staged changes. The -m flag lets you write a short message describing what you changed. Good commit messages help you (and teammates) understand project history later.

You should see output confirming your commit, including the branch name and your message.

Seeing an error about identity?

If Git asks you to set your name and email, it means the global config from Step 1 didn't save properly. Run git config --global user.name and git config --global user.email to check your current settings. Re-run the config commands from Step 1 if they're empty.

Help me fix my Git identity error

Add more content with additional commits

Professional developers make multiple small commits as they build features. Each commit captures one logical change. Let's add a Skills section as a separate commit.

  • Open README.md again in your text editor.
  • Add a Skills section below your introduction. Use this as a starting template, listing technologies you know or are learning:
## Skills

- HTML & CSS
- JavaScript
- Python
- Git & GitHub

What does this Markdown do?

The ## creates a second-level heading. Lines starting with - become bullet points. Swap these out for whatever skills you actually have or are working toward.

  • Save the file.
  • Stage and commit your Skills section by running these commands:
git add README.md
git commit -m "Add skills section"
  • Check your commit history on this branch by running:
git log --oneline

You should see at least two commits listed: your introduction commit and your skills commit, with the most recent at the top.

✔️ Awesome, I've got everything!

Great. Make sure you've saved README.md and that git log --oneline shows both commits.

ⓧ I'd like to double check the full code

Your README.md should look something like this (your personal details will differ):

# Hi, I'm [[YOURNAME="your name"]]

I'm a developer learning to build things with code. I'm currently exploring web development and cloud computing.

## Skills

- HTML & CSS
- JavaScript
- Python
- Git & GitHub
Push the branch and open a pull request

Your commits only exist on your local machine right now. To get them onto GitHub and merge them into main, you'll push the branch and open a pull request.

  • Push your branch to GitHub by running:
git push origin add-introduction

What does this command do?

This uploads your add-introduction branch and all its commits to the origin remote (your GitHub repository). Since this branch is new to GitHub, Git creates it on the remote for you.

You should see output showing objects being pushed and a new remote branch being created.

Push rejected or authentication error?

If you see an authentication error, your personal access token or SSH key may not be configured correctly. Go back to Step 1 and verify your authentication setup.

If the push is rejected because the remote contains work you don't have, run git pull origin add-introduction first, then try pushing again.

Help me fix my push error

Now you'll create a pull request on GitHub to merge your changes into main.

  • Open your repository on GitHub in your browser.
  • You should see a yellow banner that says your branch had recent pushes. Click Compare & pull request.
  • Enter a title for your pull request (for example, Add profile introduction and skills).
  • Optionally add a description explaining what you changed.
  • Click Create pull request.
  • Click the Files changed tab to see your diff. This shows exactly what lines you added or removed.
  • Go back to the Conversation tab and click Merge pull request.
  • Click Confirm merge.

What is a pull request?

A pull request is a proposal to merge changes from one branch into another. It gives you (and your team) a chance to review the code before it becomes part of main. On real projects, teammates leave comments and request changes before approving.

The Files changed tab shows the diff: green lines are additions, red lines are deletions. This is how code review works in the real world.

Your changes are now merged into main on GitHub. But your local machine still has the old main. You need to sync it.

  • Switch back to your local main branch and pull the merged changes by running these commands:
git switch main
git pull origin main

What does git pull do?

The git pull command downloads changes from the remote (GitHub) and merges them into your current local branch. After this, your local main matches what's on GitHub, including the merged pull request.

  • Verify everything synced by running:
git log --oneline

You should see all your commits now on main: the initial commit, your introduction commit, and your skills commit.

Don't see your commits on main?

Make sure you merged the pull request on GitHub first. Check the pull request page to confirm it says "Merged". Then run git pull origin main again.

Also confirm you're on the main branch by running git branch. The active branch has a * next to it.

Help me find my merged commits

You've just completed the full GitHub Flow cycle: branch, commit, push, pull request, merge, and sync. Next up, you'll create a deliberate merge conflict to understand how they happen and how to resolve them.

Create and Resolve a Merge Conflict

Your profile README is live on GitHub, built through the branch-and-pull-request workflow that professional teams use daily.

But what happens when two people edit the same lines of a file on different branches? This is called a merge conflict. In this step, you'll deliberately create one so you can practice resolving it in a safe environment.

In this step, get ready to:
  • Create two branches that edit the same section of your README.
  • Merge the first branch cleanly into main.
  • Resolve a merge conflict when merging the second branch.
Set up two conflicting branches

Merge conflicts happen when two branches change the same lines of the same file. Git can't decide which version to keep, so it asks you to choose.

You're going to create this situation on purpose by making two branches that each add a different skill to the same spot in your Skills section.

  • Create and switch to a new branch by running this command:
git switch -c update-skills-v1
  • Open README.md in your text editor.
  • In the Skills section, add Python as a new bullet item at the top of your skills list.
  • Save the file.
  • Stage and commit your change by running these commands:
git add README.md
git commit -m "Add Python to skills"

What did you just do?

You created a branch called update-skills-v1 and added Python to your skills list on that branch.

The important thing is that main doesn't know about this change yet. This change only exists on the update-skills-v1 branch.

  • Switch back to main by running:
git switch main

If you open README.md now, you'll notice Python is gone. That's because you're back on main where the change hasn't been merged yet.

  • Create a second branch by running:
git switch -c update-skills-v2
  • Open README.md in your text editor again.
  • In the Skills section, add JavaScript as a new bullet item at the top of your skills list (the same spot where you added Python on the other branch).
  • Save the file.
  • Stage and commit your change by running:
git add README.md
git commit -m "Add JavaScript to skills"

Why does the position matter?

You added both skills to the same spot in the list deliberately. Git tracks changes by line number. When two branches modify the same lines, Git cannot automatically decide which change to keep.

If you had added Python at the top and JavaScript at the bottom, Git could merge both cleanly because the changes wouldn't overlap.

  • Confirm your commit was recorded by running:
git log --oneline

You should see your "Add JavaScript to skills" commit at the top.

Don't see your commit?

Make sure you saved README.md before running git add. Unsaved changes won't be staged.

Run git status to check if there are still uncommitted changes.

Help me figure out what went wrong with my commit

Merge the first branch

Now you'll merge the first branch into main. Since main hasn't changed in that area since the branch was created, this merge will be clean.

  • Switch back to main by running:
git switch main
  • Merge the first branch into main by running:
git merge update-skills-v1

This merges cleanly because main hasn't changed in the Skills section yet. Your README now includes Python in the skills list.

What is a clean merge?

A clean merge means Git was able to combine the changes from both branches without any overlap. The changes on your branch touched lines that main hadn't modified, so Git could apply them automatically.

  • Verify by opening README.md in your text editor.

You should see Python listed in your Skills section.

Merge didn't work?

Make sure you ran git switch main before running git merge. You must be on the branch that receives the changes (main), not the branch with the changes.

Help me fix my merge

Merge the second branch and resolve the conflict

Here's where it gets interesting. Main now has Python in the Skills section (from the first merge). But update-skills-v2 was created from a version of main that didn't have Python.

Both branches changed the same lines. Git won't know which version to keep, so it will ask you to decide.

  • Merge the second branch by running:
git merge update-skills-v2

You should see output mentioning a conflict in README.md.

Seeing this message? Don't freak out

This is exactly what's supposed to happen. A merge conflict is not an error. It's Git asking for your help because it found changes on both sides that it can't resolve on its own.

  • Open README.md in your text editor.

You'll see conflict markers that look something like this in your Skills section:

<<<<<<< HEAD
- Python
=======
- JavaScript
>>>>>>> update-skills-v2

What do these markers mean?

The section between <<<<<<< HEAD and ======= shows what's on your current branch (main, which now includes Python from the first merge).

The section between ======= and >>>>>>> update-skills-v2 shows what's on the incoming branch.

Your job is to delete the markers and decide what the final file should look like.

  • Delete all the conflict marker lines (<<<<<<< HEAD, =======, and >>>>>>> update-skills-v2).
  • Keep both - Python and - JavaScript lines so your skills list includes both.
  • Save README.md.

After resolving, that section of your file should look like this (with the rest of your skills still intact):

- Python
- JavaScript
  • Stage the resolved file by running:
git add README.md
  • Complete the merge by committing with a descriptive message:
git commit -m "Resolve merge conflict: keep both Python and JavaScript"
  • Push your resolved changes to GitHub by running:
git push origin main

What just happened?

You told Git that the correct resolution is to keep both skills. Running git add on the file marks the conflict as resolved. The git commit then creates a special merge commit that records how you resolved the conflict.

This merge commit has two parent commits (one from each branch) and your manual resolution in between. Anyone looking at the history can see exactly how the conflict was handled.

  • Verify your merge history by running:
git log --oneline

You should see your merge conflict resolution commit at the top, along with the earlier commits from both branches.

Still seeing conflict markers in your file?

Make sure you deleted all three types of marker lines: <<<<<<< HEAD, =======, and >>>>>>> update-skills-v2. If any remain, Git will include them as regular text in your file.

If you made a mistake, you can open README.md, remove the markers, save the file, then run git add README.md and git commit --amend to fix it.

Help me fix my conflict resolution

You just handled your first merge conflict. Next up, you'll clean up your branches and review the complete history of your project.

Clean Up and Review Your History

You just created and resolved a real merge conflict. That is the single most intimidating thing in Git for beginners, and you handled it.

Now it is time to tidy up. Professional developers delete branches after merging them so the repository stays clean and easy to navigate. You will also review your full commit history to see the branching and merging story you have written.

In this step, get ready to:
  • Delete all merged feature branches so only main remains.
  • View your full project history as a graph showing branches and merges.
  • Verify your live profile README on GitHub.
Delete your merged branches

Every branch you created has been merged into main. Keeping them around adds clutter and makes it harder to tell which work is still in progress.

  • Delete all three merged branches by running these commands:
git branch -d add-introduction
git branch -d update-skills-v1
git branch -d update-skills-v2

What do these commands do?

The -d flag stands for "delete" and only works on branches that have already been fully merged. This is a safety feature.

If you accidentally try to delete a branch with unmerged work, Git will refuse and warn you. You would need -D (capital D) to force-delete an unmerged branch.

  • Confirm only main remains by running:
git branch

You should see only * main in the output. The asterisk means it is your current branch.

Seeing an error about unmerged branches?

If Git says a branch is not fully merged, it means that branch's commits have not reached main yet. Go back and merge it first with git merge <branch-name>, then try deleting again.

Help me figure out why Git won't let me delete my branch.

Review your complete project history

Git keeps a record of every commit, branch, and merge you have made. Viewing it as a graph lets you see how your work branched off and came back together.

  • View your full history as a graph by running:
git log --oneline --graph

What does this command show?

The --oneline flag condenses each commit to a single line. The --graph flag draws ASCII lines showing where branches split off and where merges brought them back together.

You should see your merge commits connecting the different branches. This is the visual proof of the branching workflow you just practiced.

You should see a branching diagram with your commits, including the merge commit where you resolved the conflict between Python and JavaScript.

  • Now visit your live profile on GitHub. Open your browser and go to github.com/ followed by your GitHub username.

You should see your profile README displayed right on your profile page. It shows your introduction heading and your Skills section with both Python and JavaScript listed.

Don't see your README on your profile?

Make sure the repository name matches your GitHub username exactly, including capitalization. The repository must also be set to Public.

Also confirm that you pushed your latest changes. Run git status to check for unpushed commits, and git push origin main if needed.

Help me figure out why my profile README isn't showing up on GitHub.

Your repository is clean, your history tells a clear story, and your profile README is live for the world to see. Next up, you will take your profile to the next level with dynamic stats badges in the Secret Mission.

Secret mission

Add GitHub Stats Badges

Your profile README is looking great, but it's completely static. What if it could show live stats that update automatically? In this secret mission, you'll add dynamic GitHub stats badges that showcase your coding activity in real time.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally and uses free services, so there are no ongoing costs. Decide whether to keep your resources for future use, or remove them entirely.

Resources you used:

  • Local repository clone at ~/Desktop/<username>/.
  • GitHub profile README repository (public, on your GitHub account).
  • Git (installed via Homebrew or Xcode Command Line Tools).
  • SSH key or personal access token (created for GitHub authentication).

Keep everything running

No action needed. Choose this if you plan to keep updating your GitHub profile README or want to continue practicing Git workflows.

  • Your profile README will stay live on your GitHub profile page for anyone to see.
  • Your local clone remains on your Desktop for future edits.
  • Git stays installed on your machine for all future projects.
  • Your SSH key or personal access token remains configured for GitHub authentication.

Pause - I'll come back to this later

There is nothing to pause for this project. Git repositories do not consume ongoing resources. Your GitHub profile README will remain visible, and your local files will stay on your Desktop until you delete them.

  • If you want to free up Desktop space, you can move the local clone to another folder.
  • Your GitHub repository and profile README will remain untouched and ready for you to continue.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below for the resources you want to remove.

Delete the local repository clone
  • Remove the local folder by running this command in Terminal:
rm -rf ~/Desktop/[[GITHUB_USERNAME="your GitHub username"]]
Delete the GitHub profile repository
  • On GitHub, navigate to the main page of your profile repository.
  • Click Settings under your repository name.
  • Scroll down to the Danger Zone section and click Delete this repository.
  • Click I want to delete this repository.
  • Read the warnings and click I have read and understand these effects.
  • Type your repository name to confirm, then click Delete this repository.
Delete your personal access token (if you created one)
  • On GitHub, click your profile picture, then click Settings.
  • In the left sidebar, click Developer settings.
  • Under Personal access tokens, click Tokens (classic).
  • To the right of the token you created for this project, click Delete.
Remove your SSH key (if you created one)
  • Remove the local SSH key files by running:
rm ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub
  • On GitHub, go to Settings > SSH and GPG keys and delete the key you added for this project.
Uninstall Git (optional)

Git is a fundamental developer tool you will likely use for future projects. Only uninstall if you are sure you will not need it.

  • If you installed Git via Homebrew, uninstall it by running:
brew uninstall git

Nice Work!

Nice Work!

You did it! You've built a personal GitHub profile README from scratch using the same Git workflow that professional development teams use every day.

You now have the exact cycle that every open-source contribution, team project, and coding job relies on: branch, commit, push, pull request, merge.

What you accomplished:

  • Built a live GitHub profile README that displays on your profile page for anyone who visits.
  • Practiced the complete GitHub Flow workflow (branch, commit, push, pull request, merge) entirely from the command line.
  • Created and resolved a real merge conflict by editing the same file on two different branches.
  • Added dynamic GitHub stats badges to your profile using the full pull request workflow.

Ready to quiz yourself?