Setting Up Your First GitHub Repository: A Step-by-Step Guide

Introduction

What happens if your laptop died tomorrow?

If you’re only using Git locally (like we learned in Part 1 - Understanding Git), your code dies with it. All those commits, that careful history, your hard work – gone.

That’s where GitHub comes in.

GitHub takes your local Git repository and gives it three superpowers:

1. Immortality – Your code lives in the cloud, surviving any hardware disaster
2. Accessibility – Work on your project from any computer, anywhere
3. Collaboration – Share with teammates without email attachments or USB drives

Think of it this way: Git is your time machine. GitHub is your time machine’s backup in the cloud, plus a way to let others use it too.

Today, we’ll take that repository you created in Part 1 and:

• Push it to GitHub (making it disaster-proof)
• Set up VS Code for easier workflows (no more memorizing commands)
• Create your first pull request (the foundation of collaboration)

In 30 minutes, you’ll go from “my code is safe on my laptop” to “my code is immortal and shareable.”

Ready to give your repository superpowers? Let’s start by creating your GitHub account.

Creating a GitHub Account

Before we create your account, let’s address the elephant in the room: why GitHub?

Simple answer: GitHub is where the code lives. With over 100 million developers and most open source projects hosted here, it’s the center of the software development universe. While alternatives like GitLab and Bitbucket exist, GitHub is where you’ll find the libraries you use, contribute to projects you love, and showcase your work to potential employers.

Best part? Everything we need is completely free. Forever. Private repositories, unlimited collaborators, all the core features – no credit card required.

Setting Up Your Account

Head to github.com and let’s get you set up. The signup process is straightforward, but let me guide you through the important decisions:

Your Username – Choose Wisely

This is more important than you might think. Your username becomes:

• Your GitHub URL: github.com/YOUR-USERNAME
• Part of every repository URL you create
• How other developers will remember and find you
• Often the first thing employers see when they Google you

Most developers use either:

• Their real name: jane-smith or johnchen
• A consistent professional handle they use everywhere

⚠️ While you can change it later, doing so breaks all existing links to your repositories. Choose something you’ll be happy with long-term.

Your Email Address

GitHub needs this for important notifications and account recovery. A few things to know:

• GitHub will send a verification code here (check spam if it doesn’t arrive in 2 minutes)
• This email can be hidden from public view (we’ll show you how)
• Remember in Part 1 when we configured git config --global user.email? You can use a GitHub-provided privacy email for that too!

Privacy Tip: After signing up, GitHub provides a no-reply email address like 12345678+username@users.noreply.github.com. This lets you make commits without exposing your real email. We’ll set this up in your account settings.

Creating Your Account

1. Enter your chosen username, email, and a strong password
2. GitHub might ask about email preferences – your choice on product updates
3. Complete the verification puzzle (proves you’re human)
4. Enter the verification code sent to your email

After Signing Up

Once you verify your email, GitHub might:

• Ask about your interests and experience level – feel free to skip this
• Show you a personalized dashboard – don’t worry about all the options yet
• Suggest creating your first repository – perfect, that’s exactly what we’re doing next!

What You’ve Just Joined

Congratulations! 🎉 You’re now part of the world’s largest developer community. This same account will:

• Become your coding portfolio (employers look at this)
• Track your contribution history (that green squares graph you might have seen)
• Let you contribute to any open source project
• Follow you throughout your entire development career

Quick Troubleshooting

Username taken? Try adding:

• Your middle initial: john-m-smith
• Numbers (birth year works): jsmith1995
• A descriptive suffix: jsmith-dev

Using a school/work email? Some institutions have restrictions. If you have issues, try a personal email instead.

Already have an account? No problem! Use “Sign in” instead. Forgot your password? GitHub’s recovery process is straightforward.

Setting Up Privacy (Optional but Recommended)

Let’s quickly protect your email privacy:

1. Go to Settings → Emails (or direct link)
2. Check “Keep my email addresses private”
3. Note your no-reply address that appears (like 12345678+username@users.noreply.github.com)
4. You can now use this in your Git config to keep commits private!

Perfect! Your GitHub account is ready. You’ve joined a community where your code can live forever, survive any hardware failure, and be shared with the world (or kept private – your choice).

Ready to upload that repository from Part 1? Let’s make your code immortal!

Creating Your First GitHub Repository

Remember that repository from Part 1 sitting on your computer? It’s time to give it a home in the cloud.

You have two options when creating a GitHub repository: start fresh on GitHub, or push an existing local repository (which is what we’ll do). Since you already have commits and history from Part 1, we’ll take the “push existing repository” approach.

Finding Your Way to Repository Creation

Once you’re logged into GitHub, you’ll see your avatar in the top-right corner. Click it and select “Your repositories” from the dropdown. This is your repository dashboard – think of it as your code library.

You’ll see a green “New” button. Click it, and let’s set up your repository’s new home.

Naming and Configuring Your Repository

Now you’re looking at the repository creation form. Let’s walk through each decision:

Repository Name

Let’s call it my-first-project to match what we created in Part 1. GitHub will show you if the name is available with a green checkmark.

Tip: Repository names become part of the URL. Keep them lowercase with hyphens instead of spaces. Good: my-awesome-project. Avoid: My Awesome Project!

Description (Optional but Recommended)

Add something like: “Learning Git and GitHub fundamentals - my first repository!”

This helps you remember what this project was about when you look back in six months.

Public or Private – The Big Decision

Here’s where you decide who can see your code:

Choose Public if:

• You want to build your portfolio (employers love seeing active GitHub profiles)
• You’re learning and want to share your progress
• You might want contributions or feedback from others

Choose Private if:

• This contains sensitive information
• It’s client work under NDA
• You’re just experimenting and not ready to share

For our learning project, I recommend Public. You can always change this later in settings.

Initialize This Repository – IMPORTANT

Here’s the critical part: you’ll see checkboxes for:

• Add a README file
• Add .gitignore
• Choose a license

Leave ALL of these unchecked!

Why? You already have a repository with commits from Part 1. If GitHub creates files here, you’ll have two different histories that conflict. We want a completely empty repository that’s ready to receive your existing work.

Creating Your Repository

With everything configured:

• Name: my-first-project
• Description: Added
• Visibility: Your choice (I suggest Public)
• Initialization options: All UNCHECKED

Click the green “Create repository” button.

What You’ll See Next

Perfect! GitHub just created your repository’s home. You’ll see a page with QuickSetup instructions. GitHub is smart – it knows this repository is empty and gives you exactly the commands you need.

Notice it says “…or push an existing repository from the command line” – that’s us! We have an existing repository from Part 1.

The page shows you these commands:

git remote add origin https://github.com/YOUR-USERNAME/my-first-project.git
git branch -M main
git push -u origin main

Don’t run these yet! Let me explain what each line does in the next section.

A Quick Celebration

Take a moment to appreciate what just happened:

• You created a home for your code in the cloud
• Your repository has a URL anyone can visit (if public)
• You’re about to connect your local work to the internet

Your code is one step away from being immortal. Ready to make the connection?

Connecting Your Local Repository to GitHub

Your GitHub repository is ready and waiting. Now let’s connect your local repository from Part 1 to its new home in the cloud.

Understanding What We’re About to Do

Think of this like setting up a backup drive for your computer. Your local repository (on your computer) needs to know where its backup location (GitHub) is. In Git terms, this backup location is called a “remote.”

Remote: A link between your local repository and another repository (usually online) Origin: The nickname Git uses for your main remote (you could call it anything, but “origin” is the convention)

It’s like saving GitHub’s phone number in your contacts as “GitHub” instead of typing the full number every time.

Making the Connection

Open your terminal and navigate to your Part 1 repository:

cd path/to/my-first-project

Let’s check that you’re in the right place:

git status

You should see something like “On branch main” and your files listed. Good? Let’s connect to GitHub.

Remember those commands GitHub showed you? Here’s the first one:

git remote add origin https://github.com/YOUR-USERNAME/my-first-project.git

Replace YOUR-USERNAME with your actual GitHub username. This command says: “Git, I want to add a remote connection called ‘origin’ that points to my GitHub repository.”

Verifying the Connection

Let’s make sure it worked:

git remote -v

You should see:

origin  https://github.com/YOUR-USERNAME/my-first-project.git (fetch)
origin  https://github.com/YOUR-USERNAME/my-first-project.git (push)

Perfect! Your local repository now knows about GitHub. The (fetch) means you can download from GitHub, and (push) means you can upload to GitHub.

A Quick Note About Branch Names

GitHub showed you another command:

git branch -M main

This ensures your branch is called “main” (the modern standard). If you followed Part 1, you’re already using “main.” You can verify with:

git branch

If it shows * main, you’re all set! Skip to the next section.

If it shows * master, let’s rename it to match GitHub’s expectation:

git branch -M main

This command renames your current branch from “master” to “main”. The -M means “move/rename even if the target already exists.” After running this, git branch should now show * main.

Why “main” instead of “master”? The Git community shifted to “main” as the default branch name in 2020. GitHub creates new repositories with “main” by default, so we’re aligning with that standard.

The Connection is Ready

Right now:

• ✅ Your local repository exists with all your commits
• ✅ Your GitHub repository exists (empty, waiting)
• ✅ They know about each other (connected via “origin”)
• ❌ Your code isn’t on GitHub yet (that’s next!)

Think of it like this: you’ve exchanged phone numbers with GitHub, but you haven’t sent any messages yet. Ready to push your code to the cloud?

Pushing Your Code to GitHub

This is it – the moment your code becomes immortal. Let’s push your local repository to GitHub and watch the magic happen.

Understanding Your First Push

Remember exchanging phone numbers with GitHub? Now it’s time to send your first message – all your commits, all your history, everything you built in Part 1.

The command GitHub showed you is:

git push -u origin main

Let me break this down:

• git push – Send your commits to a remote repository
• -u – Sets up tracking (like setting a default recipient for your messages)
• origin – Where to send it (that GitHub connection we just created)
• main – Which branch to push

The -u flag is clever – after this first push, you can simply type git push without specifying where. Git remembers.

The Moment of Truth

Take a deep breath and run:

git push -u origin main

What Happens Next: Authentication

Here’s something important: GitHub needs to verify it’s really you. You’ll likely see one of these scenarios:

Scenario 1: Browser Opens Automatically A browser window might pop up asking you to authorize Git. This is GitHub’s preferred method – click “Authorize” and you’re done!

Scenario 2: Username/Password Prompt You might see:

Username for 'https://github.com':

If this happens:

1. Enter your GitHub username
2. For password, you’ll need a Personal Access Token (not your GitHub password!)

Note: GitHub stopped accepting passwords in 2021 for security. If you need a Personal Access Token, here’s the quick version:

1. Go to GitHub Settings → Developer settings → Personal access tokens
2. Generate new token (classic)
3. Select “repo” scope
4. Copy the token and use it as your password

Don’t worry if this feels complex – you only do it once. Git remembers your credentials.

Watching the Upload

After authentication, you’ll see something beautiful:

Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (10/10), 1.23 KiB | 1.23 MiB/s, done.
Total 10 (delta 0), reused 0 (delta 0)
To https://github.com/YOUR-USERNAME/my-first-project.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

This is Git copying your entire history to GitHub. Every commit, every change, everything – now safely in the cloud.

The Victory Lap

Go back to your browser and refresh your GitHub repository page.

🎉 YOUR CODE IS THERE! 🎉

You should see:

• All your files
• Your commit history
• That README you created in Part 1
• A green “Code” button (anyone can now download your project if it’s public)

Try this: Open GitHub on your phone and navigate to your repository. There it is – accessible from anywhere in the world.

Testing Your New Superpower

Let’s prove your code is truly safe. Make a small change locally:

echo "This line was added after pushing to GitHub" >> README.md
git add README.md
git commit -m "Test commit after initial push"

Now push again – notice how simple it is this time:

git push

That’s it! No -u origin main needed. Git remembers where to push. Refresh GitHub and your new change appears instantly.

What You’ve Accomplished

Take a moment to appreciate this:

• ✅ Your code exists in two places (local + cloud)
• ✅ If your computer dies, your code survives
• ✅ You can access your code from any device
• ✅ Others can see your work (if public) and learn from it
• ✅ Every future commit can be backed up with a simple git push

Remember that 2 AM panic scenario from Part 1? Now it’s impossible. Your code is immortal.

A Small Challenge

Want to really feel the power? Here’s something brave:

1. Create a new folder somewhere else on your computer
2. Clone your repository: git clone https://github.com/YOUR-USERNAME/my-first-project.git
3. Watch your entire project appear from thin air

You just proved you can recover your work from anywhere. How’s that for peace of mind?

Ready to learn the easier way to do all this with VS Code?

Using VS Code for GitHub

You’ve learned the Git commands – now let’s look at how most developers work day-to-day. VS Code provides a visual interface for the same Git operations you just learned.

Installing VS Code

If you don’t have VS Code yet, download it from code.visualstudio.com. It’s free and works on all platforms.

Adding GitHub Integration

VS Code has built-in Git support, but the GitHub extension adds helpful features:

1. Open VS Code and press Ctrl+Shift+X (or click the Extensions icon)
2. Search for “GitHub Pull Requests and Issues”
3. Install it and restart VS Code if prompted

Opening Your Repository

Open your project folder in VS Code:

• File → Open Folder → Select your my-first-project directory

You’ll see your files in the sidebar and can edit them directly.

The Source Control Panel

Click the Source Control icon in the sidebar (third icon down, looks like a branch). This is where you’ll do most of your Git work.

Here’s how VS Code maps to the commands you know:

Making changes:

• Edit any file in the editor
• Changed files appear in the Source Control panel
• The “M” means modified (just like git status showed you)

Staging files:

• Hover over a changed file and click the + icon
• This runs git add for that file
• The file moves to “Staged Changes”

Committing:

• Type your message in the text box at the top
• Press Ctrl+Enter or click the checkmark
• This runs git commit -m "your message"

Pushing:

• Click the ... menu in the Source Control panel
• Select “Push”
• This runs git push

Understanding the Visual Feedback

VS Code shows you what’s happening:

• Blue numbers on folders show how many files changed inside
• Color coding in the editor: green lines for additions, red for deletions
• Status bar (bottom left) shows your current branch

Everything you see here corresponds to a Git command you already know. The interface just makes it faster to execute them.

Taking Stock of Your New Powers

Let’s pause and appreciate what you can now do. You started this article with code trapped on your computer. Now look where you are:

Your code lives in three places:

• ✅ Your local repository (with full history)
• ✅ GitHub’s cloud (safe from any disaster)
• ✅ VS Code’s visual interface (making it all effortless)

You can work two ways:

• Use commands when you need precision or automation
• Use VS Code when you want speed and visual feedback

Try this: Close VS Code, delete your local folder (yes, really!), then clone it back with:

git clone https://github.com/YOUR-USERNAME/my-first-project.git

Everything returns. Your code, your history, every commit. That’s the power of what you’ve built.

Conclusion: Your Code Is Truly Safe

Remember the promise from Part 1? We said you’d never lose code again. Now that promise extends beyond your computer.

You’ve transformed from someone working alone on one machine to someone who can:

• Access your code from anywhere
• Share your work with the world
• Recover from any disaster
• Choose between command line and visual tools based on what feels right

Your repository isn’t just backed up – it’s alive on the internet, ready to grow and evolve.

What’s Next: Collaboration and Automation

So far, you’ve been working solo. Your repository is like a single-player game – safe and functional, but isolated.

In our next article, we’ll unlock multiplayer mode. You’ll discover pull requests – GitHub’s powerful feature that transforms your repository from a backup into a collaboration hub.

More intriguingly, you’ll see how pull requests aren’t just about code review. They’re events that can trigger automated workflows. Every pull request can run tests, check code quality, even deploy applications – all automatically.

Ready to make your repository work with others and FOR you?

Continue to Part 3: [GitHub Pull Requests: Your Gateway to Collaboration and Automation] →

---

You’ve completed Part 2 of the GitHub Actions series! Your code is now immortal and accessible from anywhere. Next, we’ll make it collaborative and intelligent.