What Is GitHub Used For? Explained

Teams use GitHub to keep code in one place, review every change before it goes in, and ship from the same site. Under the hood it hosts Git repositories and puts pull requests, issue tracking and automation around them.

Software teams and open source maintainers are the obvious users, but students and documentation writers work in it too.

Most of that work happens out of public view. In 2025, 81.5% of contributions landed in private repositories, even though 63% of all repositories were public (GitHub Octoverse, 2025).

What Is GitHub Used For?

Developers use it to store code, record every change, and work on one project together without overwriting each other. In practice that means an online copy of the project that any teammate can clone, plus a commit history where every change carries an author, a timestamp and a message.

New work happens on branches, away from the main line. The online copy also doubles as a backup beyond one laptop, and public repositories let anyone read the code, copy it and propose changes.

That trail of commits is what makes version control useful day to day. You see who changed a line and why, and you roll it back when it breaks something.

Repositories are public or private. Public ones are visible to everyone, private ones only to the people you invite.

GitHub’s Octoverse 2025 report counts 630 million repositories and more than 180 million developers on the platform.

How GitHub Differs From Git

Git is the version control tool. What GitHub does is host Git repositories online and build collaboration features around them.

Git came from Linus Torvalds. GitHub is a separate product that stores Git repositories and layers collaboration features over them, and how Git and GitHub differ comes down to that split.

You can use Git without GitHub, though not the other way around.

How Do Teams Collaborate on Code in GitHub?

Everything runs through branches and pull requests. Someone works on a branch, or on a fork if they have no write access, opens a pull request to propose the change, gets a review, and merges once the checks pass.

GitHub merged an average of 43.2 million pull requests per month in 2025, up 23% year over year (GitHub Octoverse).

1. Create a branch, or fork the repository if you have no write access
2. Commit your changes on that branch
3. Open a pull request against the base branch
4. Reviewers comment on the diff, then approve or request changes
5. Required status checks pass
6. Merge the pull request

Branches are parallel lines of work inside one repository, and they only help people who can write to it. Everyone else forks, which gives them a personal copy of someone else’s repository. A fork is how outside contributors on open source projects propose changes without touching the original.

The pull request is the unit of review. It shows the diff, holds the discussion, runs status checks and can require approvals before anything merges. Merging itself can be a merge commit, a squash and merge, or a rebase and merge.

Long-lived branches are where this workflow breaks down. They drift from the main line, and the conflicts arrive all at once at the end.

When two branches edit the same lines, GitHub blocks the merge until someone fixes it. Short-lived branches avoid most of that, and resolving merge conflicts in the web editor covers the small ones.

Tracking Work With GitHub Issues, Projects and Discussions

Tasks and bugs go in Issues. Projects arranges those same items as boards and roadmaps, and Discussions takes the open-ended conversation that doesn’t belong in a task list.

Each issue carries labels, assignees and a milestone, so tracking defects becomes a matter of filtering instead of memory.

In Projects, the same issues and pull requests show up as a board, a table or a roadmap. A walkthrough of setting up GitHub Projects covers the first board.

▶ GIT EXPLAINED

If you commit, branch, or merge code every day, it helps to know how Git came to be. This video covers how Linus Torvalds created Git in just 10 days after a license dispute and explains how its data model actually works.

Built in 10 Days Out of Spite. Git and its data model explained in plain language.

Questions, ideas and announcements get their own space in Discussions, which keeps the issue tracker clean.

Writing “Fixes #42” in a pull request closes issue 42 when it merges, and typing #42 in any comment links back to that issue.

Small and mid-sized teams get everything they need here. Larger programs with dependencies across many teams often outgrow it and add a dedicated planning tool.

How Does GitHub Automate Builds, Tests and Publishing?

Workflows are YAML files, and GitHub Actions runs them whenever an event such as a push or pull request occurs. Pages, releases and Packages take over from there and publish the output, whether that’s a static site, a downloadable build or a package.

GitHub Actions for CI/CD

Workflow files live in the .github/workflows folder of a repository, and they can be triggered by pushes, pull requests or a schedule.

A typical job runs the test suite, builds the project and deploys it. Teams that want that loop explained step by step can read about how GitHub Actions workflows run.

Concurrency limits for GitHub-hosted runners vary by plan, according to GitHub Docs.

Standard runners are free in public repositories. Private repositories get included minutes by plan, then metered billing, so a heavy test matrix gets expensive quickly.

GitHub Pages, Releases and Packages

Pages serves static HTML, CSS and JavaScript from a branch root or a /docs folder, and builds with Jekyll by default. Releases hold tagged versions with binaries attached. Packages is a registry for packages and containers.

Static sites are the fit. GitHub Pages turns a repository into a free site, which suits documentation, portfolios and project pages.

According to GitHub Docs, a published site can be no larger than 1 GB, the source repository should stay around 1 GB as well, and bandwidth has a soft limit of 100 GB per month.

It does not run server-side code. GitHub also says not to use Pages for sensitive transactions such as passwords or card numbers.

For large files, releases beat committing the binary to the repository.

Which GitHub Security Features Protect Your Code?

Dependabot watches your dependencies for known vulnerabilities, and code scanning looks at your own code. Secret scanning with push protection deals with leaked credentials, while branch protection rules control what gets merged.

Dependabot alerts flag dependencies with known vulnerabilities. Security updates open a pull request with the fix, and a dependabot.yml file schedules routine version updates.

Secret scanning looks for tokens and keys in your commits. Push protection blocks the push before the secret lands, which matters because keeping API keys out of a repository is far easier than cleaning them out of history afterward.

Code scanning runs CodeQL against the repository and reports flaws as alerts.

Branch protection rules require approved reviews and passing status checks before a merge. Strict mode, the default for required checks, also forces the branch to be current with the base branch.

Pricing first. Secret Protection cost $19 per active committer per month at its April 1, 2025 launch (GitHub), and Code Security cost $30 per active committer per month at launch (GitHub). Push protection is free on public repositories (GitHub changelog). Branch protection works on public repositories with Free, and on private repositories with Pro, Team or Enterprise (GitHub Docs).

Check current pricing before budgeting, since those are launch figures.

Alerts need triage. A scanner that flags 200 issues nobody reads protects nothing, and none of these tools replaces a human security review.

Writing Code With GitHub Copilot and Codespaces

Copilot is the AI assistant. Codespaces is a cloud development environment that opens a repository in a browser tab or in Visual Studio Code.

GitHub Copilot

Copilot completes lines and functions inline as you type and answers questions about code in chat. Agents go further, taking on multi-step tasks such as working an issue through to a pull request.

Plans split by buyer. Individuals pick Free, Student, Pro, Pro+ or Max, while Copilot Business covers organizations and Copilot Enterprise is for enterprises on GitHub Enterprise Cloud (GitHub Docs).

Every plan includes a monthly allowance of GitHub AI Credits, and paid plans can buy extra usage beyond it. GitHub moved all Copilot plans from premium requests to this usage-based billing on June 1, 2026, so older guides that count premium requests are out of date. Code completions and next edit suggestions are not billed in credits and stay unlimited on paid plans.

Check the plans page before budgeting, because credit allowances differ by plan.

Suggestions need review. Copilot predicts plausible code, not verified code.

Teams weighing a rollout can read a primer on how GitHub Copilot works first.

GitHub Codespaces

Personal accounts on GitHub Free include 120 core hours and 15 GB-month of Codespaces storage each month, while Pro includes 180 core hours and 20 GB-month (GitHub Docs, as of October 2026).

Core hours scale with machine size. A 2-core codespace running for an hour uses 2 core hours, so the Free quota covers 60 hours on the smallest machine.

Machine sizes run from 2 to 32 cores, and the larger the machine, the faster the quota disappears.

Organization and enterprise plans include no free usage at all. A team that adopts Codespaces pays from the first hour.

Each repository defines its own environment, so a new contributor opens a codespace instead of installing a toolchain. This explainer on how GitHub Codespaces work covers the setup.

Who Uses GitHub, and for What?

Different groups lean on different parts of the platform, from software teams working on private product code to data teams keeping scripts under version control.

Students and job seekers get the most from public repositories. Employers can read a public profile and the code behind it.

Documentation teams use the same pull request flow as engineers. In the docs-as-code approach, docs live with the code, follow its workflow and get reviewed alongside it, which suits teams that count technical documentation as part of the definition of done.

Can Non-Developers Use GitHub?

Yes. GitHub Docs’ own Hello World exercise runs in the browser, from creating a repository with a README through branching, editing, opening a pull request and merging.

Browser edits need no Git install. Markdown is the only syntax to learn, and issues double as a shared to-do list.

Markdown takes an afternoon, and a Markdown cheat sheet covers the syntax most pages use.

GitHub Plans, Cost and Alternatives

GitHub has a free plan, and the paid plans are listed at $4 per user per month for Team and $21 for Enterprise on GitHub’s pricing page in October 2026. Those rates are labeled as applying to the first 12 months, and GitHub says the price can change after the first year. Copilot and Codespaces bill on top of those fees.

GitHub Free, Team and Enterprise

Free costs $0 and is the entry point for individuals and open source work.

Team runs $4 per user per month for the first 12 months and adds multiple reviewers on a pull request. Enterprise is $21 per user per month for the first 12 months, and it brings Enterprise Managed Users, SCIM provisioning and an enterprise account that spans several organizations.

Microsoft completed its $7.5 billion stock purchase of GitHub in October 2018 and reports it inside its Intelligent Cloud segment (Microsoft Form 10-K). At the announcement, Microsoft said GitHub would operate independently (Form 8-K, 2018).

GitHub vs GitLab vs Bitbucket

Bitbucket’s free plan stops at 5 users per workspace, with unlimited public and private repositories (Atlassian).

GitHub is the default pick, though the cheapest fit depends on the team. If open source reach, Copilot or Actions workflows drive the decision, stay on GitHub. GitLab makes more sense when you want one vendor covering planning, CI/CD and self-managed hosting. Bitbucket is really only worth a look for a team of five or fewer that already runs Jira.

When GitHub Is Not the Right Tool

Large binary files are the usual breaking point. GitHub blocks any file over 100 MiB, warns at 50 MiB, and caps browser uploads at 25 MiB (GitHub Docs).

Git Large File Storage (Git LFS) raises that ceiling, with 10 GiB of storage and 10 GiB of bandwidth included on Free and Pro, and 250 GiB of each on Team and Enterprise Cloud (GitHub Docs).

Design files, datasets and game builds hit those blocks. LFS bandwidth is billed per GiB downloaded, and that includes downloads by GitHub Actions.

GitHub.com is cloud-hosted, so teams that need code on their own servers need GitHub Enterprise Server, or a GitLab Self-Managed instance.

For solo work where nobody reviews the code and nothing needs automation, Git alone handles source control. A private repository then mostly adds an offsite copy.

There’s also the single-vendor problem. Code, CI, packages and Copilot on one platform means one pricing change reaches all of them, and a second provider mirroring the code reduces that exposure.

How to Start Using GitHub

The whole loop is short. Create an account, create a repository with a README, make a branch, edit a file, open a pull request and merge it. GitHub Docs’ Hello World exercise walks through all of it in the browser.

1. Sign up at github.com and verify your email
2. Create a repository named hello-world with a README
3. Create a branch, such as readme-edits, from main
4. Edit README.md on that branch and commit the change
5. Open a pull request and review it
6. Merge the pull request, then delete the branch

A longer guide to creating a repository on GitHub covers the settings on the creation screen.

Working locally adds one step, which is installing Git and cloning the repository.

Write a README that says what the project does and how to run it. Add a license to public repositories, or nobody else has a clear right to reuse the code.

What to Turn On After the First Repository

The order matters here, because each step supports the next.

1. Dependabot alerts first. They’re free, and they catch vulnerable dependencies early.
2. Branch protection on main, so a merge needs a review and passing checks.
3. A test workflow in GitHub Actions, which gives branch protection a check to require.
4. Issue labels and a project board, once more than one person works in the repository.
5. GitHub Pages last, and only if the project needs a site.

Common Questions About GitHub

What is a GitHub gist?

For a code snippet or a block of text that doesn’t deserve its own repository, people use a gist.

Each gist is still a small Git repository underneath, so it keeps a revision history and can be forked.

What is a README file for?

GitHub displays the README right below the file list, which makes it the front page of a repository. It should say what the project does, how to install it and how to run it.

Most READMEs are written in Markdown.

Is private code safe on GitHub?

Private repositories are visible only to the people you grant access. Turn on two-factor authentication for every account with write access, since a stolen login bypasses every repository setting.

A separate look at whether GitHub is safe covers the risks in more depth.

Does GitHub work offline?

Git does, GitHub does not. You can commit, branch and merge locally without a connection, then push the work once you are back online.

Anything that lives on the platform, such as pull requests and issues, needs a connection.

What are GitHub CLI and GitHub Desktop?

From the terminal, GitHub CLI handles issues, pull requests and repositories.

GitHub Desktop is a graphical app for the same Git workflow, and a walkthrough of what GitHub Desktop does shows where it replaces typed commands.

What are GitHub Stars and GitHub Sponsors?

People star a repository to bookmark it and signal interest, which is why maintainers watch the count.

GitHub Sponsors goes a step further and lets people fund open source developers directly.

Which GitHub Features Are Worth Paying For?

The first paid upgrade belongs where private code needs control, which means branch protection and secret scanning. Hosting, issues and pull requests stay free for solo and open source work.

Price the upgrade per person before committing. A Team seat costs $4 per user per month, while Secret Protection costs $19 per active committer, so a five-person team pays $95 for scanning on top of $20 for seats, about 4.75 times the seat fee.

The trade-off is plain. Skipping paid scanning keeps the bill flat but leaves private repositories without push protection, so a leaked key lands in commit history before anyone sees it.

The position was verified in October 2026 and changes if GitHub reprices Team seats or moves secret scanning into the free tier.

For the day-to-day workflow after that decision, learn how to use GitHub from a first commit onward.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• How to Run a React App in VS Code Step by Step - October 23, 2026
• Transactional or marketing email: which messages your app should send itself - October 23, 2026
• How Software Teams Write SOPs for Releases and Deployments - October 22, 2026