Learn About GitHub: What It Is, What It Is For, and Where to Start

Git is version control software that runs on a computer and tracks changes to files over time. GitHub is a website that hosts Git repositories online and adds collaboration tools on top: pull requests for reviewing changes before they merge, issues for tracking bugs and tasks, and a place for other people to find and contribute to a project. Git works without GitHub, and predates it by three years; GitHub is one of several hosted services (GitLab and Bitbucket are others) built around Git. Beyond storing code, GitHub is commonly used to deploy applications directly from a repository, to track work as a simple to-do list through issues, and to publish static websites through GitHub Pages.

The most common beginner confusion is treating Git and GitHub as the same thing, which makes half of the documentation unreadable until it clicks. Git is the tool that tracks changes. GitHub is a website built around that tool. Learning them in that order, rather than starting from GitHub’s interface, makes the rest of this make sense faster.

Table of contents

• Git vs GitHub
• The core objects: repos, commits, branches, pull requests, README
• What GitHub is for, beyond storing code
• A first-week plan
• What not to commit
• Reading a repository before touching it
• How this fits the rest of the stack
• FAQ

Git vs GitHub

Git runs locally. git init creates a repository on a computer, git commit saves a snapshot of the current files, and none of it requires internet access or an account anywhere. A developer can use Git for years on solo projects without ever creating a GitHub account, since every part of version history lives in a hidden .git folder inside the project itself.

GitHub adds a server to push that local history to, a web interface to browse it, and a set of collaboration features, reviews, issues, project boards, built around Git repositories. git push sends local commits to GitHub; git pull brings GitHub’s commits back down. The command belongs to Git; the destination belongs to GitHub.

The confusion usually shows up as a specific error: someone types git push before ever connecting a remote, and Git replies that there is no upstream repository configured, because Git itself has no idea GitHub exists until a remote is added with git remote add origin <url>. That single command is the entire bridge between the two tools; everything before it is Git working alone, and everything after it can involve GitHub.

GitLab and Bitbucket do the same job as GitHub, hosting Git repositories with a web interface and collaboration tools layered on top, which is why a resume line reading “experience with Git” and one reading “experience with GitHub” are answering slightly different questions. The first is about the tool; the second is about which hosted service someone has used it through.

The core objects: repos, commits, branches, pull requests, README

• Repository (repo): a project’s folder, plus its entire history of changes, hosted on GitHub with a URL such as github.com/username/project-name.
• Commit: a saved snapshot of changes, with a message describing what changed and why, identified by a long hexadecimal hash rather than a version number.
• Branch: an independent line of work, usually created to build a feature or fix without touching the main version until it is ready to merge.
• Pull request (PR): a request to merge one branch’s changes into another, with a space for comments, review, and automated checks before it merges.
• README: a file, usually README.md, shown automatically on a repository’s main page, explaining what the project is and how to use it.

A typical flow: create a branch, commit changes to it, push the branch to GitHub, open a pull request into main, get it reviewed, merge. Most of what makes GitHub useful beyond plain Git sits inside that pull request step, since it is the point where a change becomes visible to teammates before it becomes permanent.

A repository can also be public or private, a setting chosen when it is created and changeable later. Public means anyone can view the code and its full history; private restricts that to people explicitly invited. The free tier includes unlimited private repositories, which is a newer state of affairs than it sounds, since GitHub charged for private repos for most of its history.

What GitHub is for, beyond storing code

Storing code is the smallest part of what makes GitHub the default for so many teams and projects.

• Deploying: many hosting platforms connect directly to a GitHub repository and build a new deploy automatically on every push, which is how most modern deploy pipelines start.
• Issues as a to-do list: every repository gets a lightweight issue tracker, useful for a solo project’s task list just as much as for a team’s bug reports.
• GitHub Pages: free static site hosting built directly into a repository, enough for a simple portfolio, documentation site, or project page without a separate host.
• Discovery: public repositories are searchable and forkable, which is how open-source projects find contributors and how a beginner finds real code to read.
• GitHub Actions: automated jobs that run on a push or a schedule, tests on every commit, a nightly build, a deploy step, without a separate server to run them on.

The through-line across all of these is that a repository is not just a code archive: it is an event source. Every push, every merged pull request, every opened issue is something another tool can react to, which is the whole reason connecting GitHub to a deploy platform, a CI runner, or a project board feels less like configuration and more like plugging in a cable.

A first-week plan

1. Create a free GitHub account and set a profile picture and bio; this is the identity attached to every commit and contribution.
2. Install Git locally and set git config --global user.name and user.email so commits are attributed correctly from the first one.
3. Create one repository for a small project, even a throwaway one, and add a README explaining what it is.
4. Make a few commits over a few days, so the commit history and the idea of a saved snapshot become familiar.
5. Create a branch, make a change on it, and open a pull request into main, even alone, to see the review interface.
6. Star a few repositories in a language or framework of interest, and read one real project’s README and issues to see how an active project actually looks.

By the end of the week the goal is not fluency: it is familiarity with what a commit history looks like, what a pull request diff looks like, and where the issue tracker lives, so that joining a real project later is not the first time any of it has been seen.

What not to commit

A repository’s history is effectively permanent and, if public, visible to anyone, which makes a small set of files worth keeping out from the start.

• .env files and anything containing API keys, passwords, or database credentials.
• node_modules/, and any other dependency folder that gets reinstalled from a lockfile rather than tracked directly.
• Build output (dist/, build/) that is generated from source rather than hand-written.
• Large binary files and local editor or OS files (.DS_Store, IDE settings) that have nothing to do with the project itself.

A .gitignore file, added at the start of a project, tells Git to skip these automatically instead of relying on remembering not to run git add on them. GitHub’s repository creation form offers a .gitignore template for common languages and frameworks at the point of creation, which is the easiest moment to get this right.

If a secret does get committed, deleting the file in a new commit does not remove it. The old commit, and the secret inside it, still exists in the history and is fetchable by anyone with read access. The actual fix is rotating the leaked credential immediately, then treating the history rewrite as a separate, optional cleanup rather than the fix itself.

Reading a repository before touching it

Before making a change to an unfamiliar repository, the README, the issues tab, and any CONTRIBUTING file answer most first questions: what the project does, how to run it locally, and what kind of contributions are welcome. Skipping straight to editing code, without reading how the project expects changes to be proposed, is the most common way a first pull request gets stuck.

What to check specifically: whether the project uses issues to track what is being worked on, so a pull request does not duplicate someone else’s in-progress fix; whether there is a linked style guide or linter configuration that a change needs to pass; and whether recent merged pull requests give a sense of how large a single change is expected to be. A ten-file rewrite submitted to a project whose history is entirely small, focused commits is a mismatch the maintainer will notice before reading a single line of the diff.

How this fits the rest of the stack

The deploy-from-a-repository pattern mentioned above is exactly how RunxBuild works: connect a GitHub repository and every push builds and ships automatically, with build logs, environment variables, and rollback available from the same dashboard, on a service plan sized for whatever the first real project turns into. The RunxBuild hosting calculator prices that out once a repository is ready for a live route instead of just a README.

Useful related references:

• Bitbucket vs GitHub: A Decision About Your Toolchain, Not Your Git
• Git vs GitHub vs GitLab: One Is a Program, Two Are Companies
• Collaboration on GitHub: Branches, Reviews, CODEOWNERS, and Deploying on Merge
• Deploying from GitHub on RunxBuild

FAQ

What is GitHub used for?

Hosting Git repositories online, reviewing code changes through pull requests, tracking tasks and bugs through issues, publishing simple static websites through GitHub Pages, and, through integration with hosting platforms, deploying applications directly from a repository on every push.

Is GitHub free?

Yes, for public and private repositories with the core features: unlimited repositories, issues, pull requests, and GitHub Pages. Paid plans add features aimed at organizations, such as advanced access controls and additional compute for automated workflows.

What is the difference between Git and GitHub?

Git is version control software that runs locally and tracks changes to files; it works without any online account. GitHub is a website that hosts Git repositories and adds collaboration tools, pull requests, issues, and project pages, on top of what Git already does.

Do I need to know how to code to use GitHub?

Not to create an account, browse repositories, or even edit a file through GitHub’s web interface, which supports basic edits without any local setup. Meaningful use of branches, commits, and pull requests benefits from knowing at least basic Git commands, which come with practice rather than prior coding knowledge.

What should I not commit to a GitHub repository?

Secrets such as API keys, passwords, and .env files; generated folders like node_modules or build output that can be recreated from source; and large binary files or local editor settings that add noise without adding value. A .gitignore file set up at project start prevents most of these automatically.