How to use GitHub: a beginner's walkthrough

Most GitHub tutorials try to cover everything at once. Almost nobody needs everything at once. This is the smaller set of steps that gets a beginner from a blank account to a working project.

1. Create an account and install Git

Sign up at github.com with a username, email and password. Separately, install Git itself on your computer; GitHub’s own hosted git-guide has links for Windows, macOS and Linux. GitHub is the website, Git is the program running on your machine, and you need both.

2. Create your first repository

On GitHub, click the plus icon and choose “New repository.” Give it a name, tick “Add a README,” and create it. That README file is the one thing worth ticking on day one: it initializes the repository with a first commit, which makes cloning and pushing to it much less confusing than starting from a truly empty repository.

3. Clone it to your computer

“Clone” means downloading a full copy of the repository, history included, onto your machine. Copy the URL from the green “Code” button on the repository page, then run:

git clone https://github.com/your-username/your-repo.git

You now have a local folder that is connected back to the one on GitHub.

4. Make a change and commit it

Edit a file, or add a new one. Then run three commands:

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

git add stages the files you want to include. git commit saves that snapshot to your local history, with a message describing what changed. git push sends that commit up to GitHub, where it becomes visible to anyone who looks at the repository.

This is the loop. Almost everything else in Git is a variation on add, commit, push, repeated over the life of a project.

5. Branches, for when you want to try something without breaking anything

A branch is a parallel version of the repository. git checkout -b new-feature creates one and switches to it. Changes made there do not touch the main branch until you merge them back, which is why branches are the standard way to work on something risky or unfinished without disrupting a project other people are also touching.

6. Pull requests, for proposing a change

If you branch inside your own repository, or fork someone else’s, a pull request is how you propose merging your branch back into the main one. It shows a diff of every change, lets other people comment on specific lines, and keeps a permanent record of why the change was made. This is the mechanism that makes GitHub collaborative rather than just a backup location.

What trips beginners up

Forgetting to git add before committing is the most common early mistake; a commit with nothing staged does nothing. A close second is confusing commit (saves locally) with push (sends to GitHub) and wondering why a teammate cannot see a change that was only ever committed on your own machine.

Once you have some real history

A GitHub account with a handful of pushed commits and a couple of real repositories already contains more verifiable information about your work than most résumés do. If you want to see what that record looks like laid out for someone else to read, resumefromgit.com turns any public username into a visual CV and a downloadable resume PDF, pulling directly from the repositories and contribution history you already have.