Path B · Command Line

The Git Command Line Tutorial

Install Git, set up authentication, and push commits from a real terminal. The workflow you will use at your first job.

← back to the GitHub tutorial hub

You are in Path B — the command line tutorial

Before you start these steps, make sure you already have the shared setup done. If any of these are missing, click back to the hub and take care of them first.

1
You have a GitHub account. Hub → Create an account
2
You claimed the Student Developer Pack. Hub → Student Developer Pack
3
You created a repository. Hub → Create a repository
Fair warningThis path is harder than Path A. There are more steps, authentication is tricky, and you have to type commands correctly. If your capstone is due this week, do Path A instead and come back to learn this over the summer.

Step 1: Install Git

First thing: make sure Git is actually installed on your computer. Open a terminal window and check.

Open a terminal

macOS
  • Press ⌘ + Space, type Terminal, press Enter.
  • Or open Finder → Applications → Utilities → Terminal.
Windows
  • Press the Windows key, type Git Bash, press Enter (after installing Git below).
  • Or use PowerShell — search for it in the Start menu.

Check if Git is already installed

In your terminal, type this command and press Enter:

$ git --version

If you see something like git version 2.40.1, you are done with this step. Skip to Step 2. If you see command not found or an error, keep going.

Install Git

macOS
  • Easiest: just run git --version and macOS will offer to install it for you.
  • Or install Xcode Command Line Tools:
$ xcode-select --install

If you already use Homebrew, you can also run:

$ brew install git
Windows
  • Go to git-scm.com/download/win.
  • Download the installer and run it.
  • Accept all the default options — they are fine for beginners.
  • This gives you Git Bash, a real Unix-style terminal you can use for everything that follows.

Verify installation

Close your terminal, reopen it, and run:

$ git --version
git version 2.40.1

If you see a version number, Git is ready. Move on.

Step 2: Configure your identity

Git needs to know your name and email so your commits are labeled. This is a one-time setup on each machine. Use the same email you used for your GitHub account.

$ git config --global user.name "First Last"
$ git config --global user.email "your.email@example.com"

Verify both are set:

$ git config --global user.name
First Last
$ git config --global user.email
your.email@example.com

Set the default branch name to main (GitHub's default, so they match):

$ git config --global init.defaultBranch main

Step 3: Set up authentication

This is the part that trips everyone up. GitHub no longer accepts your account password from the command line. You need either a Personal Access Token or an SSH key. Pick one.

Option A: Personal Access Token (easier to set up)

Go to Developer settings
On github.com, click your profile picture (top right) → Settings → scroll down the left sidebar to Developer settings.
Click Personal access tokens → Tokens (classic)
Then click Generate new tokenGenerate new token (classic).
Name the token
Example: My laptop — capstone project. This is just a label so you remember what it is for.
Pick an expiration
90 days is a safe default. Less secure options exist (1 year, no expiration), but you will learn the renewal process this way.
Check the "repo" scope
Under "Select scopes," check the top-level repo box. That gives the token permission to read and write to your repositories. Do not check anything else unless you know what it does.
Click Generate token and COPY IT
GitHub will show you the token exactly once. It looks like ghp_xxxxxxxxxxxxxxxxxxxx. Copy it somewhere safe (a password manager is ideal). If you lose it, you will have to generate a new one.
Use it instead of a password
The first time you run git push, Git will ask for your username and password. Type your GitHub username, then paste the token where it asks for a password. Git will remember it for next time thanks to a built-in credential helper.

Option B: SSH key (cleaner long term, no passwords ever)

Run this in your terminal, replacing the email with yours:

$ ssh-keygen -t ed25519 -C "your.email@example.com"

Press Enter to accept the default file location. Press Enter twice more to skip setting a passphrase (or set one if you want extra security). This creates two files: a private key and a public key ending in .pub.

Copy the contents of the public key:

# macOS
$ pbcopy < ~/.ssh/id_ed25519.pub

# Windows (Git Bash)
$ cat ~/.ssh/id_ed25519.pub | clip

On github.com, go to SettingsSSH and GPG keysNew SSH key. Paste the key, give it a title like My laptop, and click Save. Done. You can now push and pull without typing a password ever again.

Which one should you pick?PAT is easier to set up the first time. SSH is less annoying long-term because it never asks for a password. If this is your first time, do PAT. If you plan to use Git for years, do SSH.

Step 4: Clone your repository

You already created a repo on github.com earlier. Now you need a local copy on your machine. This is called cloning.

Copy the repo URL from GitHub
Go to your repo page. Click the green Code button. Copy the URL. For PAT use HTTPS (https://github.com/...), for SSH use SSH (git@github.com:...).
Change to the folder where you want it
Example: put it in your Documents folder.
$ cd ~/Documents
$ git clone https://github.com/your-username/your-repo.git
Cloning into 'your-repo'...
remote: Enumerating objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

Now change into the new folder:

$ cd your-repo
$ ls
README.md

You are now inside a local copy of your repo. Any files you add, edit, or delete here can be pushed back up to GitHub with a few commands.

Step 5: The daily workflow

This is the loop you will run over and over. Memorize these five commands and you know 90% of Git.

Make a change

Open a file in your editor (VS Code, Sublime, Notepad, whatever), edit it, and save. You can also add brand new files.

Check what changed

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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        newfile.py

no changes added to commit (use "git add" to track)

Stage your changes

Staging means "I want these specific changes in my next commit." Use . to stage everything that changed:

$ git add .

Or stage one file at a time:

$ git add README.md
$ git add newfile.py

Commit with a message

$ git commit -m "Add login form and update README"
[main a1b2c3d] Add login form and update README
 2 files changed, 45 insertions(+), 2 deletions(-)

Push to GitHub

This uploads your commit to the github.com copy of the repo:

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 420 bytes | 420.00 KiB/s, done.
To https://github.com/your-username/your-repo.git
   9f8a7b6..a1b2c3d  main -> main

Refresh your repo page on github.com and you will see the new commit with your message. The files are live.

The full loop, all at once

# Make your edits in your editor, then:
$ git status                       # see what changed
$ git add .                          # stage everything
$ git commit -m "Clear message"      # save a snapshot
$ git push                          # upload to GitHub
First push needs extra flagsIf you started with git init locally instead of git clone, your very first push needs to tell Git where to send it:

git push -u origin main

After that first time, plain git push works.

Alternative: Start from an existing folder

What if your project already exists on your laptop and you have not created the GitHub repo yet? You can turn any folder into a Git repo with git init and push it up. Here is the full sequence.

# Step 1: Go into your project folder
$ cd ~/Documents/my-capstone

# Step 2: Initialize it as a Git repo
$ git init
Initialized empty Git repository in /Users/you/Documents/my-capstone/.git/

# Step 3: Stage everything
$ git add .

# Step 4: First commit
$ git commit -m "Initial commit"
[main (root-commit) f0e9d8c] Initial commit
 12 files changed, 340 insertions(+)

# Step 5: Rename the branch to main (if needed)
$ git branch -M main

# Step 6: Create an empty repo on github.com first, then copy its URL.
# Connect your local folder to it:
$ git remote add origin https://github.com/your-username/my-capstone.git

# Step 7: Push for the first time
$ git push -u origin main
Enumerating objects: 15, done.
Writing objects: 100% (15/15), 8.42 KiB | 8.42 MiB/s, done.
To https://github.com/your-username/my-capstone.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main' from origin.

After that, just use git add, git commit, and git push like in Step 5.

Command reference

The commands you will actually use, with one-line explanations. Bookmark this.

# Setup (run once per machine)
git config --global user.name "First Last"      # your name on commits
git config --global user.email "you@email.com"   # your commit email
git config --global init.defaultBranch main     # match GitHub default

# Starting a project
git clone <url>                                  # copy a GitHub repo to your machine
git init                                         # turn current folder into a Git repo
git remote add origin <url>                      # link local folder to GitHub repo

# Daily loop
git status                                       # what changed?
git add <file>                                   # stage one file
git add .                                        # stage everything
git commit -m "Message"                          # save a snapshot
git push                                         # upload to GitHub
git pull                                         # download changes from GitHub

# Looking around
git log --oneline                                # list past commits
git diff                                         # see unstaged changes
git diff --staged                                # see staged changes

# Undoing things
git restore <file>                               # discard unsaved changes to a file
git restore --staged <file>                      # unstage a file
git reset --soft HEAD~1                          # undo last commit, keep changes
Commands to think twice aboutgit reset --hard deletes uncommitted work. git push --force overwrites the GitHub copy and can destroy teammates' work. rm -rf .git deletes your entire Git history. If you see any of these in a Stack Overflow answer, understand what they do before running them.

Write a proper README.md

The README is the front page of your repo. When a recruiter, a professor, or your future self lands on the page, this is the first thing they read. A repo without a good README looks abandoned. A repo with a clear README looks professional, even if the code inside is modest. This is the single highest-leverage thing you can write.

What a good README always has

1
Project nameBig, clear title at the top.
2
One-line pitchWhat it does, in plain English.
3
Screenshot or demoEven a phone photo of the running app.
4
How to run itThe exact commands someone else would type.

The README protocol — the sections to include, in order

# Project Title
One # makes a big heading. Use the real project name, not capstone.
One-sentence description
What the project does and who it is for. This is the tagline a hiring manager reads in three seconds.
## Screenshot or Demo
Two ## makes a subheading. Drag an image into the GitHub editor and it uploads automatically. Even a rough photo of the running app is better than nothing.
## Features
A short bulleted list of what the project actually does. Three to six bullets. No marketing fluff.
## Tech Stack
The languages, frameworks, and databases you used. Example: Python 3.11, Flask, SQLite, Bootstrap 5.
## How to Run It
Step by step commands or actions so somebody else can get it running on their computer. This is the part that separates "nice project" from "real project."
## What I Learned
Two or three sentences about what you picked up. This section is gold in interviews — it shows you can reflect on your work.
## Credits / Author
Your name, a link to your LinkedIn, and credit to anyone whose tutorial or library you relied on.

Copy-paste README template

Here is a working template you can paste directly into your README.md and fill in. Markdown is just plain text with a few symbols — GitHub formats it automatically.

# Capstone Inventory App

A Python and SQLite inventory tracking application built for small businesses that need to manage stock without the cost of commercial software. Developed as my NOVA ITP 120 capstone project.

## Screenshot

![Screenshot of the app](screenshot.png)

## Features

- Add, edit, and delete inventory items
- Search and filter by category or supplier
- Low-stock alerts with configurable thresholds
- Export reports to CSV
- Simple login with hashed passwords

## Tech Stack

- **Language:** Python 3.11
- **Framework:** Flask
- **Database:** SQLite
- **Front end:** HTML, CSS, Bootstrap 5
- **Deployment:** Local only (capstone scope)

## How to Run It

1. Clone this repo: `git clone https://github.com/yourname/capstone-inventory-app.git`
2. Install dependencies: `pip install -r requirements.txt`
3. Initialize the database: `python init_db.py`
4. Start the app: `python app.py`
5. Open your browser to `http://localhost:5000`

## What I Learned

Working on this project taught me how to structure a real multi-file Python application, how to design a normalized SQLite schema, and how to handle user authentication safely with password hashing. The hardest part was the CSV export — encoding edge cases took me a full afternoon to debug.

## Credits

Built by First Last for NOVA ITP 120, Spring 2026.
LinkedIn: [linkedin.com/in/yourname](https://linkedin.com/in/yourname)
Flask tutorial adapted from the official Flask documentation.

## License

This project is open for educational use.

How to add it to your repo

Open README.md on your repo page
If you checked "Add a README file" when you created the repo, it is already there. Click the file name.
Click the pencil icon
Top right of the file view.
Paste the template and fill it in
Replace every placeholder with real information about your project. Do not leave placeholder text — it looks worse than no README at all.
Preview before committing
Click the Preview tab at the top of the editor to see how it will look formatted. Headings should be big and bold. Bullets should have dots. Code should look like code.
Commit with a message
Write Add project README and click Commit changes. Your repo front page is now professional.
The markdown symbols you need to know# for a big heading, ## for a sub-heading, **bold** for bold, *italic* for italic, - item for a bullet, `code` for inline code with backticks, and [text](url) for a link. That is 90% of what you will ever need.

Get your shareable URL

This is the URL you put on your resume, in your LinkedIn, and in cover letters. It is the whole reason we are doing this.

Your repo URL is always this format:

https://github.com/your-username/your-repo-name

Your profile URL (shows all your repos at once) is this:

https://github.com/your-username

You can get the exact URL by just copying it from your browser's address bar when you are on the repo page. That is the easiest way.

Put it on your resume like thisUnder your name and contact info: github.com/yourname (drop the https:// — it saves space and still works). Or link directly to the capstone repo if you only have one thing you want them to see.

Bonus: Make your capstone a live website

If your capstone is anything with HTML, CSS, or JavaScript in it (a portfolio site, a web app front end, a landing page, an interactive tutorial), GitHub Pages will turn your repo into a real live website for free in under a minute. This is huge. A live URL is 10x more impressive on a resume than a zip file.

Make sure your file is named index.html
GitHub Pages looks for a file called exactly index.html at the root of your repo. Rename your main file if needed before you upload.
Go to your repo's Settings tab
It is in the top right of the repo page, all the way over. Click Settings.
Click "Pages" in the left sidebar
Scroll the left menu until you see Pages. Click it.
Set the Source to "main" branch
Under "Build and deployment," change the branch dropdown to main and leave the folder as / (root). Click Save.
Wait about 60 seconds, then refresh
A green box will appear at the top of the Pages settings with your live URL.

Your live URL will look like this:

https://your-username.github.io/your-repo-name/

Every time you commit a change to your repo, the live site updates automatically in about a minute. No deployment headaches, no servers to maintain, no credit card required.

“Can I have a live Pages URL and keep my source code private?”Yes — if you claimed the Student Developer Pack. GitHub Pages for a private repo requires GitHub Pro, and the Student Pack gives you GitHub Pro for free. The built website itself is still publicly viewable at the yourname.github.io/repo URL, but the source code stays locked down. Without the Student Pack, a completely free account can only publish Pages from a public repo.
What if I want the website itself to be private too?Making the Pages website itself access-controlled (so only people you invite can even view the site, not just the code) is a GitHub Enterprise feature and it is not free. For almost every student capstone, you do not need this — "public site, private source" is the normal setup and that is what the Student Pack gives you.

That is the whole Path B tutorial

You can install Git, authenticate, clone a repo, push commits, and use the daily workflow loop. This is the skill you will use at your first job every single day.

← Back to the GitHub hub Resume Playground