Common GitHub Terms
You may encounter the following terms while using GitHub. These explanations are intentionally non-technical.
Repository (often called a “repo”)
A repository is a shared folder that holds files and documents.
Think of it as:
A shared drive
With built-in version history
And a record of changes over time
This repository is one example of a repository.
README
A README is a front-page document that explains:
What the repository is for
How to use it
Who it is intended to serve
If you only read one file in a repository, it is usually the README.
Commit
A commit is a saved change.
Each commit records:
What changed
When it changed
Who made the change
(Often) why the change was made
Commits create an audit trail. They do not change anything automatically or immediately outside of GitHub.
History
History is the full record of changes made to a file or repository over time.
You can:
See previous versions
See who made changes
Compare versions side by side
Nothing is ever “silently overwritten.”
Issue
An issue is a structured conversation.
Issues are often used to:
Ask questions
Flag problems
Propose improvements
Track work or decisions
Creating or commenting on an issue does not change files.
Pull Request (PR)
A pull request is a request to make a change.
It allows others to:
Review proposed changes
Ask questions
Approve or reject updates
In government terms, a pull request functions like a review gate.
Nothing is changed unless it is explicitly approved.
Fork
A fork is a personal copy of a repository.
Forks allow someone to:
Experiment
Draft changes
Explore content without affecting the original repository.
Forking is reversible and non-destructive.
Clone
A clone is a downloaded copy of a repository.
Cloning does not grant permission to make changes. It simply creates a local reference copy.
Public vs. Private
Public repositories can be read by anyone
Private repositories restrict access
Reading public repositories does not notify the owner and does not create risk.
Permissions
Not everyone can make changes.
Typical permission levels include:
Read (view only)
Comment
Propose changes
Approve changes
Permissions are explicit and controlled.
What you cannot do by accident
It is not possible to accidentally:
Change production systems
Deploy software
Modify files without review
Hide changes from history
GitHub requires intentional, logged actions.
If you ever feel uncertain, it is appropriate to pause, read, or ask questions before engaging further.