I’ve been learning git and… it’s been challenging. I’ve written about my experiences:
- Azure DevOps, SSIS, and Git Part 0 – Getting Started
- Azure DevOps, Software Development, and Git Part 1 – Applied
In this post I discuss some benefits of distributed version control. But first, I’d like to share this caused no small number of headaches and grief along my path to learning git. It’s a little embarrassing to admit, but it is true nonetheless.
Recently I migrated much of the source code for the DILM Suite (DILM == Data Integration Lifecycle Management) projects from other source control systems (and, sadly, no source control for some of the code) to an Azure DevOps project that uses git version control.
Here’s a screenshot of code for several editions of our commercial SSIS Frameworks:
When I grabbed this screenshot on this virtual machine, I was in the middle of an exercise I call “walking the code up the tree.” I have several – several – virtual machines on my laptop.
I can hear you thinking, “Why aren’t you using containers, Andy? Huh? HUH?!” Pipe down, Sparky. I prefer to develop “locally.” This preference drives another preference for GUIs for local tools (like SSMS). And, frankly, for version-y stuff – like SQL Server – I want to match the target environment as much as possible… we sell this solution, after all. Plus, I’d be using Windows containers and some folks (really, really smart folks) are of the opinion containers should all be Linux containers. The only problem with that thinking is the SSIS Catalog doesn’t run on Linux containers – at least not yet.
Before pulling a copy of the latest code from Azure DevOps, my local git repo appeared like this:
Note the absence of the 2017 folder.
I’m using Visual Studio 2019 and my environment is connected to my Azure DevOps project named DILM. What I need to do is copy the version stored in the DILM Azure DevOps project to my local repository. I start by click View–>Team Explorer:
When Team Explorer displays, click the Sync button:
The Sync screen displays; I next click the “Pull” link in the Incoming Commits section:
After some repo-updating progress bar display, my local repo is updated to the latest version:
Rechecking my local repo, I now see the 2017 folder:
One cool thing about git – and (probably) distributed version control in general: If things get… out of sync, I can delete my local copy and pull a fresh set of bits from Azure DevOps*.
* You want to be very, very careful here. If you’ve made changes to your local repo that have not yet been committed and pushed to the server, you will lose those changes. My advice? Do what I do: Copy the repo – zip it, whatever – before deleting it.
I’ve faced some challenges in my journey to git. I’ve learned a bunch and I’m certain I am doing some things wrong. There’s more to learn. I will share more of my journey, Lord willing.