Version Control, Git, and GitHub

Git and GitHub are connected, but they solve different problems.

Git is a version control system that runs on your computer. It tracks changes to files, preserves multiple versions of a project, and records a history of saved changes. This history allows you to return to an earlier state instead of permanently overwriting previous work.

GitHub is a remote hosting platform for Git repositories. It provides a central online location where multiple people can upload, view, compare, and combine their work. Git can operate without GitHub, but GitHub makes remote access, backup, sharing, and team collaboration possible.

Git observes the files inside a repository and records selected states of those files as commits. Each commit represents a saved point in the project's history. Over time, the repository becomes a sequence of versions rather than a single set of files that is continually overwritten.

This matters because project requirements change. A client may approve one version, request a later modification, and then decide that the earlier version was better. Without version history, recovering the previous state may require manually reconstructing it. With Git, the earlier committed state remains available.

Git can be used with many kinds of files, not only source code. The central idea is the same in every case: Git preserves change history so that a project can move forward without erasing its past.

GitHub adds a remote layer. Each contributor can work in a local repository on a separate computer, then send committed work to a shared repository online. The remote repository becomes the common point through which the team exchanges changes.

Other platforms can host Git repositories, including GitLab and Bitbucket. The workflow described here focuses on GitHub, but the local Git concepts remain separate from the hosting platform.

Version control addresses two different risks:

1. History risk: A useful earlier version may be lost when files are overwritten.
2. Collaboration risk: Multiple people may create different versions of the same project on separate computers.

Git reduces history risk by preserving commits. GitHub reduces collaboration risk by giving the team a shared remote repository.

The distinction also prevents a common conceptual error. A local commit does not automatically appear on GitHub. Committing saves work to the local repository. Pushing sends those commits to a remote repository. These are separate actions in separate locations.

Consider a project maintained by two developers.

Developer A changes files on one computer. Developer B changes files on another. Git tracks each developer's local history independently. When their work is ready to share, each developer pushes the relevant commits to GitHub. GitHub then provides the shared location where branches can be compared, reviewed, and merged.

A single developer also benefits from the same separation. Local Git provides version history even without an internet connection or remote repository. GitHub becomes useful when the developer wants an online copy, access from another computer, or a place to share the project.

A useful operating model is:

Local Git answers: "What versions have I saved on this computer?"

GitHub answers: "What versions and branches are available to the wider team online?"

A local repository alone provides local history, but it does not provide remote access or a shared collaboration point.

A GitHub repository provides a remote location, but it does not replace the local Git workflow. Files still need to be changed, staged, and committed locally before those commits can be pushed.

A remote repository also does not automatically contain every local branch. A branch appears remotely only after it is pushed.

Git manages version history locally. GitHub hosts Git repositories remotely so that work can be backed up, accessed from other machines, reviewed, and shared across a team.