What it is
GitHub is a hosted service for Git repositories, owned by Microsoft. A repository on GitHub is a remote your local Git can push to and fetch from. Around that remote, GitHub adds pull requests (a branch proposed for review), issues, code review comments, permissions, and GitHub Actions for automation. Those extras are not part of Git. GitLab, Bitbucket and a bare server you run yourself can host the same Git objects with different buttons.
When someone says "commit it to GitHub", they mean commit with Git and push to a GitHub remote. The commit happens locally first.
Why and when it is used
Use GitHub when your team already does, when you want hosted review and CI, or when you depend on open-source projects that live there. Pull requests are the usual gate before merging to the default branch. Actions run tests on those requests if you configure them (CI and CD).
You do not need GitHub to use Git. A single player can commit locally forever. You do need some remote if two computers must share history and you do not want to pass patches by hand. Choose the host your organisation trusts with the source code. Private repositories are still source code on someone else's computers; read the agreement if the code is sensitive.
How it works
You authenticate with SSH keys or a personal access token (or the gh CLI's login). HTTPS passwords for Git operations were removed; a token is not your GitHub password pasted into a URL. A pull request compares a branch to a base branch and shows the diff. Reviews can be required by branch protection: no merge until checks pass and a person approves. Actions workflows are YAML files in .github/workflows. They run on GitHub's runners or yours, with permissions you should narrow.
Issues and pull requests are not a project plan by themselves. They are a log of decisions if you write them that way. The default branch (often main) is what clones check out. Protect it.
Technologies and dependencies
A GitHub account, a repository with a clear owner, and Git locally. The gh CLI is optional and useful. Actions minutes and storage have limits. Secrets for CI live in the repository or organisation settings, not in the YAML. Packages can be published to GitHub's registry; that is separate from source hosting. Environment Variables on your laptop are still yours; Actions secrets are the CI equivalent.
How to get started
- Create an empty private repository. Do not initialise it with a README if you already have a local repo you plan to push, or you will merge two unrelated histories.
- Add the remote and push your default branch.
- Branch, commit, push, and open a pull request. Merge it with the button only after you have seen the diff.
- Add a workflow that runs your tests on pull requests. Start with one command.
- Turn on branch protection for the default branch once the check is real.
- Invite a second person with the least access they need, not admin out of habit.
If a token appears in a remote URL in an error message, revoke it and create a new one. URLs get copied into tickets.
Cautions and trade-offs
A public repository is public, including issues and commit history. Do not "temporarily" push secrets. Forks of public repos can receive pull requests that try to run malicious CI; do not expose secrets to workflows from forks.
Admin access is not a courtesy. It can delete the repository and change protections. Actions workflows can be a supply-chain risk if they run third-party actions you have not pinned to a commit SHA. Pin them when the pipeline matters. And GitHub being down does not delete your local clones. It does stop hosted CI and new clones. Keep the source of truth recoverable, and do not treat a single hosted issue tracker as the only record of why a change was made.