Why you should use Git command line


Writing this for developers, testers, UX designers or anyone who might interact with source code stored in Git but as yet hasn’t used Git command line, instead uses a GUI or integration (Tortoise, Source Tree, Intellij/VS integration etc.).

Git command line is the low level program that interacts with git repos in a terminal or powershell window. I know that using the terminal and typing commands is a big step for most inexperienced users, but please stick with me and hopefully I’ll convince you.

Why you should use Git command line

You will know and understand what you are doing

Most people I’ve known starting with Git first start with a GUI tool. Something to handle Git for them. While understandable, this is a mistake as you do not know what the tool is doing or learn how Git works.

GUI tools will be using the same Git commands under the hood, they will just hide them from you. Whether you are learning source control from scratch or just new to Git it will help you in the long run to understand what the basic commands are and what they do.

You will know exactly what you are changing

Source control GUI tools hide some of the complexity of using git, but in doing so hide what they are actually doing. This can be as simple as pre-selecting the list of modified files for a commit, or as complex as handling a merge for you. Either way, you no longer know exactly what the tool is doing and changing.

With Git command line you are forced to declare exactly what files in source you are changing and can see exactly how they have changed.

git status and git diff, how I love you.

It’s not that complicated

My normal day to day use of git only uses 7 commands; pull, checkout, status, diff, add, commit and push.

Truthfully, for anything more complicated I just search for it. I haven’t memorised much else and you shouldn’t have to either.

Command line is universal

Git command line is the same on every machine, every environment. Learn it once and you won’t have to learn it again. Not if you switch editor, language or go from Windows to Mac. The commands won’t change.

Different GUI tools use different UI, different names for the actions and even apply different low level operations for actions, e.g. may automatically pull before a push or rebase.

Even authentication is standardised, as you can setup your ssh key so you don’t need to keep entering username/password for operations.

How to learn Git command line

It’s easier than ever to pick up and learn git, here’s a few resources to help you start:


I hope this has convinced you to give Git command line a try. If not at least you will understand why I sigh when I see you trying to fix a git issue with your mouse.


Using private Nuget packages hosted in VST

Writing this as a quick guide to using your own private Nuget packages hosted in a private feed in VSTS for dotnet core. There is official documentation but I encountered enough issues that I think it’s worth documenting.

1. Install Package Manager into your VSTS

You must install Packagse Manager extension into VSTS. There’s a 30 day free trial, after which you must pay.

Setup your private feed, this will be used to publish your private packages to authenticated VSTS users needing the packages in Visual Studio and in the VSTS builds.

2. Create your Class Library needed as a package

Create the Class Library project in Visual Studio which you need packaged.

NOTE: As of writing in dotnet core you must create as Console App and update to class library in project properties->Application->output type due to issues with templates.

In project properties->Package setup the package metadata. Do not check “Generate Nuget package on build”. Version number will be overridden in VSTS build definition.


3. Setup VSTS Build definition for Nuget Package

Add a new build definition for your Class Library repo/project, based on the template for ASP.NET Core template (sets defaults for project paths and build version number).

  1. Remove the Publish setups.
  2. Replace dotnet restore with a Nuget task restore (to allow using your own feed).nuget1
  3. Use a dotnet pack task to build the Nuget package with explicit version number based on build.nuget2
  4. Use a Nuget task to push the build package to the private feed.nuget3

4. Reference your private Nuget package in another project

Add a Nuget.config file to your project which needs the private package dependency to use the private Package Manager feed.


You can also add this in your Visual Studio global Nuget.config but makes the feed explicit for others using the same source. You will be prompted to authenticate with VSTS the first time you build to resolve the dependency from the feed.

In the build definition for the project add a Nuget Restore step which references your private feed (standard dotnet restore will not pick up the Nuget.config or authenticate with the private feed).


Tricks and traps (as of writing 2017/07/25):

  • Standard agent queue “Hosted” does not support dotnet core, use “Hosted Visual Studio 2017
  • dotnet restore does not support using Nuget.config or authenticating with private feed, use Nuget restore task
  • Nuget pack does not support dotnet core packages, use dotnet pack with explicit version option