GIT – Setting up a local repository, working within GIT CMD Terminal, and integrating with Visual Studio Code!


This will be a step by step of creating a local Repository, and how to work with GIT

As of 7/9/20 I’ve deleted all content from this article, and recreating it to better start off with GIT, rather than documenting my struggle to force it to work with VSC and GitHub!

That being said, this document will be more aimed towards the basic setup and some integration with Visual Studio Code and GitHub, and how to get started with creating version history using GIT rather than creating multiple scripts with slight differences.

A few things you will want to download / sign up for at some point for GIT:

  • – I would sign up but when creating a new Repo do not “Initialize” it as we will work from local and push or clone the local up to our GitHub Repository to share our Master Repo for others to collaborate on
  • – Visual Studio Code is a great text editor, and integrates well with both Local GIT Repo’s and Remote Repo’s like GitHub
  • – This will provide a BASH Shell for GIT to work locally on your PC which is how I will start out my GIT Repository (What I am using is actually the “GIT Bash Terminal” in this post, though a Shell is included in the GIT Download for windows).

***Note there are some other GUI programs like “GIT For Windows” and things like that, you do NOT want those, you want the GIT Bash / CMD Terminal for Windows / Mac ***

At this point I will get into making my local GIT Repository initial configuration

I had made a lot of Python Scripts along with some XML and just text files (used within scripts) that I loaded into a main folder, and put on it on the Root (C:) to more easy Navigate to, then opened my GIT CMD Terminal and navigated to it and did initial setup:


After setting up these initial parameters (username / email) within the GIT CMD Terminal in the Folder / Directory I intend to use for my repository, I now have two options to create the local repository on my machine:

  • “Clone” a remote repository to this one, so it will still be a local repository that I can perform change controls on whatever documents I import via Clone, and will not impact the remote Repository that it was cloned from
  • “git init” to “Initialize” this folder at the Repository itself, which creates a hidden .git folder / directory that I will review after initializing this local repository

I will be starting out with creating a local GIT repository, and work on integrating it into Visual Studio Code, and have actually completely wiped out my loopedback GitHub:


Updated 23 seconds ago, meaning I went to its “Settings” page and scrolled down into the “Danger Zone” settings, and deleted the Repository (I’ll admit it hurt) and re-created it.

Back to setting up my local GIT Repository on my laptop to begin with!

In the GIT CMD Terminal I issue the “git init” and this makes the folder / directory I am currently in the local GIT Repository that I will be working out of:


Here I issue “git init” and it spits out a small message, then I “cd .git” to get into the actual GIT directory which is a hidden directory within “LocalRepo” directory, you will not see any GIT files when typing “dir” in C:\LocalRepo\ prompt except the scripts within it.

However if I got into the .git I can get the GIT details of the directory, such as Config, Description, HEAD, and other hidden directories such as hooks / info / etc.

This folder “LocalRepo” is now a GIT Repository, it can be cloned out to remote GitHub Repository’s or copied to a thumb drive and installed on another local machine as a repo!

Next I will add all the files to be tracked by GIT, and do an initial “commit” to them

In the following screen snip, I add all files in the directory or “Stage” them initially by using the command “git add *.*” in the GIT CMD Terminal, and then I commit them:


Being that these are all now Staged / Committed with the comment “Initial Commit” tagged on there as every commit should have some comment indicating the update, I would not be able to up arrow and commit again because files must be staged before they can have a “commit” issued for them (and being there are no changes there is nothing to stage / commit).

Time to integrate my local GIT Repository with Visual Studio Code that I work from!

Its fairly easy to now point my Visual Studio Code to my local GIT Repository on my laptop, this is done simply by selecting the GIT symbol in VSC and selecting the folder:


Once I’ve selected my Repository Folder, it imports it into Visual Studio Code but won’t show all my files within this GIT tab, you will only see files that have some kind of pending change that needs to be Staged / Comment Added / Committed shown here:


I am actually not entirely sure if .gitignore file should be tracked (as the U stands for “Untracked” by GIT), however this demonstrates that when a new file or change is detected it will show up in this tab, and you will need to push the + button to “Stage Changes” / give it a commit message below the red line underscoring the Repo name of LocalRepo, and then hit the check mark to the right of it to commit – So for example:


I’ve hit + which has now changed it to “Staged Changes” and the letter “A” next to it, I’ve entered a brief description comment of “Initial GitIgnore Tracking” and above that is where the check mark and other symbols appears if you hover over it to commit however I left the mouse off of it so the Repo Name and GIT can be seen.

Now in the files tab of VSC you can see your Repository and its files shown here:


And that is about all I have to say about that.

Moving along to staging and committing files using both VSC and the GIT CMD

With GIT there are 3 stages to a file from a tracking stance: Unmodified, Modified, and Staged before ultimately committing changes to a file and updating its version history.

What is the big deal with staging? Why not just commit changes immediately?

Staging is done so when working on large scale projects, you don’t accidentally commit a lot of unintended changes, and also so you can have different comments for different pieces of codes such as bug fixes or enhancements.

Another note on “Commit” operations, they should be done frequently as you are sure that your code update is correct and complete, as they are lightweight operations and can be undone with GIT version history / change control.

So lets take a look at this by adding an Ice Cream flavor to my AwesomeFood XML Script:

First a quick look in the GIT CMD Terminal using “git status” to view the local GIT repo:


Everything is good there, so I open my XML script and add my flavor, and now I have a color on the left hand side of the script to indicate tracked changes in the script:


At this point I go to save my file, but then a GIT notification pops up in VSC, and also the status changes in our GIT CMD Terminal:


We now have a modified file running loose out there somewhere, and inside VSC(!) :


At this point I have only saved the file locally in Visual Studio Code, and now our GIT CMD Terminal and VSC is throwing up flags that we have a modified file, so I check out the GIT Tab in VSC to see whats going on:


Note that it now shows “M” for Modified file, I’ve put in my Comment of “Adding Snozzberry IceCream Flavor” before staging and committing this file, then once committing it goes back to nothing in VSC and Git CMD is back to a clean tree:


When the file is “Staged” in VSC this “Modified” message in GIT CMD Terminal will turn green noting it is staged to be committed, however I missed the screen snip so I wanted to at least mention it for the sake of being thorough.

Also in GIT CMD Terminal I could have done a commit with git commit -m “Some message for the commit” to make the commit with a message attached.

Here is an interesting scenario you may be see on the exam or real world

What if you make a change, stage the file to commit, and then make another change?

Are both changes Staged? Will either change commit? WHAT PLANET AM I ON???

Lets check it out (You are most likely on Earth) :


Now here I’ve made two changes to our Sibling / Element “Pizza” to Toppings2 and Staged that change in the GIT CMD Terimnal, then added Toppings3 but did nothing yet other than save the file locally in VSC so lets see how it looks in GIT CMD Terimanl:


So here we see the file was modified (saved but not staged in VSC), I then typed “git add AwesomeFood.xml” to put it into a “Staged” status as indicated by the green, but then I made another change and saved it within VSC but didn’t stage it.

Now when I do “git status” it shows AwesomeFood.xml both has Staged and non-Staged changes both at the same time, so if I type “git commit -m “Some comment” “ What will be the result?

The results were actually a bit surprising and I am not sure what to make of them:

I did this on another file to test actually hitting “git commit …” in this state, and the file pulled back up with the extra line I did not stage:


“git status” doesn’t show any issues after the commit, I do see 1 deletion, however I do also see 4 insertions / 1 file changed from this script in VSC:


Ultimately how you would fix this issue instead of doing a “git commit” is by simply doing another “git add (filename)” and it will combine both changes as Staged and ready to Commit – Though this file seems to still have its non-staged Line #4 in it!

I am almost 100% certain Visual Studio Code has something to do with this un-Staged change going seeming to Commit to the Local Repo, so for exam day I would go with the un-Staged changes would be discarded as it seems it says in the output in the GIT CMD Terminal, but then VSC shows that Line #4 even after a reboot of my laptop.

So I will humbly admit, I have no idea what happened there, and you may want to play with this on your own to dig into to the finite details of this odd behavior 🙂

And with that, I have officially had quite enough of GIT for tonight, more to come!

There is just a ton more to GIT but its really GITs into really nitty gritty detail, I wanted to demonstrate how to clone my repository up to my GitHub account in this one, but I think I’ve covered enough to make myself relatively brain dead after a long work day.

I will be covering JSON and YAML then be wrapping back around to finish off GIT during my Intro week to the DevNet group starting next Tuesday while I still have a chance, so I will be staying busy.

I am going to go sit on the recliner, and let my brain cool off, until next time! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s