Git and GitHub for College Students: From Local Project to GitHub Repository

You wrote a project on your laptop. It works. Now you want it on GitHub so your teacher, a friend, or a recruiter can see it, and the first git push throws an error you do not understand.

This post walks through the whole path, from an empty folder to a pushed repo, and then the errors that usually show up on the way. I ran every command below on a real machine (Git 2.43) against a local test remote, so the outputs are what Git actually printed.

Git vs GitHub, in two lines

Git is a tool on your computer. It records snapshots of your project, called commits, so you can go back or see what changed.

GitHub is a website that stores a copy of your Git project online. Git works fine without GitHub. GitHub is just where people put their repos to share them.

A repository (repo) is a project folder that Git is tracking.

One-time setup

Tell Git who you are. This name and email get attached to every commit.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the same email as your GitHub account if you want commits linked to your profile.

Step 1: Turn a folder into a repo

mkdir my-project
cd my-project
git init

Output:

Initialized empty Git repository in .../my-project/.git/

On my machine Git also printed a long hint about the default branch name. That hint matters later, so keep it in mind.

Now add a file:

echo 'print("hello git")' > app.py
git status --short

?? app.py

?? means Git sees the file but is not tracking it yet.

Step 2: Stage and commit

Committing is two steps. First you stage the files you want in the snapshot. Then you commit them with a message.

git add app.py
git commit -m "Add first script"

[master (root-commit) 8d064d0] Add first script
 1 file changed, 1 insertion(+)
 create mode 100644 app.py

Look at the first word inside the brackets: master. That is the branch Git created for me. Remember it.

A few habits that help:

• Write messages that say what changed. "Add first script" beats "update".
• Commit small and often.
• Run git status whenever you are unsure what state you are in.

Step 3: Create the repo on GitHub

On github.com, click New repository. Give it a name, leave it empty (no README, no .gitignore, no license), and click Create. GitHub then shows you a URL like https://github.com/your-username/my-project.git.

Leaving it empty matters. If GitHub adds a README, your local repo and the online repo start with different histories and your first push will be rejected.

Step 4: Connect local to remote

A remote is just a saved link to another copy of your repo. By convention the main one is called origin.

git remote add origin https://github.com/your-username/my-project.git
git remote -v

In my test I used a local bare repo as the remote, so my output looked like this:

origin	../remote.git (fetch)
origin	../remote.git (push)

With GitHub you will see your GitHub URL there instead. The behaviour is the same.

Step 5: The push that fails (master vs main)

GitHub's default branch is main. Depending on your Git version and settings, git init may still create master. So you run the push command from GitHub's instructions:

git push -u origin main

And get this:

error: src refspec main does not match any
error: failed to push some refs to '../remote.git'

Read it slowly. It says: you asked me to push a branch called main, but I have no branch with that name. Your branch is master. Check:

git branch

* master

There it is. The mismatch is just a name.

Fix 1: rename your local branch to main

This is what I would do.

git branch -M main
git push -u origin main

To ../remote.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

-M renames the branch even if the name is taken. -u links your local main to origin/main, so later you can type plain git push.

Fix 2: push master into a remote branch called main

If you want to keep master locally:

git push -u origin master:main

To ../remote2.git
 * [new branch]      master -> main
branch 'master' set up to track 'origin/main'.

It works, but now your local master tracks a remote main. That is confusing a month later, so Fix 1 is cleaner.

Stop it happening again

Tell Git to name new repos main from the start:

git config --global init.defaultBranch main

Git 2.28 or newer supports this setting.

Step 6: Branches

A branch is a separate line of work. You try something on a branch, and if it works you merge it back into main. If it does not, you delete the branch and nothing is harmed.

git switch -c add-readme
echo "# My Project" > README.md
git add README.md
git commit -m "Add README"

Switched to a new branch 'add-readme'
[add-readme 495fd55] Add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Go back to main and merge:

git switch main
git merge add-readme
git push
git branch -d add-readme

Switched to branch 'main'
Your branch is up to date with 'origin/main'.
Updating 8d064d0..495fd55
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
To ../remote.git
   8d064d0..495fd55  main -> main
Deleted branch add-readme (was 495fd55).

"Fast-forward" means main had nothing new of its own, so Git just moved the pointer forward. No extra merge commit.

For solo college projects you can commit straight to main. Branches become useful when you work in a group or want to experiment safely.

Common errors after the first push

Rejected: fetch first / non-fast-forward

You push and get:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../remote.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.

The online repo has commits you do not have. Maybe a teammate pushed, maybe you edited a file on github.com, maybe you pushed from another laptop. Git refuses to overwrite them.

Fix: pull first, then push.

git pull --no-rebase --no-edit
git push

Merge made by the 'ort' strategy.
 notes.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 notes.txt
To ../remote.git
   e92fe90..f6a0bb1  main -> main

Please do not reach for git push --force to make the error go away. That overwrites the remote's commits, including your teammate's.

Merge conflict

If both sides changed the same lines, the pull stops:

CONFLICT (content): Merge conflict in app.py
Automatic merge failed; fix conflicts and then commit the result.

Open the file. Git marks both versions:

print("hello git")
# my edit
<<<<<<< HEAD
print('bye')
=======
# friend's line
>>>>>>> 19ba3faf8afa0169000c7478eb89b9abf0822b1a

Everything between <<<<<<< and ======= is yours. Everything between ======= and >>>>>>> is theirs. Edit the file to the version you actually want, delete the marker lines, then:

git add app.py
git commit -m "Merge friend's changes"
git push

To ../remote.git
   19ba3fa..f7a1f06  main -> main

Authentication failed

Since August 2021, GitHub does not accept your account password for Git operations over HTTPS. If you type your password, you get an authentication error. Two ways around it:

Option A: GitHub CLI. Install it from cli.github.com, then:

gh auth login

Pick GitHub.com, HTTPS, and log in through the browser. After that, git push just works.

Option B: Personal access token. On GitHub go to Settings, Developer settings, Personal access tokens, and generate one with the repo scope. When Git asks for a password, paste the token instead. Treat it like a password and never commit it into a file.

I could not run the login flows in my test setup because they need a browser, so follow GitHub's current docs for exact screens.

Accidentally committed junk

Things like __pycache__/, .env files, or virtual environments should not be in a repo. Create a file named .gitignore before your first commit:

__pycache__/
.venv/
.env
*.pyc

If a secret like an API key did get pushed, deleting it in a later commit is not enough. It stays in history. Revoke the key and make a new one.

A quick command cheat sheet

Command	What it does
git init	Start tracking a folder
git status	See what changed
git add <file>	Stage a file
git commit -m "msg"	Save a snapshot
git remote add origin <url>	Link to GitHub
git push -u origin main	First push
git pull	Bring in remote changes
git switch -c <name>	Create and move to a branch

What a finished repo looks like

If you want to see a real small project laid out on GitHub, look at Asha Kalavagunta's Sales Analytics Dashboard. It is an open-source Streamlit project that I studied, and it is a good example of a repo with an app file, an ETL script, a requirements file and a README. My GitHub has a copy of it too, but the original is hers, so that is the link to open. What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas)

Wrap-up

The path is short: git init, git add, git commit, git remote add, git push. Nearly every beginner error comes from three things: the branch is master but you pushed main, the remote has commits you lack, or you are logging in with a password instead of a token.

Once you can push, put your next project on GitHub from day one. How College Students Can Build a Strong GitHub Portfolio covers how to make those repos look good. My profile is at github.com/Pranaav717 if you want to follow along as I add projects.