GitHub

Overview

You modify three files.

You make a commit.

You push everything to a repository.

From there, the code can be reviewed, commented on, tested automatically, linked to an issue, included in a release, deployed, scanned for vulnerabilities, and increasingly handed to agents capable of continuing part of the work.

The commit was only the beginning.

That is probably the best way to understand GitHub.

Git is not GitHub

The confusion is understandable because the two names almost always appear in the same sentence.

Git is the distributed version control system used to track the evolution of a project, create branches, and merge changes.

GitHub is a platform built around that mechanism.

Developed by GitHub, Inc., it hosts repositories and adds an entire environment around the code: accounts, organizations, discussions, reviews, automation, security, packages, documentation, development environments, project management, and artificial intelligence.

You can perfectly well use Git without GitHub.

But GitHub managed something more difficult: turning version control into a shared workspace.

The repository as the center of the project

On GitHub, a repository is not merely a remote folder containing code.

It becomes the meeting point for several layers:

This proximity changes a lot.

An issue can lead to a branch.

The branch to a pull request.

The pull request to a test workflow.

The workflow results return to the pull request.

The merge can trigger a release or deployment.

Everything stays connected to the same project.

GitHub does not replace Git. It builds everything that can happen around it.

From open source to enterprise infrastructure

GitHub also has a slightly unusual identity.

It is both a professional platform and a gigantic public space.

A student can publish a first project there.

An open-source library can receive contributions from around the world.

A company can manage thousands of private repositories, enforce security policies, control access, and automate deployments.

The underlying mechanics remain surprisingly similar.

The constraints, obviously, do not.

GitHub therefore offers several tiers: Free, Pro, Team, and Enterprise, with Enterprise available in the cloud as well as through the self-hosted GitHub Enterprise Server.

That range partly explains its position in the ecosystem.

You can start for free with a personal repository.

And a few years later, find yourself administering an entire development pipeline without really having left the platform.

Features

Repositories, branches, and history

The repository remains the heart of GitHub.

A repository can be public or private and contain the code, its Git history, documentation, and various files used to configure associated services.

On top of Git, GitHub provides an interface for browsing:

• files and folders;
• commits;
• branches and tags;
• contributors;
• differences between versions;
• releases;
• forks.

Complex operations remain available from the command line.

But many actions can also be performed through the browser, GitHub Desktop, the GitHub CLI, or third-party tools.

That diversity matters.

GitHub does not really force one single way of working with Git.

Pull requests: making change visible

The pull request is probably the idea that best represents GitHub.

A branch contains a change.

The pull request turns it into a conversation.

You can see precisely what changed, comment on specific lines, request corrections, launch reviews, link the work to an issue, and verify test results before allowing the merge.

It brings together three things that used to be much more separate:

the code, the discussion, and the decision.

Teams can go further with protected branches, mandatory reviewers, CODEOWNERS, or repository rules so that a change can only be merged after certain validations have been completed.

The green “Merge” button looks simple.

What matters is everything that can be required before you are allowed to click it.

Issues and Projects: the work around the code

Not every project problem begins with a line of code.

An Issue can represent a bug, an improvement, an idea, a question, or a task.

It can receive labels, assignees, milestones, sub-issues, and dependencies.

GitHub Projects can then organize this work into different views and connect planning directly to issues and pull requests.

It does not necessarily replace Jira, Linear, or a specialized project management system.

But for many software projects, proximity to the repository is exactly what makes it useful.

A task is not merely described somewhere.

It can remain attached to the change that eventually resolves it.

GitHub Actions: when the repository starts reacting

A developer pushes a commit.

A few seconds later, several machines begin working.

Tests run.

Linting checks the code.

An application is compiled.

A package can be built.

A release can be prepared.

A deployment can begin.

GitHub Actions makes it possible to define these automations in YAML workflows stored directly in the repository.

The trigger can be a push, a pull request, a release, a schedule, a manual action, or many other events.

This integration is one of GitHub’s major strengths.

Automation is no longer an external system that has to be awkwardly connected to the project.

It lives just a few folders away from the code it tests.

Codespaces: opening the project before preparing the machine

Setting up a development environment can sometimes take longer than understanding the bug you wanted to fix.

Python version.

SDK.

Extensions.

Variables.

System dependencies.

Then the famous missing configuration file because it “was obviously already on Paul’s machine.”

GitHub Codespaces moves that environment to the cloud.

A project can define its configuration through a dev container and allow a developer to open an already prepared environment from the browser or a compatible editor.

For personal accounts, GitHub includes monthly compute and storage allowances depending on the plan.

Once those are exceeded, usage becomes billable if a budget has been configured.

Codespaces is therefore not simply “VS Code in a browser.”

It is mainly a way to make the development environment reproducible and disposable.

Security: watching what the repository carries with it

A modern project rarely contains only handwritten code.

It depends on dozens, sometimes thousands, of packages.

It handles tokens.

It builds artifacts.

It receives external code.

GitHub therefore provides several integrated security layers.

Dependabot can report vulnerable dependencies and propose updates.

Secret scanning looks for exposed API keys, tokens, and other credentials.

Push protection can stop certain secrets from being committed to the repository.

Code scanning, notably with CodeQL, analyzes code for vulnerabilities.

The exact availability of these features varies depending on whether the repository is public or private and which security products are enabled.

But the general idea is interesting:

Security moves closer to the moment when code is written, instead of waiting until the end of the project to discover what slipped inside.

Packages, Releases, and Pages

GitHub also supports what happens after the code is written.

GitHub Packages can host different types of packages.

Releases organize distributed versions of a project with notes and associated files.

GitHub Pages can publish a static website directly from a repository.

These features do not replace every specialized distribution or hosting platform.

But they reinforce an idea that runs throughout GitHub:

keep as much of the software lifecycle as possible around the same project.

Copilot: AI enters the repository

GitHub Copilot has gradually moved beyond simple autocomplete.

The Copilot ecosystem now includes conversations, code suggestions, agent mode, code review, and agents capable of receiving certain tasks linked to issues or pull requests.

Agents can notably be launched from different GitHub surfaces and work around a repository before proposing their changes through a pull request.

Copilot nevertheless remains a separate product, with its own plans, quotas, and billing mechanisms.

That distinction matters.

GitHub can be used perfectly well without Copilot.

But AI is now integrated deeply enough into the platform to change how its workflows can be imagined.

The repository no longer hosts only humans and deterministic automations.

It is starting to host agents too.

Use cases

Publishing a first project without building infrastructure

You have just finished a small application.

It works.

Well, on your machine.

That is already an excellent start.

Creating a GitHub repository lets you preserve the project history, publish the code if you want, write a README, and immediately gain a space for issues, releases, and contributions.

For a personal or student project, the free plan is already more than enough to get started.

And most importantly, the project gets an address.

Something you can show, clone, follow, and evolve.

Collaborating without sending files named final_v7_really_final

Two developers are working on the same feature.

Each creates a branch.

The changes arrive through a pull request.

The differences are visible.

Comments remain attached to the relevant lines.

Tests run automatically.

Once everything is approved, the change joins the main branch.

No ZIP file sent over Discord.

Human progress is sometimes made of small victories.

Building and testing an application on multiple systems

An application needs to work on Linux and Windows.

Yet the developer only has one machine in front of them.

GitHub Actions can run different jobs on several runners, install dependencies, launch tests, and produce artifacts.

The same mechanism can then generate a release or automate part of the deployment process.

For a cross-platform project, GitHub then becomes something more than a code host.

It actively participates in the production pipeline.

Maintaining an open-source project

A public project receives a feature suggestion.

Someone opens an issue.

Another person proposes a pull request.

A discussion begins.

A maintainer requests a correction.

The automated tests fail.

The contributor fixes the problem.

The PR turns green.

Merge.

This workflow feels so normal today that it is easy to forget how much it has shaped modern open-source development culture.

GitHub does not merely host the result.

It hosts a large part of the conversation that makes the result possible.

Managing development for a team

As a project grows, the question is no longer simply “where do we store the code?”

It becomes:

Who can modify this branch?

Who must approve this pull request?

Which tests are mandatory?

Which secrets can the pipeline use?

Who owns this part of the code?

Which dependencies contain vulnerabilities?

Which repositories belong to which team?

Team and Enterprise plans progressively add controls designed to answer these kinds of questions.

GitHub then moves from shared repository to development governance infrastructure.

PANACHES review

GitHub has a strange flaw: it has become so ordinary that we barely notice everything it contains anymore.

People often say:

“The project is on GitHub.”

As if that simply meant a folder is waiting somewhere on the Internet.

In reality, GitHub can cover a considerable part of the development lifecycle: versioning, discussion, planning, review, testing, security, building, publishing, distribution, and now delegation of certain tasks to AI.

Its real strength: context stays attached to the code

There are excellent specialized tools for almost every GitHub feature.

More specialized CI systems.

More powerful project managers.

Deeper security scanners.

Different cloud environments.

Competing AI assistants.

Taken individually, GitHub is not necessarily the absolute best tool in every one of these categories.

But that is not really its game.

Its strength comes from the continuity between them.

The issue knows the pull request.

The pull request knows the commit.

The commit triggers the Action.

The Action produces the result.

Security analyzes the same repository.

The package comes from that project.

The release carries that version.

Context keeps flowing.

And in software development, losing context often costs far more than we think.

GitHub is also a place

There is something else.

GitHub is not only a toolbox.

It is a place where a huge part of the public software ecosystem is visible.

You find libraries there.

Frameworks.

AI models.

Applications.

Game engines.

Extensions.

Tiny projects.

Infrastructure used by millions of people.

You can watch how software evolves, read its issues, observe technical decisions, follow its releases, or discover a tool simply by tracing it back to its repository.

For a developer, knowing how to navigate GitHub is almost part of the profession’s general culture.

The downside of integration

But that richness has an opposite side.

The more a project uses GitHub for repositories, issues, Actions, Packages, Pages, Codespaces, security, Copilot, and team management, the less migration means simply changing the URL of a Git remote.

You have to move part of the working system.

It is the classic paradox of integrated platforms.

They are pleasant precisely because all the pieces communicate so well.

And that communication is also what makes leaving more expensive.

When should you prefer something else?

GitLab is the most obvious alternative when looking for an integrated DevOps platform with strong self-hosting capabilities.

Gitea, Forgejo, or Codeberg become particularly interesting for people who prioritize open source, lightweight infrastructure, independence, or control over hosting.

Bitbucket can remain relevant in an environment strongly tied to the Atlassian ecosystem.

The choice therefore depends less on the question:

“Which service can host Git?”

Almost all of them can.

The real question is:

What kind of environment do you want to build around your repositories?

And on that ground, GitHub remains extremely difficult to ignore.

Points to consider

GitHub is not open source just because Git is

This is probably the most important confusion to eliminate.

Git is free and open source. GitHub is not.

The GitHub platform is a proprietary service operated by GitHub, Inc.

Some parts of the broader GitHub ecosystem have their own open-source code, and GitHub obviously hosts a gigantic amount of free and open-source software.

That does not make the service itself open source.

Its terms of service state that GitHub and its suppliers retain the intellectual property rights associated with the site and service.

Free does not mean everything is unlimited

The Free plan notably allows unlimited public and private repositories.

But several surrounding services operate with quotas.

For a GitHub Free personal account, GitHub includes 2,000 Actions minutes per month, along with a monthly Codespaces allowance.

GitHub Pro and organization plans increase some of these limits.

Standard Actions runners are free for public repositories, but private repository usage or specific resources can become billable once included quotas are exceeded.

The same logic applies to Codespaces.

The repository can be free.

The machine compiling the repository will not necessarily keep working for free forever.

Copilot has its own economy

GitHub Copilot should not be confused with the price of a GitHub account.

GitHub offers several distinct Copilot plans for individuals and organizations.

In 2026, their usage also relies on a system of GitHub AI Credits, with allocations depending on the plan and possible billing for additional usage.

For someone who makes heavy use of agents or premium models, that consumption becomes part of the real cost of the platform.

In other words:

GitHub Free can remain free while the services built around the repository start generating a bill.

GitHub.com and self-hosting are not the same offer

GitHub Enterprise exists in different forms.

GitHub Enterprise Cloud remains hosted by GitHub.

GitHub Enterprise Server allows GitHub to be deployed on infrastructure controlled by the company.

That does not mean the standard version of GitHub.com can simply be downloaded and installed for free on your own server.

Self-hosting belongs to the Enterprise offer.

For an individual or small project primarily looking for a free and open-source self-hosted forge, Gitea, Forgejo, or GitLab may feel more natural.

Actions workflows deserve the same attention as code

GitHub Actions is extremely convenient.

And precisely because of that, it becomes very easy to automate a lot of things.

A workflow can access code, run commands, manipulate artifacts, use tokens, and sometimes hold secrets that allow it to communicate with external services.

The permissions, secrets, and third-party Actions used in a pipeline should therefore be treated as sensitive parts of the project.

Automatic does not mean harmless.

It simply means the mistake can run by itself.

Making a repository private does not remove every trust question

A private repository restricts access to authorized people and systems.

It is still hosted by an external provider in the case of GitHub.com.

The service terms describe how GitHub processes this content and provide for certain access scenarios, notably to provide the service, comply with legal obligations, perform automated processing, or respond to security risks.

For most projects, this can be a perfectly acceptable compromise.

For certain regulated, sovereign, or highly sensitive environments, data location and infrastructure control can become decisive criteria.

Centralization simplifies daily work and sometimes complicates leaving

Git is distributed.

A local clone preserves the code history.

That is excellent protection against complete lock-in.

But the rest of GitHub is not contained in a simple git clone.

Issues.

Pull requests.

Discussions.

Projects.

Actions.

Secrets.

Packages.

Rules.

Permissions.

Security configuration.

The more of these layers you use, the more migration requires moving the project around the code, not merely the code itself.

That is not a reason to avoid GitHub.

It is a reason to understand what you choose to build there.

Your Git repository can travel easily. Your complete workflow, much less so.