Git, GitHub, and the Rest of the Toolchain
Git and GitHub are connected, but they are not interchangeable. Git records and moves history. GitHub hosts repositories and adds collaboration services around that history. Knowing the boundary lets you work offline, choose alternatives, and debug the layer that actually failed.
One workflow, several owners
Git is the version-control engine
Git is software that manages a repository. It can initialize history, record commits, create names for graph positions, compare states, and integrate lines of work. Those operations do not require GitHub. A repository on an unplugged laptop is still a Git repository.
Your working files are not “inside GitHub” while you edit them. They live in the filesystem. Git observes selected paths and records states when you explicitly ask it to. Later, Git can exchange recorded objects with another repository.
LOCAL — works without GitHub
working files · commits · branches · history · diffs
HOSTED — provided by GitHub
pull requests · issues · Actions · permissions · web UI
BRIDGE
a remote URL plus fetch/push operationsGitHub is a hosting and collaboration service
GitHub stores Git repositories on its infrastructure and exposes them through the web, APIs, and network protocols. Around those repositories it provides identities, permissions, pull requests, issues, project planning, releases, security features, and Actions automation.
Repository history
- Commits and parent relationships
- Branches and tags as references
- Local differences and history inspection
- Merge and rebase operations
- Remote configuration and data exchange commands
Hosted collaboration
- Pull request conversations and approvals
- Issues, labels, milestones, and projects
- Repository permissions and protection rules
- Actions workflows and status checks
- Release pages, web UI, and organization policy
A pull request can discuss a group of Git commits, but it is not stored inside those commits. Clone the repository elsewhere and the commits travel; GitHub review comments do not become commit objects. They remain service data linked to the hosted repository.
Test what you learned
Which tool provides pull request discussions: Git or GitHub?
The rest of the toolchain still matters
Your editor and filesystem
│ save files
▼
Local Git repository
│ exchange commits through a remote
▼
GitHub repository
│ review, discuss, automate, release
▼
Collaborators and deployed systemsEditor and filesystem
Create and save working files. If text never reached disk, Git cannot record the intended bytes.
Local Git repository
Stores selected history and names. A clean or dirty working tree is local repository state.
Transport and credentials
HTTPS or SSH moves objects between repositories. Authentication failure is not a broken commit graph.
GitHub service
Applies hosted permissions, branch rules, checks, and review policy after the network reaches it.
There may be more layers: a package manager restores dependencies, a CI runner executes tests, and a deployment platform serves the application. Keeping their responsibilities separate prevents ritual fixes such as reinstalling Git because a unit test failed.
A remote bridges repositories
In Git, a remote is a named configuration for another repository location. The conventional name origin is not a special cloud or master copy; it is simply the default name many clone operations assign to the source location.
A remote may point to GitHub, GitLab, Codeberg, a company server, or another reachable Git repository. GitHub is common, not mandatory. The same local repository model works with several hosts and can even have more than one remote for different coordination needs.
Know the offline and online boundary
- 01Works locally
Edit files, record commits, create branches, compare snapshots, and inspect already-present history.
- 02Needs a connection
Receive commits not yet in the clone, publish local commits, or contact a hosted API.
- 03Needs GitHub
Open a pull request, assign an issue, change hosted permissions, or run a GitHub-hosted workflow.
- 04Needs human agreement
Approve a design, choose conflict intent, or decide whether passing checks are sufficient to merge.
The boundary is also a recovery tool. If GitHub is unavailable, local commits remain available. If a laptop is lost, GitHub may hold published history but not uncommitted files or commits that were never pushed. Neither side replaces a deliberate backup strategy.
Diagnose by layer, not by product name
“My change disappeared.”
First inspect the editor and filesystem. Was the file saved, and are you opening the expected path?
“My commit is missing.”
Inspect local Git history and the current graph position. Do not begin with GitHub settings.
“Push was denied.”
Read the transport response: URL, authentication, destination, permissions, or branch policy may own the failure.
“The check is red.”
Open the GitHub Actions job or external check logs. A successful push does not imply successful tests.
Good diagnosis names the last boundary that succeeded. If the commit is visible locally, file saving and commit creation already worked. If GitHub received the commit but rejected a protected-branch update, transport and authentication probably worked too; hosted policy is now the relevant layer.
Test what you learned
A commit exists locally but not on the hosting site. What one-word Git concept names the configured destination to inspect?
Worked example: “GitHub lost my work”
A developer records commit C while offline. The GitHub page still ends at B. Nothing is lost: local history contains C, while the hosted repository has not received it. After the connection returns, the developer attempts to publish C and receives a permission error.
FILESThe edited file was savedFilesystem evidence confirms the intended content exists.
GITLocal history contains CThe commit and its parent B prove local recording succeeded.
REMOTEGitHub still ends at BThe histories differ because exchange has not completed.
POLICYGitHub rejects the updateThe response points to permissions or branch protection—not a missing local commit.
The correct next move is to follow the repository’s contribution policy, perhaps publishing a feature branch and opening a pull request. Recreating C, reinstalling Git, or editing the file again would attack layers that already succeeded.
Git is portable across hosting services
GitHub is not Git’s only home. GitLab, Bitbucket, Codeberg, self-hosted forges, and bare repositories can exchange Git history. Their collaboration features and policy syntax differ, but commits and core graph concepts remain portable.
Portability is not perfect: issues, pull request comments, Actions workflows, secrets, and protection settings are platform-specific service data. Moving the Git repository transfers history; migrating the surrounding collaboration system is a separate project.
Independent lab: classify the owner
For each scenario, write one owner—filesystem, local Git, transport/credentials, GitHub, or human decision—and one piece of evidence you would inspect:
- The editor tab changed, but the file on disk did not.
- A new commit appears in local history but not on the website.
- The server says the SSH key is not authorized.
- A pull request exists, but a required check is failing.
- Two implementations both pass tests, but the team disagrees about behavior.
Common boundary mistakes
“I committed, so it is on GitHub.”
Commit records locally. Publishing requires a successful remote exchange.
“GitHub is required for Git.”
Git repositories work locally and can use many different hosts.
“A pull request is a Git object.”
It is hosted review state linked to Git commits and branches.
“Push rejected means Git is broken.”
The cause may be credentials, permissions, destination choice, or hosted policy.
Lesson review
Git is the distributed version-control engine. GitHub is one hosting and collaboration service built around Git repositories. A remote bridges repositories; it does not make every local action public. Editors, filesystems, credentials, network transport, hosted policy, automation, and human decisions each own different parts of the workflow.
- I can identify which common tasks belong to Git and which belong to GitHub.
- I can explain why commits and local history still work offline.
- I can define a remote without treating
originas a magical cloud. - I can distinguish a transport failure from a hosted policy rejection.
- I know which collaboration data will not travel merely by copying Git history.