Blog→Practice
ProgrammingFor beginners

Git and GitHub for beginners: what they’re for and how to upload your first project

2 Jul 2026 · 10 min read

Have you ever accidentally deleted a file you worked on all weekend? Or do you have projekt_final_v3_OPRAVDU_final.zip in a folder? This is exactly what Git was created for — a tool that remembers every version of your code and can return to it at any time. And GitHub adds a place on the internet where you back up, share and show your projects to the world. In this article we explain in plain language what Git and GitHub are, what you’ll use them for even as a beginner, and walk step by step through uploading your first sample project to GitHub.

A developer works on a laptop covered in GitHub Octocat stickers

Octocat — GitHub’s mascot — on a developer’s laptop. Photo: Christina Morillo, Pexels

What Git is and why everyone uses it

Git is a version control system — a program that tracks changes in your files and stores their history. Think of it as an endless “save as…” that, however, doesn’t create copies of files but tidy snapshots of the whole project over time. Each such snapshot is called a commit and carries a message, an author and the exact content of all files at that moment. You can look at any time at what changed and when, and return at any time to any older version — no change is lost.

Git was written in 2005 by Linus Torvalds (the author of Linux) because he needed to manage the development of the Linux kernel, on which thousands of people work at once. Today Git is the de facto standard: practically every software company in the world uses it and, according to surveys, over 90% of developers. That is why knowledge of Git appears even in job ads for junior positions — nobody will want expert tricks from you, but add, commit and push are expected automatically.

Quick intuition

Git is a “time machine” for your project folder. You say “remember this state” (commit) and Git saves it forever. If you break something tomorrow, you return to today’s state with one command — without copying folders and without final_v3 in the file name.

Git vs. GitHub: what’s the difference

Beginners often confuse the two names, yet the difference is simple. Git is a program that runs on your computer and keeps track of the project’s history. GitHub is a web service (today owned by Microsoft) to which you can upload your Git projects — something like “cloud storage for code”, but with much greater added value: web browsing of code and history, bug tracking (issues), discussions, collaboration of multiple people, and your own profile that works as a public portfolio. Git works entirely without GitHub; GitHub doesn’t work without Git.

Moreover, GitHub isn’t the only one — GitLab or Bitbucket offer the same principle. To start with, though, we recommend GitHub: it is free (even for private repositories), has the largest community and recruiters know it. Students also get the Student Developer Pack with a pile of free services.

What you’ll use Git and GitHub for even as a beginner

A frequent objection goes: “But I program alone, what do I need a tool for teams for?” Yet it is precisely beginners whom Git and GitHub help the most:

  • A backup that survives anything — disk dies, laptop gets lost? The project is on GitHub. git clone and in a minute you continue elsewhere.
  • Undoing mistakes — the experiment didn’t work out and the code is broken? You return to the last commit and that’s it. Git gives you the courage to try things, because you won’t destroy anything irreversibly.
  • A portfolio for recruiters — for juniors, the GitHub profile is often the first thing a company opens. A few polished sample projects say more than a paragraph in a CV.
  • A learning diary — the commit history is a record of your progress. In six months you’ll look back and see how much you’ve learned.
  • Collaboration and open source — when you want to contribute to someone else’s project or work in a team, Git and GitHub will be the path everything flows through.
  • A free website — via GitHub Pages you can turn a repository into a public web page with one click, for example for your portfolio.

Basic terms and how they relate

Before we start typing commands, let’s clarify the vocabulary. The whole everyday Git cycle revolves around four places between which changes move with three commands:

Working folderthe files youeditStaging areachanges readyto be savedLocal repositorycommit history(.git)GitHubremote repositoryin the cloudgit addgit commitgit pushyour computerinternetgit clone / git pull
A change’s journey: you edit a file in the working folder, prepare it with git add, git commit saves a snapshot into the local history and git push uploads the history to GitHub.
Term What it is In plain language
repository (repo) A project folder whose history Git tracks “a project under Git’s supervision”
commit A saved snapshot of the project with a message “remember this state”
staging area The anteroom — a list of changes that will go into the next commit “I want to save this”
branch A parallel line of development; the default one is called main “a sandbox for experimenting”
remote / origin A remote copy of the repository, typically on GitHub “a backup in the cloud”
push / pull Sending commits to GitHub / downloading news from GitHub “upload / download”
clone Downloading the whole repository including history “copy the project to your machine”
Table 1: Seven terms that will get you through the first months

You don’t need to deal with branches and merging yet — for your first projects a single main branch is plenty. When you want to go further, we recommend clicking through branching in the interactive playground Learn Git Branching.

Installation and first setup

Download Git from git-scm.com (Windows, macOS and Linux). On Windows the installer also adds Git Bash — a terminal in which all the examples from this article work. After installation introduce yourself to Git; the name and e-mail are recorded with every commit:

Bash
$ git --version
git version 2.50.1

$ git config --global user.name "Jana Novakova"
$ git config --global user.email "jana.novakova@example.com"

That’s all — the setup is one-time and applies to the whole computer. If the command line is still uncomfortable for you, there is also the official GitHub Desktop application, where you can do the same with the mouse. We recommend, though, that you master at least the basic commands in the terminal — they will work everywhere and thanks to them you’ll understand what is really happening.

Your first repository step by step

Let’s say you have a folder kalkulacka (calculator) with a small Python project — a few files you want to start versioning. Open a terminal in it and run:

Bash
$ cd kalkulacka
$ git init
Initialized empty Git repository in C:/projekty/kalkulacka/.git/

$ git status
On branch main
No commits yet
Untracked files:
  kalkulacka.py
  testy.py

git init turned the folder into a repository (a hidden subfolder .git was created, where Git hides the history). git status is your best friend — whenever you’re not sure what’s going on, call it; it prints which files have changed and what Git is waiting for. Now let’s save the first snapshot:

Bash
$ git add .
$ git commit -m "Prvni verze kalkulacky"
[main (root-commit) f3a9c21] Prvni verze kalkulacky
 2 files changed, 84 insertions(+)

git add . prepared all files into the staging area and git commit -m saved them with a message. From now on this state of the project is remembered forever. From here you just repeat the cycle: edit code → git add . → git commit -m "what I did". Feel free to commit in small steps — every time something works.

How to upload a project to GitHub

So far the history lives only on your disk. Let’s move it to the internet — for that you need a (free) account at github.com:

  • 1. Create a repository on GitHub. In the top right click + → New repository, enter a name (ideally the same as the folder, i.e. kalkulacka), choose Public and don’t tick “Add a README file” (we’ll create the README locally soon). Confirm with Create repository.
  • 2. Connect the local repository with GitHub. After creation GitHub shows you the repository’s address — you pass it to Git as origin (that’s the traditional name for the main remote repository).
  • 3. Upload the commits. The first push triggers a login — on Windows and macOS a browser opens and you just confirm (Git Credential Manager takes care of the rest).
Bash
$ git remote add origin https://github.com/jananovakova/kalkulacka.git
$ git push -u origin main
Enumerating objects: 4, done.
Writing objects: 100% (4/4), 1.32 KiB | 1.32 MiB/s, done.
To https://github.com/jananovakova/kalkulacka.git
 * [new branch]      main -> main

Done — refresh the repository page on GitHub and you’ll see your files and the commit history. From this moment, after every work session a git push is enough and the backup on the internet is up to date. Thanks to the -u switch on the first push, Git remembered where to send things.

README and .gitignore: your project’s business card and waste bin

Two small files turn “some folder with code” into a project that reads well. README.md is the first thing a visitor to the repository sees — GitHub displays it directly on the front page. Write in it: what the project does, how to run it and what you learned on it. You can master the Markdown format in ten minutes — headings with #, lists with -, code with backticks.

.gitignore, on the other hand, says what doesn’t belong in the repository: temporary files, virtual environments, package folders. For a Python project the basics look like this:

Text
# .gitignore
__pycache__/
.venv/
*.pyc
.env

At github.com/github/gitignore you’ll find ready-made templates for every language. And watch the .env line — files with passwords and API keys must never go into the repository (see common mistakes below).

GitHub as a portfolio that speaks for you

Two programmers go through code together on a laptop

Code on GitHub can be read by a friend, a mentor and a recruiter. Photo: Christina Morillo, Pexels

Once you have two or three projects on GitHub, spend an hour making the profile look good — it’s the cheapest career investment you can make as a beginner:

  • Every project has a proper README — with a description, instructions for running it and ideally a screenshot. A repository without a README looks like unfinished work.
  • Pin your best — you can pin up to 6 repositories on your profile; choose the polished ones, not all 30 attempts.
  • Meaningful commit messages — “Add tests for division by zero” says more than “update” or “asdf”. Recruiters really do open the commit history.
  • A green garden — the contribution graph on your profile shows regularity. Committing twice a week in small pieces looks (and teaches you) better than one giant bundle a month.
  • A profile README — a repository named the same as your account is displayed on your profile as a business card: who you are, what you’re learning, what you’re working on.

By the way — even in the age of AI assistants all of this makes sense. Why it pays to understand the basics even when artificial intelligence helps write the code is something we covered in the article Why learning to program is still worth it in the age of AI and vibe coding.

Common beginner mistakes (and how to avoid them)

  • Passwords and API keys in the repository. The most serious mistake — a public repository is also read by bots that abuse leaked keys within minutes. Secrets belong in .env, and .env in .gitignore. Once a key leaks, deleting it with a commit isn’t enough (it stays in the history!) — above all you must revoke it with the provider.
  • One commit a month. A giant “everything done” commit robs you of Git’s main advantage — the ability to return to an intermediate step. Commit small, working units.
  • Binary ballast. Videos, databases, node_modules or .venv don’t belong in the repository — that’s what .gitignore is for. GitHub outright rejects files over 100 MB.
  • Fear of breaking something. You won’t. As long as you commit, practically everything can be undone. The worst that happens is that you google “git how to undo last commit” — like all of us.
  • Waiting “until it’s perfect”. Nobody expects perfect code from a junior. An unfinished project with an honest README is worth more on your profile than emptiness.

What to do about it in practice

If you’re still looking for a first language and project, this guide is followed by a practical plan for how to start programming from scratch. You can then bring Git in from day one.

  • Today: install Git, create a GitHub account and upload your first project — even the one from today’s article. The whole thing takes 20 minutes.
  • This week: add a README and .gitignore, switch on the add → commit → push cycle after every work session on the project.
  • This month: go through Learn Git Branching and try your first branch; pin your best projects to your profile.
  • Continuously: write meaningful commit messages and look into the history once in a while — it’s your diary of progress.

Want to have something to show on GitHub?

In the Python Programming and Vibe Coding course you build portfolio projects from the first lesson — and use Git and GitHub along the way as in a real team. Git is also part of the basic kit for Linux, automation and deployment; the whole context is covered by the Start with Linux and DevOps course.

I want to program in Python →

Sources and further reading

Zdeněk Vais

About the author

Zdeněk Vais

Founder · Senior Principal Software Engineer, Oracle

Zdeněk has been programming since high school. Since then he has gone from programmer through team leader to architect, building large financial systems, scientific applications and IoT solutions for aircraft along the way. He currently works as a senior principal software engineer at Oracle, where he builds the cloud for media services.

Meet our team

← Back to the blog