Session 3 More Git and Intro to GitHub


By the end of this session, you will be able to:

  • practice pseudocoding approach and implementation
  • create your own repository on GitHub
  • push local changes to a remote
  • fork and clone an existing repository


  • Housekeeping, Feedback + Goals
  • Psuedocoding Practice
  • GitHub
  • Wrap Up


  • Notebook
  • Writing instrument
  • Laptop
  • Headphones & mic
  • Zoom permission to share screen for breakout sessions

Housekeeping, Wins/Follow-Ups, and Goals


  • Most common answer to git question from survey: “I can name the steps of the git workflow and can put them in practice (using a reference).”
  • This is expected, and we use references as programmers on the job all the time, at some point it’ll be muscle memory
  • Great job asking and answering each others questions in the slack channel!


  • We’re in the process of leaving feedback on everyone’s homework, be sure to check your gists!
    • Suggestions and feedback are there for your benefit
  • Make sure that you’re checking Slack at least once a day
  • Be sure to stay at your home (root) directory or below

Intros and Review

Person with their birthday coming up next starts.

  1. Introduce yourself: name, pronouns
  2. What metaphor would you use to describe the git staging area?
  3. Review the following Git commands. What is the purpose of each one?
    • git init
    • git add
    • git commit -m
    • git status
    • git diff

Have extra time? Share helpful resources you've come across.

Psuedocode Practice: Counting Sheep

Look at this collection of data…

[false, false, true, false, false, true, true, false, false, false]

Each true represents a piglet.

Each false represents a sheep.

Write a function that can count the number of sheep in the collection.

See example below (remember, it is OK if you don’t understand exactly what is happening in the code!)

[false, false, false] >>> returns "Oink! Oink! Only little piglets here!"
[true, false, false] >>> returns "There is 1 sheep in the barn."
[true, true, false] >>> returns "There are 2 sheep in the barn."

Write pseudocode to explain how you would approach finding the number of sheep in the barn - remember, the smaller you can break up the “steps” the better!

On your own

  • How can you break this problem down into smaller chunks or sub-problems?
  • What steps are needed to get from the initial data (input) to the desired end result (output)?
  • Are there any “edge” cases you need to check?

In groups

  • In groups, take turns sharing your pseudocode
  • As a group, come up with a Team Solution that can borrow parts from all the different group members!

Share Out + Review

Git Review

Let’s talk once more about this Git diagram.

Git Workflow Diagram

We’ll start by repeating the group git exercise from the last session. This may seem repetitive, but each time you practice, you’ll gain muscle memory and procedural understanding.

Today’s driver will be the person who was born closest to the state of Indiana. Everyone else will be navigators. Driver: remember not to type anything that has not yet been brought up by a navigator and discussed in the group.

The driver will be the person typing the commands, but the navigators should be the ones who brainstorm what comes next or what to type. In addition to naming the steps, discuss why you are doing each step, or what exactly is taking place in each step.

Remember: If you feel comfortable with git, your job is to hone your explanation and communication skills. Many companies in the industry place far more weight on these professional skills than on being a technical superstar.

Try It: Git Review

As you and your group walk through the git review below, it might be a good idea to have Session 2's Git notes open.

  1. Before we do this, make sure the driver is in the home directory by typing cd
  2. Create a new directory called session_3_git_practice. Inside of that directory, create three files called,,
  3. Initialize git in the session_3_git_practice directory.
  4. Before you check the status, predict what the output will be. Then, run the command to check the current status.
  5. Add to the staging area.
  6. Make your first commit in this directory. What should the commit message here be?
  7. Before you check the status, predict what the output will be. Then, check the current status.
  8. Add to the staging area.
  9. Make your second commit in this directory. This commit should include both files from the previous step. What should the commit message here be? Why? What conventions have we talked about?
  10. Use atom to add the names of two separate coding languages to You may Google "programming languages" if you can't think of any.
  11. Before you check the status, predict what the output will be. Then, check the current status.
  12. Before you check the difference between your last commit and what the file looks like now, predict what the output will be. Then, check the diff.
  13. Add the changes to the staging area.
  14. Before you check the status, predict what the output will be. Then, check the current status.
  15. Commit the changes using a properly formatted commit message.
  16. Before you check the status, predict what the output will be. Then, check the current status.
  17. Repeat steps 10-16 again, adding the names of some programming terms and some git terms to the respective files.
  18. Add and commit the changes to these two files together with a properly formatted commit message.

Finished before time is up? Repeat, but choose a different driver this time.


Git is not the same as GitHub. They work together, but they are separate tools. Git allows us to track versions of our work on our local computers. GitHub is an online git repository hosting service. A repository (or repo) is at its core, a place where your work and commits are stored.

Other alternatives to GitHub include GitLab and BitBucket, among others. GitHub (and these other services) also makes it easy for teams that use git to collaborate on the same codebase.

During Mod 0, we will not be exploring the collaborative functionality of GitHub. We’re going to stick to learning the basic functionality of GitHub.

Let’s first discuss this diagram:

Github Diagram


origin: refers to the URL where the code is hosted on GitHub. Each repository has its own origin (own URL).

git pull: means download all of the changes and updates on the remote GitHub repo that I don’t currently have on my local repo. You would use git pull after a teammate makes a change to the code, and you want to bring those changes into your own code.

git push: this is how you share/upload the changes you made to your local repository on GitHub.

This diagram shows how GitHub can be used as a collaboration tool:

Collaborative Github Diagram


Let’s take a look at an example of a repo on GitHub: FreeCodeCamp

Creating a Remote Repo on GitHub

Watch and take notes while we walk through how to add a remote to your local repository. This assumes we already have a repository initialized with git locally.

  1. Visit
  2. Click the plus button in the upper-right corner of GitHub and select “New Repository” from the dropdown.
  3. Give your repository a name, and don’t worry about adjusting any of the other settings for now.
  4. Scroll down and click “Create Repository”
  5. Scroll to …or push an existing repository from the command line
  6. Paste the lines listed, one at a time, in your terminal. Make sure to follow instructions for SSH
  7. Refresh Github. Tada! Your project is there.

Try It: Adding a Remote

1. Create a new repository on GitHub called git_homework.

2. In your terminal, navigate to your git_homework directory from session 2's homework.

If for some reason you don't have this directory then use the mkdir command to create git_homework. Then use touch to create a file Then run git init. Only do this if you don't already have a git_homework repo.

3. Add the remote to your local repository, then push your changes to GitHub.

Making Additional Changes and Pushing to GitHub

Watch and take notes while we walk through how to continue making changes and pushing those changes to GitHub.

Try It: Full Git Workflow

In your breakout rooms, everyone will complete the steps below synchronously, but on your own projects. Use each other as resources and sounding boards. Don't hesitate to click "share screen" if there's something you want your team to look at!

If you get really stuck, you can click "ask for help" and we'll pop into your room.

  • Add a few new thoughts to your file.
  • Save your file using the shortcut command + s.
  • Go back to your terminal.
  • Use commands to add and commit your new changes. Be sure to use git status to check your status, and make sure your commit message is properly formatted.
  • Push your new changes to GitHub.
  • Refresh the page to make sure the new changes appear.
  • Repeat the above steps, but this time, remove one of the thoughts from your document, then add, commit, and push your changes.

Finished? Get to know your breakout room classmates better: What are they trying to get better at in life? What book would the recommend that everyone read at least once in life?


What is Forking?

Forking allows you to copy someone else’s project while still keeping a reference to the original. To fork an existing project, you just click the fork button, which will make a copy of all of the code and directory structure to your own GitHub account.

You can tell if something is a fork because it will say “forked from [original repo name]” underneath the title.

Once you’ve forked a repo, click the green “Clone” button to get the URL to clone.

git clone <insert URL here>

If you fork, clone, make changes, and push to origin, it will work because it’s pushing to your forked origin (YOUR account), not the original repository (ORIGINAL CREATOR’s account). To push those changes:

git push


git push origin main

(In our case today, both commands will do the same thing)

Things to Note: Cloning with Git

  • Never clone a remote repository within a preexisting Git repository. If you watched the video for modifying your .zshrc, then you will see main if you're already in a git repository.
  • After cloning a repository, remember to cd into the directory you just cloned to your machine before running commands. If you cannot remember what the directory is called then runls after cloning to see the contents of your current directory.
  • There is no need to run git init within a repository that you cloned down to your local machine. Remote repositories that you clone to your local machine have already been initialized by git. You only ever need to run git init when you've created a repository locally from scratch. If you mess this one up, it's not going to cause any problems; it's just unnecessary.
  • Don't use "Initial commit" as your commit message for a cloned repository. Whoever made the repository already did that. You only need "Initial commit" when you make a new repository for yourself.

Try It: Forking

  1. Fork the Best Animals repository.
  2. Clone your fork using your terminal.
  3. Open up the project in your text editor (atom).
  4. Add a few animals to the file.
  5. Add and commit your changes.
  6. Push your changes to the origin (which is your fork).

Done? Repeat steps 4-6 with another animal file.

Remote Collaboration Using GitHub: A Primer

The workflows we outlined above are common patterns you will follow when working on projects for yourself. However, the real “magic” of using GitHub is it allows you to work collaboratively with teammates on the same repository/project.


When working on collaborative projects, it is best for each group member to be working on their own branch. Think of a branch as a part of the overall project (tree), but a branch can go in it’s own direction. Developers will often use a separate branch to work on a particular piece of functionality, usually referred to as a feature. This allows multiple developers to be working on separate pieces of an application simultaneously!

Pull Requests + Code Reviews

When a developer has finished their feature, they will push their feature branch up to GitHub for their teammates to review. This process is known as making a pull request - essentially asking the other developers on the team to “pull down” the new code from GitHub, test it’s functionality, and leave any feedback or requests for changes. Typically, teammates should review:

  • Does the code meet the quality standards as outlined by the team/organization?
  • Does the code “play nice” with the other features of the application? Or does it cause bugs?
  • Are there places that can be refactored or the code improved to make it easier for other developers to build on top of it?

Pull requests are essentially requests to merge the new changes from the feature branch to the project’s main branch. Once everyone from the team has had a chance to review the code, request adjustments, and fix any merge conflicts (issues that the new code causes with older code) - they can either approve or reject the request.

  • Approving the request will allow the new feature to be merged into the main branch of the project
  • Rejecting the request will prevent the new feature from being merged into the main branch of the project

Typically, you do not want to merge your own pull request - this would prevent anyone else from reviewing it and giving valuable feedback!

Why Does This Matter?

  • The pull request process allows for all team members to view, test, and provide feedback on anyone’s code
  • Hiring managers will often look at your code review comments and pull requests on your projects to gauge your ability to collaborate in a remote environment
  • This is the one of the first tools you will learn to use that will help you prevent “shipping” (approving) unstable code in your production environemnt (the “public” version of your app)


Business as usual. Reach out on slack if you’re stuck!