I’m writing about my journey with git, sharing my experiences along the way. The series to date:
- Azure DevOps, SSIS, and Git Part 0 – Getting Started
- Azure DevOps, Software Development, and Git Part 1 – Applied
- Azure DevOps, Software Development, and Git Part 2 – Distributed Version Control
In this post I cover command-line operations with git. Why? Because it took me… several… attempts to figure out how to even get started. The git documentation is truly good and freely available, and it is an awesome place to start. I needed to read the same portions of the git documentation… several… times before it “took.” The sections I reference here are:
- 1.6 Getting Started – First-Time Git Setup
- 2.1 Git Basics – Getting a Git Repository
- 2.2 Git Basics – Recording Changes to the Repository
The Problem I Am Trying to Solve
I want to manage legacy code from an older virtual machine environment (SQL Server 2012, Visual Studio 2012) using Azure DevOps. My Azure DevOps project is configured to use git version control.
I find git source control and Visual Studio 2012 do not play nice.
I started by downloading the latest Windows release from the Git Downloads page:
Now, I confess this download confused me some because a lot is installed. I used a small portion of the installed code.
The Executable (I Used)
I installed the download on my VM’s E drive. The VM’s PATH variable was updated thus:
Because of this addition to the VM’s PATH, whenever I open a command prompt, I can access items stored in the VM’s E:\Program Files\Git\cmd directory without specifying the full path to that item. For instance, I can reach git.exe by simply typing “git”:
To get started with git on this VM, I needed to initialize two configuration properties: user.name and user.email. I used the following commands:
- git config –global user.name “Andy Leonard”
- git config –global user.email [email protected]
I opted to use Notepad++ as my text editor when I need to add commit messages with git. I set this option using the following command:
E:\git\repos\DILM>git config –global core.editor “‘E:/Program Files/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin”
Once configuration is complete, you can view it using the command “git config –list”:
In my case, my server repository exists on Azure DevOps. I wanted a local copy. The command for that operation is clone:
git clone https://dev.azure.com/<Azure DevOps Organization>/_git/<Azure DevOps Project>
For me, this command looked like this:
Once you have a local copy you can check the status at any time. But this check must be performed from within a directory that contains a .git directory – and this directory is hidden:
After making a small test change to one file, I wanted to commit that change back to my Azure DevOps repo. Before you can commit, though, you need to stage the change locally.
If you attempt to commit changes (and changes exist) without staging them first, you are informed thus:
On branch master
Your branch is ahead of ‘origin/master’ by 1 commit.
(use “git push” to publish your local commits)
Changes not staged for commit:
no changes added to commit
Checking the Status tells the tale:
You need to first stage the changes and you stage changes by adding them using a command similar to:
git add SSISFramework/2012/0_sql/FrameworkSQLScripts/0_InitialAndConnectionBuild.sql
Now, this threw me a little. If the stage (add) command works, you get… nothing:
In order to determine whether this command worked or not, you have to check the status:
Now I can commit the change to my Azure DevOps repo using the git commit command. When I execute git commit, Notepad++ opens and informs me:
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is ahead of ‘origin/master’ by 1 commit.
# (use “git push” to publish your local commits)
# Changes to be committed:
# modified: SSISFramework/2012/0_sql/FrameworkSQLScripts/0_InitialAndConnectionBuild.sql
Once I close Notepad++, the commit completes:
I have no doubt there are other ways to get started with git, and I would wager $1USD that there are several better ways to get started. This post describes how I started using the git command-line to start managing a repo on a virtual machine built for backwards-compatibility with SQL Server 2012 and Visual Studio 2012. This worked for me.
3 thoughts on “Azure DevOps, Software Development, and Git Part 3 – Command-Line”
Re: git CLI. Don’t feel bad — I’ve been whacking this particular mole for a while now. Turns out to be handy, though. Every now and again VS gets confused and the only way (at least that I’ve found so far) is to break out the trust cmd.
Comments are closed.