Glossary
A glossary of Git terms and concepts.
A
- Assignee
-
The person responsible for working on an issue or pull request.
An assignee helps teams know who is responsible for completing a piece of work. When using assignees:
- You can assign an issue or pull request to yourself or another team member
- Multiple assignees can be added if several people are collaborating
- Everyone can easily see who is responsible for the task
- Assignments help prevent duplicate work and keep projects organized
Being assigned to an issue or pull request does not automatically give someone extra permissions. It is simply a way to track responsibility.
References:
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
- Checkout
-
Switching from one branch or commit to another.
Checking out changes your working directory so you can work on a different branch or view an older version of the project. When you checkout:
- Git updates your working directory to match the selected branch or commit
- Your commits remain safely stored in their branch or commit history
- You can move between branches whenever needed
- If you have uncommitted changes, Git will only let you switch if those changes won’t be overwritten. Otherwise, Git will stop and ask you to either commit your changes, stash them, or discard them before switching.
Older tutorials commonly use
git checkoutfor changing branches. Newer versions of Git introducedgit switch, which is dedicated to switching between branches and is generally easier for beginners to understand. However,git checkoutis more versatile so you’ll still encounter it frequently in existing documentation. - 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.
References: - 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.
- Conflict
-
A situation where Git cannot automatically combine changes from different branches.
A conflict happens when two versions of the same part of a file have been changed differently. When a conflict occurs:
- Git pauses the merge or pull process
- You must decide which changes to keep
- After resolving the conflict, you create a new commit
Conflicts are a normal part of collaborative development. Most conflicts are resolved by editing the affected files and choosing the correct final version.
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
L
- Label
-
A way to categorize and organize issues and pull requests.
Labels help teams quickly identify and organize work within a repository. When using labels:
- You can mark issues as bugs, feature requests, documentation, or other categories
- Multiple labels can be added to the same issue or pull request
- Labels make it easy to filter and search for related work
- Teams can create their own custom labels to match their workflow
Labels do not affect your Git history or code. They are simply an organizational tool provided by interfaces like GitHub to help manage projects.
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.
- Milestone
-
A collection of issues and pull requests grouped together around a shared goal or deadline.
A milestone helps organize related work that should be completed together. When using milestones:
- You can group multiple issues and pull requests into a single objective
- Milestones often represent software releases, project phases, or deadlines
- GitHub tracks progress by showing how many items have been completed
- Team members can easily see what work remains before the milestone is finished
Milestones make it easier to plan, monitor, and communicate progress on larger projects.
References:
P
- Project
-
A GitHub planning tool used to organize and track work across issues and pull requests.
A project provides a central place to manage the progress of a repository. When using a project:
- You can organize work using boards, tables, or roadmaps
- Issues and pull requests can be added as project items
- Tasks can be grouped into columns such as To Do, In Progress, and Done
- Team members can track progress and prioritize upcoming work
Projects help teams coordinate their work and keep development organized beyond the code itself.
- 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
- Rebase
-
An alternative way of combining changes from one branch into another by moving commits onto a new base.
A rebase rewrites the history of a branch so it appears as though your work started from a newer commit. Rebasing:
- Creates a cleaner, more linear project history
- Can make commit history easier to follow
- Should be used carefully on branches shared with others
- Is often used instead of merging before opening a pull request
Although rebasing is a powerful Git feature, it is dangerous because it often is not revertable. For beginners it is recommended to use merges, which are safer, until they become more comfortable with Git.
- Remote
-
A version of your repository that is hosted somewhere else, such as GitHub.
A remote is another copy of your local repository that Git can communicate with over the internet. Remotes allow you to:
- Push your commits to GitHub
- Pull changes made by teammates
- Collaborate across different computers
- Keep backups of your work online
A repository can have multiple remotes, although beginners usually only use one named
origin.You can view your configured remotes by running
git remote -v. - 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).
- Review
-
The process of examining a pull request before it is merged into a branch.
A review allows team members to check code for quality, correctness, and readability before it becomes part of the project. During a review:
- Reviewers can leave comments or ask questions about specific lines of code
- Changes can be approved if everything looks correct
- Reviewers can request changes before the pull request is merged
- Discussions help improve the quality of the code and share knowledge across the team
Reviews are an important part of collaborative development and help catch problems before they reach the main branch.
S
- Squash
-
The process of combining multiple commits into a single commit.
Squashing is used to simplify a branch’s commit history before it is merged into another branch. When you squash commits:
- Multiple smaller commits are combined into one larger commit
- The final commit usually has a single, descriptive commit message
- The project’s history becomes cleaner and easier to read
- The individual commits are replaced by the new combined commit
Many teams squash commits before merging a pull request to keep the main branch’s history organized and focused on completed pieces of work.
T
- Tag
-
A permanent label attached to a specific commit.
A tag is used to mark important points in your project’s history. Tags are commonly used to:
- Mark software releases such as v1.0.0
- Easily return to important versions
- Share stable versions with others
- Keep release history organized
Unlike branches, tags do not move when new commits are created.