Git & GitHub Copy

PART 1 : Intro


Before moving on to this section, you must feel comfortable working with the terminal, be able to execute basic commands and manipulate files and folders using command line utilities like cd, ls, touch, rm, etc.

Learning Objectives

  • Understand what Git and GitHub are and explain the differences between the two.
  • Understand the differences between Git and a text editor in terms of what they save and their record keeping.
  • Understand why Git is useful for an individual developer and a team of developers.
  • Explain what Version Control is


Watch this video to learn about the history of Git and GitHub.

Duration: 5 minutes

What’s the Difference between Git and GitHub?

Duration: 2 minutes

Duration: 4 minutes

A Detailed Overview

Let’s start with one of our recorded sessions about Git & GitHub

Officially, Git is a version control system. Git is like a really epic save button for your files and directories.

When you save a file in a text editor such a .doc document you only save a record of all the words in a document as a single file. So you have access to that record only unless you make many duplicates of the same file. However this is difficult to remember and it is inefficient.

On the other hand when you save in Git, Git records differences in the files and folders. Most importantly keeps a historical record of each save. This is really handy since it enables you to review how the code works and easily go back to previous saves. Therefore you have the ability to look or restore file states from the past. In addition, Git allows you to push your project to GitHub for sharing and collaborating with other developers.

So Git works on our local machine, whereas GitHub is a remote storage facility on the web. It is essential to learn Git because in Git and Github are used from many developers to showcase their work. Having a portfolio of projects on Github is really important because it is a proof to future potential employers as to what you can do.


Before moving on, we should familiarize ourselves with the basic terms of Version Control and Git.

Download this Cheat Sheet (PDF), take a first look at each term and make sure to keep this file open while you go through the Git lessons, as you will need to come back to this terms sheet quite often.

Study & Practice Time

Take a 5 to 10 minute break before diving into the next video, as you will not only be learning about the basics of Git and version control, but you will also be practicing these concepts on your own Git repository.

Although the video duration is close to 15 minutes, this session will probably take more than 1 hour (or even more), since you will be practicing along with Colt Steele.

We suggest that you run the commands through the integrated terminal of VSCode. (Tip: Press Ctrl+J to open/close the terminal while in VSCode)

Duration: 16 minutes

Knowledge Check

This section contains questions for you to check your understanding so far. If you’re having trouble answering the questions below on your own, clicking the small arrow to the left of the question will reveal the answers.

What kind of program is Git?
    • Git is a version control program.
What are the differences between Git and a text editor in terms of what they save and their record keeping?
    • A text editor can only make and save changes to a file.
    • Git tracks changes to the files and their contents over time.
Does Git work at a local or remote level?
    • Git works on a local level. Any changes you make are saved locally with Git.
Does GitHub work at a local or remote level?
    • GitHub works on a remote level. You must push your local changes (using Git) to Github.
Why is Git useful for an individual developer?
    • Git is useful for creating snapshots of your work. If you realize halfway through that you’ve messed up, it’s much easier to reset.
Why are Git and GitHub useful for a team of developers?
    • Git and GitHub are useful for teams because they can merge code together. A developer can work on one part of the code while a second developer works on another part. They can then use Git and GitHub to easily combine their changes.

PART2 : Installation

As already mentioned Git and GitHub are essential tools for every developer. So now let’s follow the next steps:

  1. Install Git
  2. Configure Git and GitHub
    1. Setup Git
    2. Create an SSH Key
    3. Link Your SSH Key with GitHub
    4. Testing your key

Step 1: Install Git

First step is to install Git. Click the Operating System you have chosen below:

Official Git Installation Guide

Step 2: Configure Git and GitHub

Step 2.1: Setup Git

Second step is to setup git. In order for Git to work properly, we need to let it know who we are so that it can link a local Git user (you) to GitHub. This is important because when we are working on a team, this allows other people to see what you have committed and who committed each line of code.

The commands below will configure Git. Be sure to enter your own information inside the quotes (but include the quotation marks)!

git config --global "Your Name"
git config --global ""

To enable colorful output with git, type

git config --global color.ui auto

To verify things are working properly, enter these commands and verify that the output matches your name and email address.

git config --get
git config --get

Step 2.2: Create an SSH Key

An SSH key is a cryptographically secure identifier. It’s like a really long password used to identify your machine. GitHub uses SSH keys to allow you to upload to your repository without having to type in your username and password every time.

First, we need to see if you have an SSH key already installed. Type this into the terminal:

ls ~/.ssh/

If a message appears in the console containing the text "No such file or directory", then you do not yet have an SSH key, and you will need to create one. If no message has appeared in the console output, you already have a key and can proceed to step 2.3.

To create a new SSH key, run the following command inside your terminal. The -C flag followed by your email address ensures that GitHub knows who you are.

Note: The angle brackets (< >) in the code snippet below indicate that you should replace that part of the command with the appropriate information. Do not include the brackets themselves in your command.

Let’s see an example. If your email address is, then you would type ssh-keygen -C You will see this convention of using angle brackets to indicate placeholder text used throughout this curriculum and other coding websites, so it’s good to be familiar with what it means.

ssh-keygen -C <youremail>
  • When it prompts you for a location to save the generated key, just push Enter.
  • Next, it will ask you for a password; enter one if you wish, but it’s not required.

Step 2.3: Link Your SSH Key with GitHub

In this step we will need to let GitHub know what our SSH key is so that we can push our code without typing in a password every time.

So now we will navigate to where GitHub receives our SSH key.

  1. Login to GitHub
  2. Click on the profile picture in the top right corner
  3. Click on Settings in the drop-down menu.
  4. Click SSH and GPG keys on the left hand side
  5. Click the green button New SSH Key in the top right corner.
  6. Name your SSH key something that is descriptive enough for you to remember.
  7. Leave this window open and proceed to the next step.
  8. Now we need to copy our public SSH key by using the cat command. This command will help us read the file to the console.
  9. Note that the .pub file extension is important in this case.
cat ~/.ssh/
  1. Highlight and copy the output, which starts with ssh-rsa and ends with your email address.
  2. Go back to GitHub in your browser window and paste the key you copied into the key field.
  3. Lastly click Add SSH key.

You’re done! You’ve successfully added your SSH key!

Step 2.4 Testing your key

In this step we will test our SSH key. Follow the directions in this article from GitHub to verify your SSH connection. If the output doesn’t correctly match up, then try going through these steps again or come to Discord to ask for help.


You have successfully completed the installations section.

You probably felt like you were in way over your head, and you probably didn’t understand much of what you were doing. That’s 100% normal. Hang in there. You can do this! And we’ve got your back.


In this lesson, we will see some basic commands that are very useful not only to manage your projects but also to upload your work onto GitHub. These commands are used very often and that’s why we refer to them as the basic Git workflow. So once you have learned and mastered these commands you would be more than half away done mastering the entire Git!

Learning Objectives

  • Understand how to copy an existing repository from Github onto your local machine.
  • Describe the two-stage system that Git uses to save files.
  • Understand and explain how to upload your work to GitHub using Git.
  • Understand and explain how to check the status of your files and how to view your commit history.


Watch the next video by Corey Schafer for a great overview of some basic Git commands.

Git Commands Cheatsheet

Now we will see a list of the most commonly used Git commands. We advise you to bookmark this page and also try to familiarize yourself with the commands. Eventually you will remember them all.

  • Commands related to a remote repository:
    • git clone or git clone
    • git push origin main
  • Commands related to workflow:
    • git add .
    • git commit -m "A message describing what you have done to make this snapshot different"
  • Commands related to checking status or log history
    • git status
    • git log

The basic Git syntax is program | action | destination.

For example,

  • git add . is read as git | add | ., where the period represents everything in the current directory;
  • git commit -m "message" is read as git | commit -m | "message"; and
  • git status is read as git | status | (no destination).


Although you might have watched and read all the assignments listed above you might still not feeling very comfortable using Git. Don’t worry if that’s the case. Git is something you learn and understand better as you use it.

For this reason in our next lesson we will see a project that will walk you through the entire Git workflow. This process is the same process you would use in a real project as a web developer.

Don’t worry if some of the commands are not sticking in your memory yet. The important thing that you need to get from this lesson is the basic workflow. The rest of the commands will be learned as you use them in future projects.

Check Your Knowledge

Now it is time to check your knowledge and your understanding of this lesson. If you stuck in a question just click the small arrow to the left and an answer will be revealed.

Which Git command should we use to get a full copy of an existing Git repository from Github?
    • We should use the git clone<your-github-username>/<your-repository-name> command to clone a GitHub repository onto our local machine.
Which Git command should we use to check the status of our files?
    • We should use the git status command to see any changes made since our last commit.
Which Git command should we use to track files?
    • We should use the git add command to track files.
Which Git command should we use to commit files?
    • We should use thegit commit command to commit tracked files.
Which Git command should we use to view our commit history?
    • We should use the git log command to view our commit history.
Which Git command should we use to upload projects onto GitHub?
    • We should use the git push command to send our commit to GitHub.
Describe the two-stage system that Git uses to save files.
    • A save in Git is divided into two terminal commands: add and commit. The combination of these two commands gives you control of exactly what you want to be remembered in your snapshot.
    • Staging: With Git, you can select the changes you want to save with git add. For example let’s say you have a project that contains multiple files and changes have been made to several files. If you want to save some of the changes you have made and leave some other changes to continue working on them then you will use git add.
    • Committing: Thecommit is actually resulting in a snapshot. For example, let’s say that you want to commit a file named Then you need to type git commit -m "Add". The -m flag stands for “message” and must always be followed by a commit message inside quotation marks. In this example, the commit message was "Add".
What is the word origin means in the git push origin main command?
    • The word origin in Git is a placeholder name for the URL of the remote repository. Once you clone a repository Git sets up the origin by default. Therefore, we can use origin to access the remote repository without having to enter a full URL every time. We can also have multiple remotes for a repository by giving each a unique name.
What is the word main means in the git push origin main command?
    • The word main in Git is the branch of the remote repository we want to push our changes to. Although you may not be familiar with branches yet, the main thing to remember is that main is the official branch in your projects where production-ready code lives.

Additional Resources

Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land., Tom Preston-Werner, author of The Git Parable

"The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git.

The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you."

Download and read the The Git Parable

Reading time: 30 to 60 minutes.

This section contains helpful links to other content. It isn’t required, but you should consider it supplemental if you need to dive deeper into Git and Version Control.

Duration: 12 minutes

Live Session (optional)

Watch the following live session that was recorded on 23/09/2020 to understand more about the basic concepts of Git and walk yourselves through some basic examples.

Part I | Duration: 1h 33m

Part II | Duration: 1h 30m

Part III | Duration: 1h 24m

Leave a Reply