Git and Github

Learning Goals

After this lesson, students should be able to:

  • explain the difference between remote and local repositories
  • Create a Git repository locally
  • Create a repository on GitHub
  • Link a local repository to a remote repository
  • Use a branching workflow with Git and GitHub

Slides

Available here

Warmup

  • What do you already know about Git/GitHub?
  • Why do we use Git/GitHub

Overview

  • Git is a version control system that we use in programming.
  • GitHub is a website that allows us to share Git repositories.
  • In order to keep our code safe we use a branching workflow that allows us to make changes to multiple files before fully commiting to those changes.

Git

What is Git?

Git is a Version Control System (VCS). It allows you to save work on your project, and reference previous states of a project if needed. Normally when we save something on our computer, the newer version overwrites the older version. This is problematic if we need to look back at an earlier version. Git solves this problem by providing you multiple save points. You can get the current version, and ANY previous version. Git’s philosophy: never lose anything.

Commits

Saving your work in git is known as committing. Even though you may change a file and hit save, you don’t actually save it to your git repository until you use the commit command. Changes can be in 3 different states:

  1. Unstaged: we have made changes but not told git that we would like to commit them
  2. Staged: we have made changes and told git that we are getting ready to commit them
  3. Committed: we have committed our changes to the repository’s log of commits. Our work is saved.

Important Git Commands

  • init - create a git repository in the current directory.
  • status - show what changes have been made. This will show changes that are staged and unstaged.
  • add <file name> - stage a change for commit.
    • ex: git add credit_check.rb
  • commit -m "<commit message>" - commit a change. Each commit requires a commit message (must be in quotes).
    • ex: git commit -m "adds search feature"

Git Workflow

Creating a Git Repository

  1. Use mkdir to create a new directory if you have not already.
  2. cd into that directory.
  3. Run git init to make that directory a Git repository.

Committing Changes

These are the steps you should take to make changes and save them to your repository.

  1. git status - make sure our working directory is clean, which means there are no changes. If there are changes, we need to figure out what to do with them, either commit them or stash them.
  2. Make changes - e.g. create or update files
  3. git status - we should see the files we changed as unstaged.
  4. git add <name of file we changed> - stage those changes for commit. We need to do this for each file we changed.
  5. git status - we should see the files we changed as staged for commit.
  6. git commit -m "short message about the changes we made" - commit the changes.

Practice!

Using the commands above:

  • Create a new directory called git_practice.
  • Make your git_practice directory a Git repository.
  • Create a file inside of that directory called README.md and add some text to that file.
  • Commit your changes
  • Make some additional changes
  • Commit those changes

Github

GitHub is a website for hosting git repositories.

The git repository on your computer is called the local repository. It is only accessible through your computer. If you are working with a partner, they cannot access it on their computer. That’s where Github comes in. When you push your repository to Github, you are creating a remote repository. It is in the cloud and collaborators can access it through the web.

Before GitHub, developers or companies configured and ran their own independent git servers, and things were much more fragmented. Now GitHub has become the de facto community standard for hosting and sharing repositories.

You certainly don’t need GitHub to use git, but its popularity and dominance, especially within the open source community, have intertwined the 2 for many users.

As you progress through becoming a more practiced git user, don’t forget that these are 2 distinct things – git provides the core technology for tracking and managing source control changes, while GitHub provides a shared location for hosting git projects.

Creating a New Repository on GitHub

In order to create a new repository on GitHub we need to visit the site and click on the green New button next to the Repositories heading on our dashboard.

Name the new repository the same as what you have named the directory that you’re working in. The other default values should be fine for our purposes.

Commands for interacting with GitHub

Once you’ve created a new repository on GitHub, you need to link that repository to your local repository. We need to add a remote.

  • remote -v - this will show you what your remote repository is configured as. This is helpful for debugging.
  • remote add <remote name> <remote url> - This adds a new remote. If you type remote -v and nothing shows up, it means you have no remotes and you will need to use this command to add one. Usually, you only need to do this once when you are setting up a project.
  • push <remote name> <branch name> - Update your remote repository to match your local repository. The remote name is almost always origin. The branch name is whatever branch you want to push to (more on branching further down). For instance, if you are working on the master branch, which is the default branch, the command would be:
    • git push origin master
  • pull <remote name> <branch name> - update your local repository with the changes made to the remote. This will be important when you are working with someone else, and you want to get the changes they made. Similar to pushing, remote name will almost always be origin. Branch name is whatever branch you want to pull from. So if you wanted to get the recent changes to master, the command would be:
    • git pull origin master
    • note: This will pull the changes in to whatever branch you are currently working in

Git workflow with Github

  1. pwd - make sure we’re in the right directory
  2. git status - double check that we have already initialized our local Git repository
  3. Create the repo on GitHub
  4. Copy the SSH address from GitHub
  5. git remote -v: this will tell us if we already have a remote repository for this local repository.
  6. git remote add origin <YOUR_SSH_ADDRESS HERE>
  7. git log make sure we have at least one commit
  8. git push origin master

To push to your remote repository

  1. Make changes
  2. git status - we should see the files we changed as unstaged.
  3. git add <name of file we changed> - stage those changes for commit. We need to do this for each file we changed.
  4. git status - we should see the files we changed as staged for commit.
  5. git commit -m "short message about the changes we made" - commit the changes.
  6. git push origin master

It is important to note that you do not have to push every time you commit. You can make several commits, and push will send all the new commits you made at once.

Practice

  • Create a new repository called git_practice
  • Add the remote to your local git_practice repository
  • Push your existing commits to the GitHub repository
  • Make additional changes to your README
  • Commit them
  • Push your changes to GitHub

Branching

If you do git status you’ll see part of the status is “On branch master”. Branches represent a line of development. The master branch is the default branch, and is typically where the code works without known bugs.

Switching to a branch is called a checkout. When you checkout a new branch, it can serve as a sandbox for development where you can make changes or experiment with a research spike without affecting the master branch. If whatever you are trying doesn’t work, no big deal; your master branch remains intact.

This link shows some helpful visuals related to git branches.

More info on branching.

Branching commands

  • branch - view a list of branches
  • branch <branch name> - create a new branch
    • ex: git branch new_feature
  • checkout <branch name> - switch to a branch
    • ex: git checkout master
  • checkout -b <branch name> - create and switch to a branch in one command
    • ex: git checkout -b new_feature
  • push <remote name> <branch name> - push to a branch. If the branch doesn’t exist in your remote, Github will create a new one for you.
    • ex: git push origin new_feature
  • pull <remote name> <branch name> - pull from a branch. Generally you want to be pushing to feature branches (branches where you’re working on code) and pulling from master.

Pull Requests

If what you did in a branch works and you want to add it to the master branch, you will merge that branch into the master branch.

Pull Requests are a Github feature that allows us to merge code from one branch into another. The name “Pull Request” can be confusing because you are actually trying to merge code rather than pull it. Some other online systems such as Gitlab call them “Merge Requests” for this reason.

Not only do Pull Requests allow you to merge branches, they allow other collaborators to look at the code you added, make comments, and review your changes BEFORE the code gets merged. They are a very powerful collaboration tool, and used extensively in the industry.

Git Workflow with Branching and Pull Requests

This is the final version of our workflow, and is what you should be doing on every project, partner or solo.

  1. git status - make sure our working directory is clean. If there are changes, we need to figure out what to do with them, either commit them or stash them.
  2. git pull origin master - Make sure you are up to date with the latest version of master.
  3. git branch <feature name> - make a new branch based on a feature you want to add. Alternatively, you can use git checkout -b <feature name> to create and checkout the branch in one command.
  4. git checkout <feature name> - Checkout the branch
  5. Make changes
  6. git status - we should see the files we changed as unstaged.
  7. git add <name of file we changed> - stage those changes for commit. We need to do this for each file we changed.
  8. git status - we should see the files we changed as staged for commit.
  9. git commit -m "short message about the changes we made" - commit the changes.
  10. git push origin <feature name> - Push your branch to Github.
  11. Repeat steps 4 - 10 until the feature is complete
  12. Put in a Pull Request (PR) to merge your branch into master.
  13. Visit GitHub and merge your pull request into master.
  14. git checkout master - Switch back to the master branch.
  15. git pull origin master - Make sure that you have the most recent changes that you made on your local master branch.

Practice

  • Check out a new branch
  • Make some additional changes to your README
  • Commit those changes
  • Push your change to the branch on GitHub
  • Visit GitHub
  • Create a pull request
  • Merge your pull request
  • Check out your master branch locally
  • Pull your changes into your master branch

Share