31  31. Putting Your Repository on GitHub

So far your repository exists only on your computer. On this page you put a copy on GitHub. That gives you an online backup, a way to reach your work from other computers (Cloning and Pulling), and something you can show others. The steps: create an account, create an empty repository, let Git sign in to GitHub, then connect and push.

31.1 Step 1: Create a GitHub account

Go to github.com and sign up. A few tips:

  • Choose a professional username. It appears in all your repository addresses (https://github.com/YOUR-USERNAME/...), and future employers may look at your profile.
  • Use an email address you’ll keep after you graduate (you can add your school address too).
  • As a student you can apply for the GitHub Student Developer Pack, which includes free GitHub Pro while you’re a student, plus offers from other companies.

31.2 Step 2: Create an empty repository on GitHub

  1. In the upper-right corner of any GitHub page, click +, then New repository.
  2. Repository name: git-tutorial-project (letters, digits, ., - and _ only).
  3. Choose Public or Private (see the table below). Private is a safe choice for coursework.
  4. Don’t add a README, a .gitignore, or a license. Your project already has its own files. If GitHub creates files too, GitHub’s copy and yours start with different histories, and your first push is rejected.
  5. Click Create repository.

GitHub then shows a Quick Setup page with the repository’s address (URL), for example https://github.com/YOUR-USERNAME/git-tutorial-project.git, and the commands for pushing an existing repository. You’ll use them in Step 4.

Public repository Private repository
Who can see it everyone on the internet only you and the people you invite
Good for portfolio projects, open source coursework, work in progress

Either way, never commit secrets (see .gitignore and Keeping Secrets Out of Git): a private repository can be made public later, or shared with someone.

31.3 Step 3: Let Git sign in to GitHub

When you push, GitHub has to know it’s really you. Your GitHub password doesn’t work for this: GitHub removed password sign-in for Git commands. GitHub recommends a tool that signs you in through your web browser and then remembers you. The simplest choice depends on your computer:

Use the GitHub CLI (gh), GitHub’s official command-line tool. With Homebrew installed:

brew install gh
gh auth login

gh auth login asks a few questions. Answer:

  • where you use GitHub: GitHub.com
  • preferred protocol for Git operations: HTTPS
  • authenticate Git with your GitHub credentials: Yes
  • how to authenticate: Login with a web browser

It then shows a one-time code. Copy it, press Enter to open the browser, paste the code, and approve. Your login is saved in the Mac’s keychain, so you won’t be asked again. Check with gh auth status.

No Homebrew? Use a personal access token instead (see the deeper dive below).

Nothing to install. Git for Windows includes Git Credential Manager (the installer’s default credential helper). The first time you push (Step 4), a window opens and asks you to sign in to GitHub in your browser, and you may be asked to authorize the app. After that, Windows remembers your login.

(If you prefer, you can also use the GitHub CLI: install it from cli.github.com and run gh auth login as described in the Mac tab.)

Method How it works Good to know
GitHub CLI (gh auth login) Browser sign-in once; gh stores the login and hands it to Git. Recommended by GitHub; also gives you handy commands like gh repo create.
Git Credential Manager Browser sign-in the first time Git needs it; stored in Windows Credential Manager or the Mac keychain. Included with Git for Windows; a separate install on a Mac.
Personal access token (PAT) A long, random password-like code you create on GitHub (Settings > Developer settings > Personal access tokens) and paste when Git asks for a password. GitHub recommends fine-grained tokens. On a Mac, Apple’s and Homebrew’s Git remember it in the keychain. Treat it like a password: it’s a secret.
SSH key A key pair: the private key stays on your computer, and you upload the public key to GitHub. Needs git@github.com:... style addresses instead of https://.... More setup steps; many developers use it long term.

31.4 Step 4: Connect your repository and push

In the terminal, go to your project and add GitHub as a remote, a named link to another copy of your repository:

cd ~/projects/git-tutorial-project
git remote add origin https://github.com/YOUR-USERNAME/git-tutorial-project.git
git remote -v

Output:

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

Replace YOUR-USERNAME with your GitHub username (or simply copy the URL from GitHub’s Quick Setup page). origin is just a nickname for that long URL; it’s the conventional name for the main remote. The two lines say the same URL is used to download (“fetch”) and upload (“push”).

Now push:

git branch -M main
git push -u origin main

Output:

Enumerating objects: 24, done.
Counting objects: 100% (24/24), done.
Delta compression using up to 8 threads
Compressing objects: 100% (19/19), done.
Writing objects: 100% (24/24), 2.51 KiB | 2.51 MiB/s, done.
Total 24 (delta 5), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/YOUR-USERNAME/git-tutorial-project.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

(Your numbers will differ, and GitHub may add a few lines that start with remote:. On Windows, this is when the sign-in window appears the first time.)

  • git branch -M main renames your current branch to main. If it’s already called main, as it is if you followed Installing and Configuring Git, it changes nothing. GitHub’s Quick Setup page includes it for computers where the first branch is still called master.
  • git push -u origin main uploads your main branch (all its commits) to origin. The -u (short for --set-upstream) links your local main to origin/main, its upstream. That’s what the last line of the output says.
  • origin/main is Git’s record of where main is on GitHub.

Because of -u, Git now knows where to push, and git status compares your branch with GitHub’s copy:

git status

Output:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

From now on, the routine is: commit as usual, then upload with a plain git push (no -u origin main needed). If there’s nothing new to upload, Git says Everything up-to-date.

31.5 Step 5: Look at your repository on GitHub

Reload your repository’s page on GitHub. You’ll see your folders and files, the number of commits (click it to browse the history), and below the file list, your README.md displayed as formatted text. Notice what’s missing: .env (it’s ignored) and the empty docs/ folder. That’s exactly what you want.

You can also edit files directly on github.com. Each edit there is saved as a commit on GitHub, which you then bring to your computer with git pull (Cloning and Pulling).

31.5.1 README.md and Markdown

A README is the front page of a repository: what the project is, how to use it, who made it. README.md is written in Markdown (.md), a simple way to format plain text:

You type You get
# My Portfolio a big heading
## Features a smaller heading
- Home page a bullet point
1. Install a numbered list item
**important** bold text
[my site](https://example.com) a link
`git status` code

For example, this README.md:

# Maria Lopez - Portfolio

A personal portfolio website, built while learning Git.

## Pages

- Home page
- Contact page (coming soon)

Run it by opening `src/index.html` in a browser.

shows on GitHub as a heading, a paragraph, a “Pages” subheading with a bullet list, and a sentence with src/index.html in code font.

31.6 Shortcut: gh repo create

If you use the GitHub CLI, one command run inside your project folder can replace Steps 2 and 4. It creates the repository on GitHub, adds the remote, and pushes:

gh repo create git-tutorial-project --private --source=. --remote=origin --push
  • --private (or --public): the visibility.
  • --source=.: use the repository in the current folder (.).
  • --remote=origin: the name of the remote to add.
  • --push: push your commits right away.

Practice Questions

Easy

Question 1 · Multiple choice

Why should you create the GitHub repository without a README when you plan to push an existing project?

  1. GitHub doesn’t allow READMEs in private repositories
  2. Your project already has its own history; files created on GitHub start a different history, so your first push is rejected
  3. A README makes the repository public
  4. README files can only be created with git commit

b. If GitHub creates a README (or .gitignore or license), GitHub’s copy has a commit your computer doesn’t have, and the two histories don’t fit together, so git push is rejected. Private repositories can have READMEs (a), a README doesn’t change visibility (c), and you can add a README any time later (d).

Question 2 · True or false

When git push asks you to sign in, you can use your GitHub account password.

False. GitHub no longer accepts account passwords for Git commands. Use browser sign-in through the GitHub CLI or Git Credential Manager, or a personal access token (or an SSH key).

Question 3 · Short answer

What is origin in git remote add origin https://github.com/...?

A nickname for the remote repository’s URL. origin is the conventional name for the main remote (here, your repository on GitHub), so you can type origin instead of the long URL.

Question 4 · Matching

Match each command with what it does.

Command What it does
1. git remote add origin <url> A. lists the remotes and their URLs
2. git remote -v B. renames the current branch to main
3. git branch -M main C. uploads new commits to the upstream branch
4. git push -u origin main D. adds a remote named origin
5. git push E. first push: uploads main and sets origin/main as its upstream

1 → D, 2 → A, 3 → B, 4 → E, 5 → C.

Question 5 · Compare

Who can see a public repository, and who can see a private one?

A public repository can be seen by everyone on the internet. A private repository can be seen only by you and the people you explicitly give access to.

Question 6 · Short answer

What does the -u in git push -u origin main do, and why is it useful?

-u (--set-upstream) links your local main branch to origin/main (its upstream). Afterwards, plain git push and git pull know where to go, and git status can tell you whether you’re ahead of or behind GitHub. You only need -u on the first push.

Medium

Question 7 · Write the command

Sam created an empty GitHub repository at https://github.com/YOUR-USERNAME/budget-app.git. His local repository ~/budget-app already has commits on main. Write the commands to connect it and push for the first time.

cd ~/budget-app
git remote add origin https://github.com/YOUR-USERNAME/budget-app.git
git push -u origin main

(Adding git branch -M main before the push is harmless.)

Question 8 · Read the output

Explain the last two lines of this push output:

 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
  • * [new branch] main -> main: GitHub didn’t have a main branch yet; your local main was uploaded and created there.
  • branch 'main' set up to track 'origin/main'.: because of -u, your local main now has origin/main as its upstream, so future git push and git pull commands need no extra arguments.

Question 9 · Find the bug

Maria added the remote but ran plain git push for her first push. Git answered:

fatal: The current branch main has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin main

What does it mean, and what should she type?

Her main branch isn’t linked to a branch on GitHub yet, so plain git push doesn’t know where to push. She should run the first push with the upstream option:

git push -u origin main

(-u is the short form of --set-upstream.) After that, git push alone works.

Question 10 · Write the file

Write a README.md for a project called “Club Events” with: a top-level heading, one sentence describing it, a “Features” subheading with two bullet points, and a link to https://example.com.

# Club Events

A web app where students sign up for club events.

## Features

- Browse upcoming events
- Sign up with one click

More information: [project site](https://example.com)

Question 11 · Scenario

After her first push, Maria looks at her repository on GitHub. Her .env file and her empty docs/ folder are missing. Did the push fail?

No, this is correct. .env is listed in .gitignore, so it was never committed, which is exactly what keeps her API key off GitHub. Empty folders are never committed by Git. A push uploads commits, so only files that are in her commits appear on GitHub.

Question 12 · Multiple choice

Sam (Windows) installed Git for Windows with the default choices. What does he need to do so that git push can sign in to GitHub?

  1. Nothing: Git Credential Manager will open a browser sign-in the first time he pushes
  2. Install Homebrew and the GitHub CLI
  3. Type his GitHub password when asked
  4. Create an SSH key; nothing else works on Windows

a. Git Credential Manager comes with Git for Windows (it’s the installer’s default credential helper) and handles the browser sign-in. Homebrew (b) is a Mac tool. Passwords (c) aren’t accepted for Git. SSH (d) works, but it’s optional.

Question 13 · Write the command

Using the GitHub CLI, write one command that, run inside the project folder, creates a public GitHub repository named recipes, adds it as the remote origin, and pushes the existing commits.

gh repo create recipes --public --source=. --remote=origin --push

Hard

Question 14 · Find the bug

Maria runs git remote add origin https://github.com/YOUR-USERNAME/portfolio.git and gets error: remote origin already exists. Why? How can she check what origin points to, and how can she fix it if the URL is wrong?

Her repository already has a remote named origin (she added one earlier, or the repository was cloned). She can check it with:

git remote -v

If the URL is wrong, she changes it instead of adding a second origin:

git remote set-url origin https://github.com/YOUR-USERNAME/portfolio.git

Question 15 · Scenario

Sam created his GitHub repository with a README. His first push is rejected with ! [rejected] main -> main (fetch first), and git pull origin main says fatal: refusing to merge unrelated histories. Explain what’s going on and give the simplest fix for a beginner.

GitHub’s repository has its own first commit (the README), which has nothing in common with Sam’s local history: the two histories are unrelated. Git refuses to overwrite GitHub’s commit when pushing, and refuses to combine unrelated histories when pulling.

Simplest fix, since the GitHub repository contains nothing he needs: delete it on GitHub (repository Settings, “Danger Zone”, Delete this repository), create it again empty, and push again with git push -u origin main.

(It is possible to combine them with git pull --no-rebase --allow-unrelated-histories origin main, but if both sides have a README.md, Git reports a merge conflict to resolve first; see Merge Conflicts.)

Question 16 · Scenario

A classmate suggests: “Just make your repository private, then you can commit your .env file with the API key.” Give two reasons why this is a bad idea.

Any two of:

  • A private repository can be made public later, or shared with collaborators (and their computers), exposing the key.
  • Once committed, the key stays in the history forever, even if you delete the file later.
  • Anyone who gets access to the repository, now or later, can use the key and run up charges or misuse your account.
  • .env files exist precisely so that secrets stay out of Git; the code can be shared safely, and each computer gets its own .env.

Question 17 · Long answer

Describe, step by step, what happens when Maria runs git push -u origin main for the first time on her Windows lab account (with Git Credential Manager).

  1. Git looks up the remote origin and finds its URL.
  2. GitHub needs to know who she is. Git Credential Manager opens a browser sign-in (first time only), and the login is stored for later.
  3. Git uploads every commit (and file version) on main that GitHub doesn’t have yet; for a new repository, that’s the whole history.
  4. GitHub creates the main branch (* [new branch] main -> main).
  5. Because of -u, Git links local main to origin/main (branch 'main' set up to track 'origin/main'.), so future pushes and pulls need no arguments.

Question 18 · Compare

Compare signing in with a personal access token and with browser sign-in (GitHub CLI or Git Credential Manager). Which would you recommend to a beginner, and why?

  • Personal access token: you create a long secret code on GitHub and paste it when Git asks for a password. It works everywhere, but you must create it, choose its permissions, store it safely (it’s a secret, like a password), and replace it when it expires.
  • Browser sign-in: you log in to GitHub in your browser once, and the tool stores and manages the credentials for you.

For a beginner, browser sign-in (Git Credential Manager on Windows, GitHub CLI on a Mac) is simpler and safer: there’s no token to copy around or accidentally leak. A token is a good fallback when those tools aren’t available.

© 2025-2026 Y. Rosenthal. All rights reserved.