Skip to content

Git concepts


A repository or repo is a collection of source code files; typically grouping together all the source code for one app or one project.


A branch is a version of the source code in a repository.

The naming of branches, and what each represents, is a matter of convention. For example, by some conventions:

  • the main branch (previously called master) contains the version of the code running in production
  • the develop branch contains the code under active development
  • a feature branch represents a version of the code related to a single feature under development.


A commit is a collection of changes to the code. It is the smallest unit that can be tracked by git.

A commit can be huge and contain many changes, or can be tiny and contain a single, small change. In order to make the most of the benefits afforded by git, it is a better practice to keep commits small.


A Merge Request or Pull Request is a request to merge one branch into another, thereby incorporating all the commits (ie changes) from the merged branch into the target branch. After the merge, the target branch will contain all the commits from the merged branch.

Gitlab calls this a Merge Request (MR). Github and Bitbucket call this a Pull Request (PR).

A MR/PR is the opportunity for another developer (peer or supervisor) to review a developer's code.

Working copy

When working on a project, you would make a copy of the source code on your computer, and make all the relevant changes to the code on your computer locally. The local copy of the source code is called the working copy.

You will then save the changes you make to the working copy as commits.


Cloning is the action of creating a local working copy of a repository.


Committing is the action of recording changes to the code in the working copy as commits so that they can be tracked by git.


Pushing is the action of saving your commits (ie the changes you made to the code in the local working copy) to the repo.


Merging is the action of combining the commits in one branch (the //merged// branch) into another branch (the //target// branch). After merging, the target branch is updated to contain all the changes made on the merged branch.


A conflict occurs during a merge when one or more commits from the merged branch cannot be incorporated into the target branch.

This can happen when the target branch has changed in the meantime.

Generally, git tries to resolve most conflicts automatically. However, when this is not possible, it reports a conflict and refuses to complete the merge.

In this case, the conflicts have to be resolved manually. This means that the developer must decide among one of 3 options:

  • Keep mine: keep the changes in the merged branch and erase the original code in the target branch
  • Keep theirs: keep the code in the target branch unchanged, and ignore the changes in the merged branch
  • Manually fix the code and decide which parts to keep from the merged branch or the target branch


A revision is the state of the source code after any commit. It's pretty much synonymous.


A tag marks a specific revision. This can be used for later reference; more commonly, it is used to mark the code that was deployed into production.