Glossary
A glossary of Git terms and concepts.
B
- Branch
-
Aliases: feature branch, topic branch
An independent line of development that diverges from the main codebase.
A branch is an independent line of development. Branches allow you to:
- Work on features without affecting the main codebase
- Experiment with new ideas safely
- Collaborate with others on specific tasks
The default branch is usually called
mainormaster.
C
- Clone
-
Aliases: local repository
A local copy of a remote repository hosted on your computer.
A clone is a full copy of a repository that lives on your local machine. When you clone:
- Git downloads the entire project folder to your computer
- The complete version history and all branches are copied locally
- You can check all the available branches by typing
git branch -ainside the local repository - You can work offline, make commits, and test changes safely
Cloning is typically the very first step you take when you want to start working on an existing GitHub project locally.
- Commit
-
Aliases: revision, changeset
A snapshot of your project's files at a specific point in time.
A commit is a snapshot of your project at a specific point in time. Each commit has:
- A unique identifier (SHA hash)
- A commit message describing the changes
- Author and timestamp information
- References to parent commits
Commits form the history of your repository.
F
- Fetch
-
Downloading the latest changes and history from GitHub without merging them.
A fetch tells your local Git environment to look at GitHub to see if your team has saved any new work. When you fetch:
- Git downloads the latest history and hidden branches to your computer
- Your current working files and active code are not modified or changed
- You can safely inspect what others have done before deciding to mix it into your code
Fetching is used to check for updates without changing local files. This is ran automatically when performing a pull command.
- Fork
-
A personal copy of another user's repository created on your GitHub account.
A fork is a personal copy of someone else’s project that lives entirely on GitHub’s servers under your own account. When you fork:
- Git duplicates the original project repository over to your GitHub dashboard
- You gain full permission to experiment, fix bugs, or add features in your copy
- The original project remains completely safe and unaffected by your changes
Forking is the standard first step in open-source development when you want to propose changes to a project using a pull-request.
I
- Issue
-
Aliases: ticket
A GitHub tracking item used to discuss bugs, feature requests, or project tasks.
An issue is an online discussion thread built directly into GitHub to help teams track tasks and report problems. When you create an issue:
- Anyone on your team can log a bug report, suggest a new feature, or ask a question
- You can assign specific team members to work on it and add colorful tracking labels
- You can link it directly to a pull-request so it automatically closes when the fix is completed
Issues act as the central to-do list for a project, keeping conversations about code organized in one clear place.
For big tasks, you can add checkboxes inside your description to create sub-issues or task lists. This breaks a massive goal down into a small, trackable checklist where tracking progress happens automatically as you check items off.
Related: pull-request
M
- Merge
-
The process of combining changes from one branch into another.
A merge combines the changes from one branch into another. When you merge:
- Git integrates the commit history from both branches
- Changes are combined automatically when possible
- Conflicts may occur if the same lines were modified differently
Merging is a fundamental part of collaborative workflows.
P
- Pull
-
Fetching the latest changes from GitHub and immediately merging them into your local branch.
A pull is a shortcut command that grabs the latest updates from GitHub and instantly mixes them into your local files. When you pull:
- Git automatically runs a fetch to download the newest changes in the background
- It immediately runs a merge to combine those changes into your active workspace
- Your local project files are instantly updated to match what is on GitHub
Pulling regularly is the best way to make sure you are always working on the most up-to-date version of a shared project.
A pull can be stopped or aborted if you have unsaved local work that conflicts with the incoming changes. Git will pause and warn you, allowing you to save your work first rather than overwriting your changes.
- Pull Request
-
Aliases: PR, merge request
A proposal to merge changes from one branch into another, allowing for code review.
A pull request (PR) is a way to propose changes to a repository. Pull requests:
- Allow others to review your changes before merging
- Provide a space for discussion and feedback
- Can trigger automated checks and tests
- Create a record of why changes were made
On GitLab, this is called a “merge request” (MR).
- Push
-
The action of sending your local commits to a remote repository on GitHub.
A push uploads all the saved changes from your local computer up to the remote project on GitHub. When you push:
- Your local commits are safely copied up to the cloud
- The matching branch on GitHub is updated with your latest timeline history
- Your code changes instantly become visible and accessible to your entire team
Pushing is the essential final step in your daily workflow that shares your completed work with your team or even with the rest of the world in case you are working in a public repository.
Git might block or refuse your push if a teammate has uploaded new work to GitHub since you last pulled. If this happens, you just need to pull their changes down first before Git will let you push your own.
R
- Repository
-
Aliases: repo
A storage location for your project's files and their complete revision history.
A repository (or “repo”) is a storage location that contains:
- All your project files
- The complete history of changes
- Branches and tags
- Configuration and metadata
Repositories can be local (on your computer) or remote (on services like GitHub).
References: