In my last post, I eulogized the virtues of using Git for the simplest of scripts.  You can find that here.  In this post, I go over using Git with a remote repository, namely GitHub.

A remote repository takes all the goodness of Git on the local machine and extends it to a cloud service.  There are several advantages to this.  First, it provides an offsite location for scripts.  Making scripts available anywhere that has an internet connection.  You can access and edit scripts across multiple computers and locations. Most online repositories provide the ability to edit files directly from the interface.  Public or private repositories provide the ability to share code or keep it private.  Also, the code can be accessed from a URL.  This is handy for ARM templates and CI/CD pipelines.  Lastly, the remote repository I’m using for this article, GitHub, is free.

Remote Git repositories don’t synchronize changes like a OneDrive or Dropbox service.  There is no continues sync process that happens in the background.  Synchronization happens with either git push or git pull command.  All of which I go over below.

Remote Repositories also enable multiple editors in a repository.  That is where branching, forking, and merging comes into play.  This series of articles is forced on System Admins and lone scripters.  As such, I’m sticking to the basics and all editing is in the master branch for this article.

Sign Up

The first step is to sign up for an online service.  For GitHub, go to www.github.com and set up an account and profile.  I have an account already and don’t plan to set another up for this article.  I’m sure you can figure it out.  Go ahead and sign up if you don’t have an existing account.  All the steps below are similar to other cloud-based repository providers such as GitLab.

Create a Public Repository

Start by creating a public repository on GitHub.  Log in and click the button to create a new repository.  You will see a window similar to below.  Let’s go over what these options are about.

Owner – That’s you.  Be sure to upload a good picture.

Repository name – The name of the new repository. Spaces are replaced with a dash.

Description – This is optional, but add something descriptive so you can recognize what the repository is about a year from now.

Private or Public – As the description says, Public Repos are available for the world to see, private is just you and anyone you invite to it.  Create a public repository first to follow along below.

Initialize with a README – this adds a README.md file to the repository for commenting on the repository.  I suggest creating a README.md file to add notes or other information about the code.

Add .gitignore – This file contains file types that will not be added or synchronized from local Git to the remote repository.  This is useful for defining items such as *.log files that don’t need to be part of the repository but may find their way into the directory.  Notice there are preconfigured options. In the window above, I added the Terraform option.  This prevents Terraform temp files from getting copied to the remote repository.

Add a license – If you want to define a license file, do it here.

Once finished, click on Create repository.  Congratulations, you now have a remote repository!

Pull Down Public Repository

Once the repository is created, time to copy it locally.  This is done from Git Bash on your local computer.  Open Git Bash and go to the directory of the parent folder for the repository.  Git will create a new folder for the repository we are about to download.

Also needed is the URL for the repository.  This can be found in the green Clone or download button in the newly created repository.  Click the clipboard button to copy the URL. 

Next, run the git clone command with the URL to clone the repository locally similar to below, only replace the URL with your own.

git clone https://github.com/tsrob50/BlogPost.git

The repository is now available on the local computer. 

Pull Down Private Repository

Copying down a public repository was pretty easy and can be done from any publicly available repository, not just your own.  That’s not the case with private repositories.  For private repositories, you need to authenticate to GitHub in Git Bash first.  Start by creating a new repository like the previous one we setup, only create it as a private repository.

Like the public repository, get the URL from the green Clone or Download button and run the git clone command to copy the repository locally.

git clone https://github.com/tsrob50/BlogPostPriv.git

You should see a login prompt for GitHub as shown below.  Sign in with your GitHub account.  The credentials will be cached going forward.

At this point, the private repository exists on the local machine and available. 

Push Changes Up

As I mentioned previously, Git does not sync files to the remote repositories.  Changes need to be pushed to the remote repository.  This may seem cumbersome, but there is actually a simplicity to it.  As users, we control when changes are committed and when the online copy is updated. 

In this example, I start by adding a file to the private repository and commit the change.  After that, I’ll add content to the file and commit the change again.  In the real world, you don’t need to commit after every change.  I do it here for demonstration purposes.

The file has been created and updated with two commits, but nothing has changed on the remote repository. 

Changes are pushed to the remote repository with the git push command.

git push

Go back to the repository in GitHub and you can see the file has been added.

Next, go to the commit history toward the top of the page.  Notice that is shows the two commits done on the local machine.  This is an important distinction from simply copying files to a file server.  The change history is updated on the remote repository with the push command.

Update from Remote

That’s all good, but what happens when you use multiple computers?  The contents of a remote repository are pulled down to the local machine with the git pull command.  In the example below, I added a new file called hostname.ps1 to the online repository to simulate a remote change.  This is easy to do with the Create new File command in GitHub.

The local copy of the repository does not contain the new hostname.ps1 file.  The local copy is updated with the git pull command.  Git pull fetches data from another repository and integrates it with the local copy.

git pull

After the git pull command is run, the file created on the remote repository now exists locally.

Push a Locally Initialized Repository

The flow above is how I commonly create a repository.  Start with the portal and clone it to the local computer.  However, in my previous post I initialized a local repository called First Repository.  What if I want to push that to a remote repository?  Below I walk through that process.

First, create a new remote repository, either public or private.  This is where the local repository will be pushed to.   Do not create a readme or .gitignore file.  For this example, the remote repository is empty.  Copy the repository URL to the clipboard for the next step.

Go to Git Bash and navigate to the folder with the local repository, in my case it’s the First Repo folder.  From there, the remote repository is added with the command below.  Replace the URL with the URL for your repository.

git remote add First-Repository
https://github.com/tsrob50/First-Repo.git 

This adds the remote location to the local repository.  Next, the remote repository is set as the master with the command below.  Replacing First-Repo with the name of your repository.

git push --set-upstream First-Repo master

Files in the local repository are now available at the remote location.  The remote repository is also set to master and will behave similarly to the repose set up previously in this article.

Conclusion

This post went over using the three commands; git clone, get push and git pull to keep a remote repository up to date with changes.  It also went over using the git remote and get push commands to copy a locally initialized repository to a remote repository and set the remote to master.

If you have read this far, congratulations.  You have the fundamentals down and well on your way to using Git for all your scripting needs.  You may be thinking that’s kind of complicated, is it worth it?  The answer is yes, yes it is.  My next article is going to simplify this process with Git integration into an IDE, specifically Microsoft VS Code.

Read Next: Git and VS Code for the Lone Scripter
h