An Introduction to Git and Version Control

Version control is an essential practice within software development and data engineering and concerns the tracking and management of changes to files. Through systems such as Git, it is possible to have a backup of your code where edits are logged, and has the additional benefit of allowing collaboration and code reviews.

Git and GitHub

There are many version control systems but one of the most widely used is Git. Unlike some other systems, Git stores a history of your files (.py, .sql, .txt etc.) and provides a snapshot of all files at a specific instance in time - storing that as a reference point. If a file has not been changed, Git will not make a new copy but will provide a link to a previous identical copy already stored.

Something essential to differentiate between is Git and GitHub. Git is a local repository (similar to a project folder and contains the entire history of that project) whilst GitHub is remote and acts as a centrally located repository for your project code.

Branches

Branching is the concept of making changes to a piece of code in a separate workspace without messing the main line (branch) of code. It enables for multiple edits to be made simultaneously. There are two types of branches to be aware of:

Main Branch: this is where the production code sits and is actively being utilised

Feature Branch: where code can be developed/edited without impacting the main branch

Saving, Committing and Pushing

These are three integral steps in the Git pipeline. Saving is identical to how you would do so with any other file locally.

Committing: This is a snapshot of your work on a feature branch and should be done ideally after every logical unit of work.

Pushing: This is the process of moving changes from your local repository to a remote repository so they can be seen by others.

The order in which these steps is undertaken is important: Save — Commit — Push

Merging, Pulling and Conflicts

As mentioned, all changes are made on a feature branch instead of directly on the main branch. In order for the main branch to be updated with these changes the branches must be merged together. A pull request is made prior to merging, and a review of the changes is always made before they are implemented into the main branch.

On occasion you may encounter a merge conflict which occurs when different changes are made by different people to the same section of code. Only one change can be pulled through so a manual review of which change to keep is enforced in this scenario.

Pull From Remote

Changes to the main branch need to be reflected in any feature branches you are currently working on, this is where a pull from remote request is made.

Summary

To summarise the Git cycle...

1) Create feature branch off main branch

2) Edit, save and commit changes: these changes can be made in a code editor such as VS Code

3) Push changes to remote

4) Submit pull request

5) Review changes

6) If approved merge branches (and resolve conflicts if they arise)

Author:
Harvey Lloyd-Smith
Powered by The Information Lab
1st Floor, 25 Watling Street, London, EC4M 9BR
Subscribe
to our Newsletter
Get the lastest news about The Data School and application tips
Subscribe now
© 2026 The Information Lab