Introduction to Git and Github

Cybersecurity First Principles in this lesson

Domain Separation

Good fences make good neighbors.


The concept of modularity is like building blocks. Each block (or module) can be put in or taken out from a bigger project. Each module has its own separate function that is interchangeable with other modules.

Introduction: Git and Github

Lesson goals

Materials required

Prerequisite lessons

Table of Contents

Step 1: Create an Account

First things first, create a free account on Github:
You will also need to verify your email address after registration in order to use your new GitHub account.


Step 2: Hello World

Complete the following Github tutorial:

At the end of Step 2, you will have created a remote repository and will have added a branch. It is remote because all your files are in the Github cloud. As a developer, you might ask, “how do I use this to create code if it is just online?” It is not convenient to write and test code online, especially when many applications require locally install packages to even work. It would be great to use your own Local repository. We will do just that in the next step.

Git is a distributed configuration management system. It helps to avoid thinking of a traditional central code repository. Instead, with Git we have multiple independent repositories that could be in different states at any given time and synchronized using specific commits.


Step 3: Clone a Repository

To create a Local repository there are two basic options.

  1. Clone a remote repository on your computer, or
  2. Initialize a new git repository from scratch on your computer.


Clone a remote repository

Let’s start by looking at option #1 and checking that Git is installed.


To clone a remote repository (what we set out to do), we first need a reference URL to find it.

You will start to see some download messages and upon success, your local repository will be ready for use. You may be asked to authenticate with Github credentials if your repository is not public.


Now, in PowerShell, switch to the hello-world directory that has all the files from the repository that you just cloned.

cd hello-world/

To list the files in this directory, use this command


You should see a and possibly some other files.


Step 4: Push Changes

In this step, we will make changes to files in our Local repository and then push changes back to the remote repository.

Git is based on a de-centralized model of ownership - which means that there is no central authoritative repository. Every repository, Local or Remote, is fully autonomous and fully functional on its own. So changes made in any repository are tracked in that repository only. Two repositories do not communicate unless there is a explicit request to synchronize changes across them. This will make more sense as we work through a scenario.

Let’s open the hello-world folder in windows explorer and make changes to the file in a text editor.

  1. Navigate to the files
  2. Open in Notepad
  3. Edit to add a message. Like the one below.


Once you save the edited, check the status of the local repository using the following command. Return to PowerShell:

git status

You should see something like this:


A few things to notice here about these status messages:

  1. On branch master: You are on the master branch in your local repository.
  2. Your branch is up-to-date with 'origin/master': Your local repository master branch is in sync with your remote repository master branch on GitHub. The default name for the remote repository is origin. This makes sense as you cloned your local repository from it.
  3. Changes not staged for commit: git follows a two step process to save changes to a repository.
  4. The user indicates which modified/deleted/new files need to be staged for a save in the repository.
  5. The staged files are committed to the repository.
  6. modified: git knows that the file has been modified

Now we stage our changes for a commit using this command:

git add --all

The above command adds any edited files in a staging area, a temporary holding place before a commit. We can check the status of the repository again using the following command:

git status

You should see something like this:


This time the modified files are staged for a commit and appear in green.

Now before we commit these files into our local repository, the git author details need to be set. This is for accountability of commits. Using the commands below, save your information to the git configuration files and set them for all of your local repositories. Make sure to use the same name and email you used to register with Github. This is a one-time setup only. Once it is set, you don’t have to do this on subsequent commits.

git config --global "replace this with your name"
git config --global

You should see something like this (with your name and email):


Check your configuration changes by using the following command:

git config --list

Again, you only have to set the config parameters once. Now that they are set, git will keep reusing them when making commits or merging your changes with other repositories.

Now let’s commit the changes that we staged before. Here we use the commit option with -m to provide a short commit message. This helps us remember various checkpoints in our editing process. These messages are very helpful to rollback changes to an appropriate commit.

git commit -m "added UNO description"

Use this command to see all your commits:

git log

This command shows a summary of commits in the repository, starting with the most recent. Observe the hash code, user details and commit message. These attributes provide attribution of all changes in the code repository, promoting code integrity.

Hit the key q to exit the log of commit messages.

Issue this command to check your repository status once again:

git status

It should report no uncommitted changes. But it indicates that Your branch is ahead of 'origin/master' by 1 commit. Which means that our local repository master branch has more recent commits than the remote repository master branch.

To push our local commits to the remote repository (Github in this case), we need the git push command. With this command, we need to indicate the name of the remote repository followed by the name of the local repository branch that has updates to be pushed. Do you remember the name of our remote repository and the main branch?


  • What is the default name of the remote repository?
  • What is the default name of the base branch in a repository?

To push local commits in the current branch to a remote repository (origin in our case) and its remote branch (master in our case), use the following command:

 git push origin master

OPTIONAL: To rename a branch in the remote repository, you’d use the same git push command, but you would add one more argument: the name of the new branch. For example:
This command pushes the LOCALBRANCHNAME to your REMOTENAME, but it is renamed to REMOTEBRANCHNAME.

Now, issue the status command to check your repository status once again:

git status

Visit your remote repository on Your changes should appear there. You should also see your commit message there. Clicking on the commit message will show the file differences in that commit.


As mentioned before in the introduction, git version control is very efficient for text files. It does not store entire files for old versions but only the differences. So it is prudent to make frequent commits and then push these changes to the remote repository - so that you have as many checkpoints as possible should you need to roll back. To keep the master branch commits clean, it is advisable to do feature development and testing in a feature branch and then merge with master.


Step 5: Pull Remote Changes

What happens if we make some changes to on Or another collaborator makes changes to it. How do we get these changes back into our local repository? We will learn just that in this step.

So, I realized that I forgot to add a link to UNO’s Cybersecurity programs in the file. So I will make these changes and commit those changes on itself.

  1. First, click on file on Github and then click the edit option as shown below:


  2. Make changes, add a commit message and click Commit changes


  3. See changes in your file


Now the remote repository is one commit ahead of the local repository. To bring the local repository up to speed, we use the following command in a terminal. This single command fetches remote changes (git fetch) and merges them (git merge) into your local repository.

git pull

Sidebar: If a repository has linked sub-modules (e.g. nebraska-gencyber), add the following recursion flags to clone and pull changes from the sub-modules as well:
git clone --recursive
git pull --recurse-submodules

Continuing with the lesson, if we look at our local README.MD file in windows explorer, it should have the updated link.


At this point, you know enough to keep both the local and remote repositories synchronized.

As long as you always pull before making changes and keep pushing any new changes - you will avoid most merge conflicts that can occur.

If you are interested in learning more about complex team interaction scenarios - you may want to explore a concept called branching that avoids most merge conflicts; for more information about merge conflicts see:


You are now ready to explore the wonderful world of open source on Github. Enjoy and make your own contributions!


Initialize a new repository

In previous steps we assumed that a repository existed on Github. What if you wanted to start a repository on your local computer? If you need to create a new repository you would just navigate to the folder (using the cd command) containing the files you wish to version control and then use the init command.

In the commands below, I will first create a new directory and then initialize a git repository within that directory. Git will then allow you to keep track all the files in that directory with version control.

# Create a new directory
mkdir test
# Switch to that directory
cd test
# Initialize a new git repository
git init

That’s it! This directory is now ready for version control using git. This is useful if you are creating new files from scratch. You can also push newly tracked files such to a remote repository hosted on Github. The steps are the same as we saw for repositories cloned from Github.

Git your engines ready!

Github Primer Quiz

Cybersecurity First Principles Reflections

Developers often design Github repositories, to be self-contained modules. These modules are then put in or taken out of a bigger project. During build time these components are composed to create an integrated system. This strategy facilitates Modularization. Following this principle allows globally distributed teams to collaborate and locate faulty components.

Finally, Github repositories separate source code from other resources. This separation allows long term archival and maintenance of a codebase, separate from its dependencies. Domain Separation enables the management of source code versions that target different products and operating environments.


Additional Resources


Lead Author




Nebraska GenCyber Creative Commons License
is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Overall content: Copyright (C) 2017-2018 Dr. Matthew L. Hale, Dr. Robin Gandhi, Dr. Briana B. Morrison, and Doug Rausch.

Lesson content: Copyright (C) Robin Gandhi 2017-2018.
Creative Commons License
This lesson is licensed by the author under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.