What Is GitHub? Repositories, Collaboration, and Visibility

Git and GitHub are closely related, but they are not the same product.

Git is the distributed version control system that tracks commits and branches. It works locally on your computer and does not require GitHub.

GitHub is a hosted developer platform built around Git repositories. It gives a team an online place to exchange Git history and adds collaboration, review, automation, security, and project-management features.

Git    → version control engine
GitHub → hosting and collaboration platform built around Git repositories

Local repository versus GitHub repository

When we run Git commands inside a project, Git stores the repository and its history locally:

Developer's computer
└── payment-api/
    ├── src/
    ├── tests/
    └── .git/     ← local objects, branches, and history

Commands such as these operate locally:

git status
git add .
git commit -m "feat: add payment endpoint"
git log --oneline

Nothing leaves the computer merely because a commit was created.

A GitHub repository is a hosted copy and collaboration point reachable over a network:

Local repository                     GitHub repository
Laptop A  ─────── push ────────────> origin
Laptop A  <──── fetch / pull ─────── origin
Laptop B  <────── clone ──────────── origin

The GitHub copy does not continuously read or update the local .git directory. Data moves only when someone or some tool performs a network operation such as push, fetch, pull, or clone.

What GitHub adds around Git

Git already provides commits, branches, merging, and distributed history. GitHub adds a shared service around that foundation:

Hosting Git repositories online.
Accounts, organizations, teams, roles, and permissions.
Pull requests for proposing and reviewing changes.
Issues and Projects for tracking work.
GitHub Actions for automated build, test, and deployment workflows.
Release pages and package hosting.
Security features such as dependency alerts and secret scanning, depending on repository settings and the account plan.
A web interface for browsing code, commits, branches, and discussions.

Some features are GitHub-specific. For example, Git itself does not contain the concept of a Pull Request or a GitHub Issue.

Why teams use GitHub

1. Collaboration without copying folders

Several developers can clone the same hosted repository, create independent branches, push them, and review changes before integration.

Mona  → feature/orders  ─┐
                         ├─ Pull Requests → review → main
Omar  → fix/payment     ─┘

The team exchanges commits instead of emailing ZIP files such as project-final-v7-really-final.zip.

2. Code review through Pull Requests

A Pull Request presents a proposed branch change for discussion. Reviewers can:

Inspect the exact diff.
Ask questions and leave comments.
Request changes.
Check automated build and test results.
Approve and merge when the change is ready.

A Pull Request is a collaboration workflow supplied by GitHub. The commits and branches inside it are still Git concepts.

3. Open-source participation

Public repositories can let anyone read the project, learn from it, report an issue, or propose a contribution. The owner still controls who can directly push and which proposed changes are accepted.

Public visibility is not the same as public write access.

4. A professional portfolio

A public profile can show real projects, documentation, tests, and meaningful contributions that an employer or collaborator can inspect.

However, the number of green contribution squares is not a reliable measure of engineering skill. A smaller repository with clear architecture, useful commits, tests, and a strong README usually communicates more than artificial activity.

5. Coordination across computers and environments

A developer can push completed commits from one computer and clone or pull the repository on another authorized computer.

This does not turn GitHub into automatic live file synchronization:

Uncommitted changes are not uploaded.
Ignored files are not uploaded through normal Git tracking.
Local configuration and secrets should normally remain local.
Someone must push new commits before another machine can receive them.

For a team, the agreed GitHub repository commonly acts as the central coordination point, even though every Git clone still contains its own local history.

Repository does not mean folder only

A GitHub repository can contain:

The project’s tracked files.
Commit and branch history received from Git.
Tags and releases.
Pull requests, issues, discussions, and project metadata stored by GitHub.
Collaborator and automation settings.

Deleting a local project folder does not automatically delete the GitHub repository. Deleting or changing the GitHub repository does not silently edit every existing clone either.

Public repositories

A public repository is readable by anyone on the internet.

Public is appropriate for examples such as:

An open-source library.
A finished portfolio project.
Public documentation or sample code.
A project where public contribution is intentional.

Public visibility means people can view and usually fork the repository. It does not mean every visitor can push into the original repository. Write access still depends on permissions, and project owners decide whether to accept proposed Pull Requests.

Private repositories

A private repository is visible only to authorized users, subject to the account or organization’s access rules.

Private is appropriate for examples such as:

Unfinished coursework or personal drafts.
A commercial client project.
Internal company source code.
A backend system that is not intended to be open source.

Private does not mean “safe to commit secrets.” Collaborators, compromised accounts, automation logs, accidental visibility changes, or copied clones can still expose data.

Never commit values such as:

Production database passwords
API keys and access tokens
Private certificates
.env files containing real credentials
Cloud service secrets

Use .gitignore, environment variables, a secret manager, and least-privilege access. If a real credential enters Git history, revoke or rotate it; merely deleting the line in the latest commit is not enough.

Public versus private

Question	Public repository	Private repository
Who can view it?	Anyone on the internet	Authorized users only
Can every viewer push?	No	No; write permission is still required
Can it be cloned?	Yes, by anyone	Yes, by authorized users
Suitable for open source?	Yes	Not while private
Safe place for secrets?	No	Also no
Good default for unfinished sensitive work?	No	Usually, with proper access controls

Organizations using GitHub Enterprise Cloud may also have internal visibility, which is available to enterprise members under enterprise access rules. It is not the same as a public or ordinary private repository.

Choosing visibility

Choose Public when:

Everyone is intentionally allowed to read the code and history.
The repository is ready to represent you or the project publicly.
The license and contribution expectations are clear.
The complete history has been checked for sensitive information.

Choose Private when:

The work is unfinished or confidential.
A client or employer owns the source.
The repository contains coursework that should not be shared publicly.
Only selected collaborators should be able to read it.

Visibility can be changed later by someone with sufficient permissions, but that change has consequences. Making a repository public exposes its code and history; changing it to private does not recall copies that people already cloned. GitHub also documents effects on forks, stars, watchers, security features, and Actions visibility, so review the current repository visibility documentation before changing a real project.

GitHub plans, briefly

At the time this lesson was reviewed, GitHub Free supported unlimited public and private repositories for personal accounts and organizations, with feature limits that differ from paid plans. Paid plans add or expand organization, policy, support, security, automation, and enterprise capabilities.

Exact plan names, prices, included usage, and features can change. Do not rely on a screenshot or a memorized number when making a purchasing decision. Check the current official GitHub plans documentation and GitHub pricing page.

For learning Git, hosting portfolio projects, and ordinary personal practice, the Free plan is normally enough. Some products and usage—such as additional automation, storage, Codespaces, Copilot, or advanced security features—may have separate limits or charges.

GitHub is not a complete backup strategy

Pushing to GitHub gives the project another copy and protects against some local failures, but a remote Git repository should not be the only backup plan for critical systems.

Reasons include:

Accidental repository deletion or account loss.
Credentials or permissions being compromised.
Large files, databases, build artifacts, and ignored files not being stored in ordinary Git history.
Force pushes or administrative operations changing remote references.

Important production data needs an independent, tested backup and recovery strategy.

Correct mental model

Local Git repository
├── Works without GitHub
├── Contains local commits and branches
└── Sends/receives history only when commanded

GitHub repository
├── Hosts a reachable copy of Git history
├── Controls online visibility and access
├── Coordinates collaboration and review
└── Adds GitHub-specific services around Git

GitHub is a useful meeting point, not the engine that creates every local Git operation.

Common mistakes

Saying “Git” and “GitHub” as if they were interchangeable.
Assuming git commit uploads code automatically.
Believing public visibility lets everyone push to the original repository.
Treating a private repository as permission to commit credentials.
Assuming ignored or uncommitted files are available on another computer.
Using GitHub as the only backup for critical business data.
Making a private repository public without reviewing its full history.
Choosing a paid plan from an old screenshot instead of current official plan information.

Summary

Git tracks versions locally; GitHub hosts repositories and adds collaboration services.
A commit remains local until a deliberate network operation sends it.
Teams use GitHub for shared repositories, Pull Requests, reviews, issues, automation, and controlled access.
Public controls who can read; permissions separately control who can write.
Private limits visibility but is never a safe storage mechanism for secrets.
GitHub Free currently supports ordinary learning and personal repository hosting, while exact plan details should always be checked officially.

Knowledge check

Can Git create commits when the computer is offline and has no GitHub account?
Does git commit send the new commit to GitHub?
What does GitHub add that is not part of core Git?
Can any visitor push directly to a public repository?
Why must secrets stay out of private repositories too?
What should you inspect before changing a private repository to public?