Git and GitHub Terminology: a Complete Glossary

Working daily with Git and GitHub, Fabien, software engineer at Mergify, offers an article listing the technical terms and glossary specific to Git and GitHub.

No need to search anymore, everything is here in your new Git dictionary by Mergify.

This article is intended to evolve over time and will be regularly updated.

Pull Request

To begin this glossary, let's focus on the terms directly associated with Pull Requests. As you probably already know, this is our raw material at Mergify, so let's get it right.

ASSIGN:
Assign a user to a Pull Request (See def of ASSIGNEE)

CLOSE:
Action to close a Pull Request, and thus cancel the proposed changes. Once closed, the Pull Request does not disappear, but remains available in the Pull Request history.

COMMENT:
Action of commenting on a Pull Request. For example in a Review or a discussion.

COPY:
Action to copy a Pull Request to another branch. If a Pull Request is proposed on a branch A, it is possible that we need to propose it also on a branch B once all its tests are passed.

LABEL:
A label is a (colored) tag displayed after the title of a Pull Request or attached to it. Labels allow you to visually differentiate, annotate and sort Pull Requests. Then, thanks to Mergify, the labels can be used as a condition to perform specific actions. For example, a Pull Request with an "A" label can validate a condition leading to the writing of a "B" comment. The possibilities of using labels are very varied.

Git Commands

With the pull request glossary in your pocket, it's time for you to move on to Git commands. These are the essential commands that make your day. It's best to master them to avoid any misunderstanding within your team!

FETCH:
Git command to download content from a remote repository, in order to get the latest changes and status.

PULL:
Git command regrouping the Git Fetch then Git Merge commands. So, this action aims to download and apply the last modifications of a repository in your local repository.

CHECKOUT:
Git command allowing to navigate from one branch to another, between the different existing branches.

BRANCH:
Git command to create a branch.

REBASE:
Git command to change the original commit of your branch, giving the illusion that you created your branch from this new original commit. This command is useful for updating the feature branch when the main branch has changed during the development of your changes (read our article explaining the difference between Git Merge and Rebase, to deeply understand the rebase concept).

SQUASH:
Git command to merge multiple history commits into a single commit.

STATUS:
Git command allowing to observe the tracking of files by Git. You can see which files will be proposed to commits, which files have been modified, which files are not tracked by Git.

STASH:
A git command to temporarily store a set of changes. This allows us to return to the state of the branch before the changes were made. We can then UNSTASH the previously stored changes in order to continue our work on them.

LOG:
Commande permettant d’afficher l’historique des Commits de la branche sur laquelle on se situe, afin de mieux observer le contexte dans lequel on travail.

DIFF:
Command to visually display the changes made to a file.

CHERRY-PICK:
Git command that allows you to select one or more specific commits from one branch in order to transfer them to another branch. Useful when you don't want to merge an entire branch to another one but only a particular selection of commits.

PUSH:
Most commonly used git command. This command allows you to send local changes to a remote repository so that they can be seen by other team members and offered for merge.

BACKPORT:
Action of passing on changes (commits) from one branch to another. For example, in the case of a versioned IT project with a dev branch where the work is produced and a series of release branches (1.7.x, 1.8.x, 1.9.x,...) corresponding to the different versions of the project available to users. If a commit is made on the dev branch, we will later want to reflect this change, for example, on the branch of version 1.9.x. So we will proceed to what is called a "Backport" of the changes from the dev branch to the version 1.9.x branch. In other words, we copy a commit from one branch to the other.

Business Notions

Now that you've mastered the vocabulary surrounding Pull Requests and Git commands, it's time to dive into the business jargon.

REVIEW:
Action of reading, correcting, validating, debating about the changes proposed in a Pull Request.

REVIEWER:
In the sense of GitHub, the person(s) responsible for the review of a Pull Request.

ASSIGNEE:
An assigned user is in a way the "responsible"/"manager" of the Pull Request, he is accountable. Not to be confused with the Reviewer (see REVIEWER).

BRANCH PROTECTION:
Branch protections allow you to secure and control each change made to a project branch. A branch protection is actually a rule that must be respected in order for a change to be taken into account. For example, ensuring that a Pull Request has at least one review before it is valid for merge.

HISTORY:
Chronological list of all the commits made on a branch. A history is said to be "linear" if there are no discrepancies and each commit is put together in a single timeline. A linear history has many advantages such as having a quick overview of the evolution of the project, or quickly going through the different commits of the project and easily spotting, eventually, the faulty commits and their chronology.

TREE:
Another name for the Git history. Indeed, since a history can be made up of divergences due to the merge of branches, the latter can visually refer to a tree from which branches can appear at a given point, thus creating a new continuity, in parallel with the others. In the case of a linear history, the tree will only consist of its trunk.

Technical Notions

You come to the last part of this glossary. This part is dedicated to the technical notions related to the use of Git and GitHub.

COMMITS:
A commit is a change, a modification, made to one or more files.

GIT BRANCH:
A branch is a separate development area of your project, allowing you to experiment with any new changes you want to make. A branch is always based on the MASTER branch (see MASTER BRANCH) of the project. In the sense of the Git history, it represents a deviation from the project allowing you to implement new changes without impacting the trunk of the main tree (see HISTORY, TREE). In fact, the starting point of a branch is a pointer to a commit in the history.

MAIN BRANCH:
The default branch of a Git project. A project can have only one master branch. It is in this branch that all the changes made to the project, once validated, are stored.

FEATURE BRANCH:
Local branch where you will proceed to any creation/addition of changes to your project. The feature branch will then be proposed to merge into the main branch via a Pull Request.

ORIGIN:
Origin is the default name given to the remote repository (see REMOTE) of your project. It is in this repository that you will propose your changes to the merge via a Pull Request.

REMOTE:
In the Git sense, a remote is a link to a repository common to all the members of a team, in which each one proposes his changes and can see those of the others. There are also local remotes which are links to repositories accessible individually by the team members, where each one will make his changes, before pushing his modifications to the common remote.

FORK:
In the GitHub sense, a fork is a copy of an external repository to your personal space. Making a fork of a project allows you to work on it in your personal space in order to propose changes. It is a different alternative to propose changes in a repository.

UPSTREAM:
Alias which defines the original remote of the project, from which you have made a fork (see FORK). It is from this remote that you will get all the changes and updates of the project.

DOWNSTREAM:
Alias that defines the local remote you have forked (see FORK). This is where you will work and through which you will be able to share your changes with other team members.

HEAD OF BRANCH:
Term defining the last commit of the current branch.

HEAD BRANCH:
Current branch in which you are located.

MERGE:
In the GIT sense, Merge allows to merge a sequence of commits into a unified history (read our article about Git Merge vs Rebase to understand the merge concept). Often, we merge the history of two branches into one (the dev branch merges its commits with the main branch, into a single unified main branch). Often, when merging two branches, we create what is called a "Merge Commit", which leaves a trace of the merging of the two branches. There is also the case where more than two branches must be merged at the same time (see 3-WAY MERGE)

3-WAY MERGE:
In projects where several people are working together, it is not uncommon for this to happen. You develop a feature that takes you time, during which time colleagues implement their changes on the master branch. So you end up with a late master branch and a feature branch to merge on this master branch, which is itself late. We talk here about 3-WAY merge because we take into account the common base (C3) of your feature-branch with the master branch, the new commits of the master branch (C6) and your feature (C5). Read our detailed article 3-Way Merge or Merge Commit: Why Is It Better Than a 2-Way Merge?

CONFLICTS:
When you try to merge two branches that modify the same piece of code, Git doesn't know which changes should take precedence. So Git stops before the Commit Merge is created, and there is a generation of conflicts, which you then have to resolve manually.