An Introduction to Version Control with Git

The Ghost of Versioning Past

Anyone that worked in a team setting 20 or more years ago has likely felt the pain of collaborating with others in the same file or same set of files at the same time. The outcome of these team projects frequently ended in a couple of different ways: Multiple copies of one or more file labeled as “version 2”, “final draft”, or even the always present “DO NOT DELETE”, or a very long evening for someone unlucky enough to be tasked with merging everyone’s versions into a single final deliverable version to inevitably miss someone’s changes.

However, the “version” problems are not isolated only when working in a collaborative setting. I am willing to bet that many of us are able to find the same script/report/presentation labeled as “February 2024”, “customer 123”, or even “version 2 FINAL” buried somewhere within our hard drives even today when some sort of version history software is always available to us. This is where a proper Version Control system truly shines and my personal favorite happens to be Git, but before we dive into the specifics of Git I think it is important to discuss different types of Version Control and what some of the additional advantages to using version control truly are.

The “Insurance Policy” for Your Files

Version Control is a system that records every single change you make to your files regardless of what type of change you’ve made. Say you added a new paragraph, fixed a few misspellings, removed a sentence, or even added or deleted files, version control software tracks it all, giving you and your team the freedom to just work. It is almost like having both a time machine and an insurance policy combined offering you an audit trail (every change is documented), a safety net (providing the ability to “undo” or revert to a previous version), and branching (allowing you to create specialized or even experimental copies of your work without impacting the main copy).

Centralized vs. Distributed: Why Git Wins

Version Control systems are usually either Centralized (TFS, SVN, VSS) or Distributed (Git, Bitbucket). The main differences between these two types of systems comes in that with a Distributed system everyone holds a local copy of the work, and work can be performed offline allowing each team member to not only have the ability to contribute anywhere and anytime, but also serve as a backup in the event that the other copies of the work are destroyed. Git is a distributed version control system and rapidly grew to be a favorite for most developers and is the primary choice by major cloud services such as GitHub and Azure DevOps.

The Git Glossary: Speaking the Language

In order to get started with Git and become not only effective, but proficient with it, there are a few terms/concepts that one should become familiar with. The very minimum concepts that I think anyone can integrate into their workflow right away and therefore must know are Repository, Branch, Clone, Pull, Push, Fetch, and Merge. Let’s explore each of them:

Repository (or “Repo”): Think of this as your Project Container. It’s not just a folder; it holds every file, every change, and the entire history of your project from day one. It’s the “Single Source of Truth.”
Clone: This is the act of downloading the project. When you clone a repo, you aren’t just getting the latest files; you are taking a full copy of the entire “Time Machine” and putting it on your local machine.
Branch: Imagine a parallel universe. Creating a branch allows you to step away from the main code (the “Master” or “Main” branch) to try something new (like a risky SQL optimization) without worrying about breaking the production code.
Push: This is how you share your work. After you’ve made changes locally and “committed” them, you push them up to the central server (like GitHub or Azure DevOps) so your teammates can see them.
Fetch: This is a “check-in.” It asks the server, “Has anyone else done anything new since I last looked?” It downloads the info about new changes but doesn’t touch your actual code yet.
Pull: This is the full update. It’s a Fetch followed by an immediate update to your files. It’s like saying, “Bring my local files up to speed with whatever the rest of the team has been doing.”
Merge: This is the unification. When you’re done working in your “parallel universe” (branch) and everything works perfectly, you merge it back into the main project. Git intelligently stitches your new code together with the existing code.

The Git Workflow

The typical end-to-end workflow with Git varies slightly depending on whether you’re working on a new project, connecting to a repository you’ve never cloned before, or simply contributing to your normal job duties. For this blog post I will start from the creation of the repository but please note this is not something you will do often unless you’re constantly starting net new projects. I also will aim to keep the workflow generic as the tools you choose to utilize may vary slightly in terminology. This blog post also assumes that you already have a cloud service for Git such as GitHub or Azure DevOps, and have Git installed locally on your machine.

First we must create a repository to contain our work. I always prefer to follow standard naming conventions for the naming of my repositories that allow me to easily identify the type of work contained in the repo. Naming standards will vary per organization, some will be project-based (i.e. safety-metrics-dashboard), some will be team-based (analytics-all-work), and some will be technology-based (sql-sales-db, pbi-sales-dashboard, etc). My personal preference is to be technology centric as team make up tends to change overtime to adapt to the needs of an organization while technology remains more constant. After all, Power BI is Power BI whether you’re in Marketing, Finance, or central IT.

Once you’ve named your repository and initialized it in your cloud service (GitHub, Azure DevOps, etc.), the transition from “cloud concept” to “local reality” happens in a few repeatable steps.

The Developer’s “Daily Loop”

Even if you aren’t a traditional software developer (maybe you’re a Data Architect or a Power BI pro) the rhythm of your day will likely look like this:

Clone: You grab the repo link and run a git clone. Now, that “Single Source of Truth” lives on your C: drive.
Branch: Before you touch a single line of code or DAX measure, you create a branch. Think of this as your “sandbox.” It keeps your experiments isolated from the “Main” version that everyone else relies on.
The “Work & Commit” Cycle: As you work, you’ll periodically “Commit” your changes. This is like hitting ‘Save’ in a video game before a boss fight. If you mess up the next hour of work, you can always teleport back to this exact moment.
Push & Pull Request: Once your feature is polished, you Push it back to the cloud. This is where the magic of modern collaboration happens: the Pull Request (PR). You aren’t just dumping code; you’re inviting your team to review the work before it officially becomes part of the project history.
The Merge: Once your code has been reviewed and approved by your peers you get the opportunity to complete your Pull Request which in essence merges your feature branch changes into the main branch of the repository.

Why This Matters for the Long Haul

Transitioning to Git might feel like a lot of “overhead” at first, especially if you’re used to just hitting Ctrl+S and calling it a day. But remember those “version 2 FINAL” files we talked about earlier? Git kills that clutter forever.

By adopting this workflow, you aren’t just managing files; you’re building a searchable, reversible, and collaborative history of your professional output. If a client asks why a calculation changed six months ago, you don’t have to guess; you can look at the commit history and see exactly what happened, when, and why.

Final Thoughts

Whether you are managing complex SQL scripts or a suite of Power BI reports, Git is the ultimate insurance policy. It turns “oh no, I broke it” into “let me just revert that.” It turns “who changed this?” into “let’s look at the audit trail. If you’re still on the fence, I encourage you to try it on your next small project. Once you experience the peace of mind that comes with a “Merge” that actually works, you’ll never want to go back to “DO NOT DELETE” files again.