GitHub is a cloud-based platform for hosting Git repositories that adds collaboration, review and automation features on top of the Git version control system. Among development tools in programming, it serves as the central place where teams store code, review changes, track work and run automated pipelines.
Launched in 2008 and acquired by Microsoft in 2018, GitHub popularized the pull request workflow and became the default home of a large share of open-source software. It is important to separate the two layers: Git is the version control tool that runs locally, while GitHub is a service built around it.
How GitHub works with Git
Every GitHub repository is a bare Git repository on a server plus metadata stored by the platform, such as issues, pull requests, comments and permissions. Developers clone it, commit locally, and push their branches back over HTTPS or SSH; other developers fetch or pull those changes.
The Git history itself is portable and can be moved to any other host, but the collaboration data lives in GitHub. Teams that plan for migration or backup therefore export issues and pull request discussions separately, because a plain clone does not contain them.
The following table distinguishes what belongs to Git and what GitHub adds.
| Capability | Provided by | Notes |
|---|---|---|
| Commits, branches, merges | Git | Work fully offline |
| Remote hosting and access control | GitHub | Organizations, teams, roles |
| Pull requests and code review | GitHub | Discussion attached to a branch |
| Issues and project boards | GitHub | Planning linked to code |
| CI/CD automation | GitHub | GitHub Actions workflows |
| Merge conflict resolution | Git, with GitHub web editor for simple cases | Complex conflicts are resolved locally |
Core features of GitHub
GitHub has grown from a code host into a complete software delivery platform. The table below summarizes the main feature areas and what each is used for.
| Feature | Purpose | Typical use |
|---|---|---|
| Pull requests | Propose, discuss and merge changes | Peer review before merging into main |
| GitHub Actions | Run workflows on events | Tests, builds, deployments |
| Issues and Projects | Track bugs and tasks | Backlogs, sprint boards, roadmaps |
| Branch protection and rulesets | Enforce merge rules | Required reviews and passing checks |
| Security features | Find vulnerable code and dependencies | Dependabot alerts, secret scanning, code scanning |
| Packages and releases | Publish artifacts | Container images, library versions |
| Codespaces | Cloud development environments | Preconfigured environments for contributors |
GitHub Actions deserves special attention. Workflows are YAML files stored in .github/workflows, triggered by events such as a push or a new pull request, and executed on hosted or self-hosted runners. Because the configuration lives in the repository, the pipeline is versioned and reviewed like the code itself.
The pull request workflow on GitHub
The typical GitHub workflow, often called GitHub flow, keeps the main branch always deployable. A developer creates a short-lived feature branch, pushes commits, opens a pull request, receives review and automated checks, and merges once everything passes.
- Create a branch from main for one focused change.
- Commit and push the work, keeping each change small enough to review in under an hour.
- Open a pull request that describes the intent and links the related issue.
- Let required status checks such as tests and linters run automatically.
- Address reviewer comments and resolve any merge conflict with main.
- Merge using a merge commit, squash or rebase, according to team policy, and delete the branch.
In open-source projects, external contributors usually work in a fork, a personal copy of the repository, and open pull requests from the fork back to the original. Maintainers keep control because only they can merge into the upstream repository.
GitHub compared with similar platforms
GitHub competes with other Git hosting services that offer broadly similar core features but differ in hosting model, built-in tooling and ecosystem. The comparison below covers the most common alternatives.
| Platform | Hosting options | Distinctive strength |
|---|---|---|
| GitHub | Cloud, Enterprise Server self-hosted | Largest open-source community, Actions marketplace |
| GitLab | Cloud, self-managed open-core | Integrated DevOps lifecycle in one product |
| Bitbucket | Cloud, Data Center | Tight integration with Jira |
| Azure Repos | Cloud as part of Azure DevOps | Fits Microsoft enterprise toolchains |
| Gitea or Forgejo | Self-hosted, lightweight | Low resource needs, full control |
Because all of them use Git, switching hosts preserves the code history. The real switching cost lies in workflows, CI definitions, integrations and the collaboration history stored on the platform.
Good practices and common mistakes
Most GitHub problems are configuration and process problems, not tool limitations. The table pairs frequent mistakes with their consequences and fixes.
| Mistake | Consequence | Fix |
|---|---|---|
| Committing secrets | Leaked API keys, even after deletion from history | Secret scanning, push protection, immediate key rotation |
| Unprotected main branch | Untested code reaches production | Branch protection with required reviews and checks |
| Huge pull requests | Superficial reviews and long delays | Smaller, focused changes |
| Overly broad tokens | Large blast radius if a token leaks | Fine-grained tokens with minimal scopes |
| Unpinned third-party actions | Supply chain risk in CI | Pin actions to a full commit SHA |
A further point is access hygiene: enforcing two-factor authentication, using teams rather than individual permissions, and reviewing outside collaborators regularly keep an organization manageable as it grows.
The idea in brief
GitHub is a shared online home for a software project. The code lives there, along with its complete history, so everyone on the team works from the same version and can see who changed what and when.
It is also a meeting room. Before a change is accepted, teammates read it, comment on it and approve it, and automatic checks test it. Think of it as a shared document with tracked changes, built specifically for program code.
A practical scenario
A team of eight developers maintains an online booking service. Their GitHub repository protects the main branch: every change needs one approving review and a passing GitHub Actions run that executes about 1,200 tests and a linter in roughly eight minutes.
A developer fixes a date-handling bug on a branch and opens a pull request linked to the issue reported by customer support. A reviewer spots a missing time-zone case, the developer adds a test, the checks turn green and the change is merged. A deployment workflow then releases it automatically. The fix reaches users the same afternoon, and the issue, review discussion and deployment remain linked for anyone investigating the change later.