Your first hour on GitHub: from zero to a repo

What your first hour on GitHub gives you

Your first hour on GitHub ends with four things: an account you will keep for years, one repository holding a real project, a README that explains what the project does, and a working push from your own computer. GitHub is a hosting service for git repositories, with review and automation tools built around them. It stores your code and every version of it, and it can serve a static website. It does not run your program.

That last sentence is where beginners lose the most time, so it is worth saying at the start. The rest of this guide is the hour itself, in order, with the error messages you will meet along the way. If you want the definition before the walkthrough, start with what GitHub is, and if the names still blur together, git, GitHub and a git server are three separate things.

Minutes 0 to 10: the account and the username

Sign up at github.com. The form is short. The one field worth thinking about is the username.

Your username becomes part of every address you will share, github.com/yourname/project, and part of every clone command anyone runs against your work. Pick something you would put on a job application. Lowercase, short, readable, no birth year. Renaming later is possible, and GitHub redirects links to your old repositories, but links to your old profile page return a 404 and the freed username can be claimed by anyone. Choosing well now saves that.

GitHub requires two-factor authentication (2FA, a second login step after the password) on accounts that contribute code, so it will ask you to enrol. Use an authenticator app on your phone and store the recovery codes somewhere other than that phone. If you lose the phone and the codes together, recovery is slow and often impossible, because nobody at GitHub can prove the account was yours.

Sign up with an email address you will still read in three years. You can add a college address as a second email later, which matters because the GitHub Student Developer Pack is granted through GitHub Education after checking proof that you are enrolled. Treat it as something to apply for and check eligibility on, not as something you already have. As of August 2026 the free plan already includes unlimited public and private repositories, so nothing in this guide depends on that application being approved.

Minutes 10 to 20: create your first repository

A repository, usually shortened to repo, is one project's files plus the complete history of every change made to them. Click the plus icon at the top right of the page and choose New repository.

1. Name it after the project, lowercase with hyphens. The name becomes the URL.
2. Write a one-line description. It appears in search results and on your profile.
3. Choose Public or Private. Public is readable by anyone. Private is readable only by you and the people you invite.
4. Tick "Add a README file". This makes the first commit, so the repository is not empty.
5. Pick a .gitignore template for your language. It keeps node_modules, .env files and build output out of the history.
6. Add a licence if the code is public. With no licence, other people have no legal permission to reuse the code.

The .gitignore choice matters more than it looks. A secret pushed to a public repository is public from that second on, and deleting the file in a later commit does not remove it from the history, so anyone can still read it. Automated scanners find committed API keys within minutes of the push. If it happens, rotate the key first and clean the history second.

Install git and tell it who you are

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git --version should print a line like git version 2.43.0. Ubuntu 24.04 and Debian 13 both ship a recent git. On Windows or macOS you install it from git-scm.com instead, and the two git config lines are the same everywhere.

The email in git config is not a login. It is a label stamped into every commit you make, and GitHub connects a commit to your profile by matching that label against the addresses on your account. Set it to an address GitHub knows, or your commits arrive with your name on them, linked to nobody, and missing from your contribution graph. If you would rather not publish a personal address, GitHub gives every account a no-reply address shaped like 12345678+yourname@users.noreply.github.com, listed on the email settings page. Use that one here.

Minutes 20 to 35: your password will not work, so set up a key

Git reaches GitHub over HTTPS or over SSH (secure shell, the encrypted protocol you also use to reach a server, covered in what SSH is and how key based login works). Your account password is refused on both. A push over HTTPS with a password fails like this:

remote: Support for password authentication was removed on August 13, 2021.
fatal: Authentication failed for 'https://github.com/yourname/my-first-site.git'

Over HTTPS the replacement is a personal access token, created under Settings, Developer settings, and typed in place of the password. Over SSH the replacement is a key pair, which is less typing over the following years. Make one:

ssh-keygen -t ed25519 -C "you@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub

Press Enter to accept the default file path. The passphrase prompt is optional, and setting one is worth the effort, because anyone who copies the private key file can push as you until you delete that key from your account.

ssh-keygen writes two files. ~/.ssh/id_ed25519 is the private key and never leaves this machine. ~/.ssh/id_ed25519.pub is the public half, and that is what cat just printed. Copy the whole line, starting at ssh-ed25519, then paste it into GitHub under Settings, SSH and GPG keys, New SSH key.

Test it before you need it:

ssh -T git@github.com

The first connection asks you to confirm the host fingerprint. Type yes. A healthy result is one line:

Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.

That message is a success. GitHub genuinely offers no shell, and the greeting proves your key was accepted. Permission denied (publickey). means it was not, usually because the pasted text was the private file, or only part of the public line, or was added to a different account. If the command instead hangs and times out, your network is blocking outbound port 22, which is common on college and office Wi-Fi. GitHub also answers SSH on port 443, so ssh -T -p 443 git@ssh.github.com gets through most of those networks, and setting the remote host to ssh.github.com with port 443 makes git use the same path.

Minutes 35 to 45: the three commands that put local work on GitHub

Some of these run once per project. Three of them run for the rest of your life. Start in the folder that holds your code.

cd ~/projects/my-first-site
git init -b main
git add .
git commit -m "First commit"
git remote add origin git@github.com:yourname/my-first-site.git
git pull --rebase origin main
git push -u origin main

Line by line:

• git init -b main creates a hidden .git folder in this directory and starts the history on a branch named main. Once per project.
• git add . stages every file the .gitignore does not exclude. Staging means marking a file for inclusion in the next commit.
• git commit -m "First commit" saves the staged files as one snapshot with a message attached.
• git remote add origin git@github.com:... stores the GitHub address under the short name origin. Once per project.
• git pull --rebase origin main fetches the README commit GitHub made for you and replays your commit on top of it.
• git push -u origin main sends your commits to GitHub. The -u records the pairing, so later pushes are just git push.

The pull --rebase line is there because you ticked "Add a README file", which means GitHub already holds one commit that your machine has never seen. Git refuses to push when the remote holds commits your local history does not contain, because the push would discard them. Leave the line out and you get this:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/my-first-site.git'

If your local folder already contained its own README.md, the rebase stops on a conflict in that file. Open it, keep the text you want, delete the <<<<<<< marker lines, then run git add README.md followed by git rebase --continue.

Check the result:

git status
git log --oneline

git status should say nothing to commit, working tree clean and report that your branch is up to date with origin/main. git log --oneline should list your commit and the README commit. Reload the repository page in the browser and your files are there.

From here the loop is three commands, every time you change anything:

git add .
git commit -m "Describe what changed"
git push

Two failures are worth recognising. error: src refspec main does not match any on a push means no commit exists on main yet, so the git commit step failed or never ran. nothing to commit, working tree clean when you know you edited files means you are in the wrong directory, or .gitignore is excluding them, and git status --ignored shows which.

What a commit, a branch and a pull request are

A commit is one saved snapshot of the whole project at a moment in time, carrying a message, an author and a timestamp. It covers every tracked file at once, which is why checking out an old commit gives you a project that still runs rather than a single restored file.

A branch is a movable name pointing at a commit. Creating one costs nothing, and work done on it leaves main untouched until you merge. main is the default branch, and it is the version visitors see first.

A pull request, written PR, asks for one branch to be merged into another. It gathers the changes, the discussion and any automated checks on one page. On a team, that page is where review happens. On your own repository a PR is optional, though it leaves a written record of why each change was made.

git switch -c add-contact-page
git add .
git commit -m "Add contact page"
git push -u origin add-contact-page

The push prints a link inviting you to open a pull request for that branch. Open it, read your own changes as a reviewer would, then merge.

What the README and the contribution graph are for

The README is the front page. GitHub renders README.md directly under the file list, so it is the first thing a visitor reads and, for most repositories, the only thing. Write four things into it:

• What the project does, in one sentence, without jargon.
• How to run it, as commands somebody can copy.
• What it needs first: language version, database, API keys.
• What state it is in. "Learning project, not maintained" is an honest and useful line.

A second README is worth ten more minutes. Create a repository whose name is exactly your username, put a README.md in it, and GitHub renders that file at the top of your profile page. A short paragraph about what you are learning and what you have built tells a visitor more than a list of half-finished repositories.

Recruiters do look at this profile, and they usually spend under a minute on it. They open the profile, glance at the pinned repositories, and read the top of one README. Six small projects that each start on a fresh machine, each with a clear README, read better than one large project nobody can run.

The contribution graph is the grid of squares on your profile. It counts commits, pull requests, issues and reviews. Two rules decide whether your work appears. The commit must carry an email address attached to your GitHub account, which is why the git config user.email step earlier matters. The commit must land on the default branch of a repository you own rather than in a fork. Private contributions are counted but hidden, and a profile setting shows them as anonymous squares.

Do not manage the graph. A daily commit that changes one character is visible to anybody who clicks it, and it reads worse than an empty week. The graph records work. It is not the work.

What GitHub will not run for you

GitHub stores code and runs short jobs. It does not host a running application, and this boundary catches most first projects.

GitHub Pages serves static files: HTML, CSS, JavaScript and images. It is a good home for a portfolio site, project documentation, or anything produced by a static site generator. It executes no PHP, Python or Node on request, so a login form, a shopping cart or an admin panel has nothing to run against.

GitHub Actions runs CI (continuous integration, automated jobs triggered by a push). A runner boots, runs your tests or your build, then is destroyed. There is no process left alive between runs, no disk that survives, and free accounts get a monthly allowance of minutes. When you need those jobs on hardware you control or beyond that allowance, point a self-hosted Actions runner at your own machine.

Here is what GitHub does not do at all: keep your application server alive between requests, run your database, hold a background worker open, fire a cron job on a real schedule, or store files your users upload. Each one needs a machine that stays switched on and belongs to you, which is what a VPS is and what it gives you. The normal shape of a small project is code on GitHub, the running application on a server, and a deploy step joining the two. If you have built something with an AI coding assistant and want other people to reach it, putting that generated app on a VPS walks the same split from end to end.

You can also keep the repository off GitHub entirely. A Gitea or Forgejo instance on your own server answers the exact commands you just learned, and the self-hosted git server options covers what you gain and what you take on. Learn the workflow here first. The commands do not change.

FAQ

Is GitHub free, and what does the Student Developer Pack add?

The free plan covers everything in this guide. As of August 2026 it includes unlimited public and private repositories, collaborators on them, and a monthly allowance of Actions minutes. The GitHub Student Developer Pack is a separate application through GitHub Education, approved after they verify that you are enrolled at a school, and it bundles offers from other companies on top of GitHub's own features. Check your eligibility and apply. If the application is refused, nothing described here stops working.

Why does my push fail with "Support for password authentication was removed"?

Because GitHub stopped accepting account passwords for git over HTTPS on 13 August 2021. The password still signs you into the website, and git now needs different credentials. Either create a personal access token under Settings, Developer settings, and paste it where git asks for a password, or add an SSH key and switch the remote with git remote set-url origin git@github.com:yourname/project.git. Confirm the key works with ssh -T git@github.com before you push again.

Why do my commits not appear on my contribution graph?

Almost always the commit email. GitHub attributes a commit by matching the address inside it against the addresses on your account, so a mistyped or stale git config user.email produces commits that show your name in the repository and link to no profile. Run git log -1 --format='%ae' to read the address on your last commit, then add that address to your account or correct the config. Fixing it applies to future commits and does not rewrite old ones. The commit also has to sit on the default branch of a repository you own rather than in a fork.

Do recruiters really look at my GitHub profile?

Yes, and briefly. They open the profile, scan the pinned repositories, and read the first few lines of one README. So the work that pays off is making a small number of projects easy to understand: a clear name, one sentence explaining what it does, and setup commands that actually run on a clean machine. The contribution graph gets a glance, because a green square proves a commit happened and says nothing about whether it was worth making.

Can GitHub host my website and my backend?

GitHub Pages hosts the website when the website is static files. It runs no server-side code, so it cannot serve a Django, Express or Laravel application, cannot talk to a database, and cannot run scheduled jobs. Those need a machine that stays running, which is what a VPS provides. The usual arrangement is to keep the code on GitHub and deploy from it onto that server.