Intro to Git and Github


What we will cover in this workshop

  • What is version control and why should we care?
  • Basics of Git: the essential commands
  • GitHub (or, a little Git between friends)

If it seems hard, it's because it is

Git comic on XKCD
"The version control system that was ... designed to make you feel less intelligent" (source)

Installation and Setup

Install Git

Download latest version of Git

Setup steps on GitHub

Installation and Setup

Setup name and email in gitconfig

$ git config --global "Your Name Here"
# Sets the default name for Git to use when you commit

$ git config --global ""
# Sets the default email for Git to use when you commit

$ git config --list

Setup: Setting the default text editor

By default Git is set up to use Vim as the text editor.

(esc + :q or :q! to get out of Vim)

Follow these instructions to change your default text editor to whatever you prefer.


Let's do this thing!
Instructions on GitHub for reference

BONUS LEVEL: Set up your GitHub account and authentication from Git.

What is version control?

Version control is a tool that allows you to...


Create anything with other people, from academic papers to entire websites and applications.

Track and revert changes

Mistakes happen. Wouldn't it be nice if you could see the changes that have been made and go back in time to fix something that went wrong?

You already manage versions of your work!

Do you have files somewhere that look like this?

You invented your own version control!

Types of Version Control Systems

Centralized Version Control

one central server with each person pushing changes to the main server

One central server, each client (person) checks out and merges changes to main server

Examples: CVS, Subversion (SVN), Perforce

Distributed Version Control

each person works on her own local copy; each copy is reconciled with the main copy on the server

Each client (person) has a local repository, which they can then reconcile with the main server.

Examples: Git, Mercurial

Why Use Git?

  • Fast! Access information quickly and efficiently.
  • Distributed! Everyone has her own local copy.
  • Scalable! Enables potentially thousands (millions!) of developers to work on single project.
  • Local! You don't need a network connection to use it. You only need a remote server if you want to share your code with others (e.g., using GitHub).
  • Branches! Keep your coding experiments separate from code that is already working.
  • Everyone has a local copy of the shared files and the history.

Git has its own Vocabulary

  • A repository is where you keep all the files you want to track.
  • A branch is the name for a separate line of development, with its own history.
  • A commit is an object that holds information about a particular change.
  • HEAD refers to the most recent commit on the current branch.

Some Basic Git Commands

  • init
  • add
  • commit
  • status
  • log
  • branch
  • checkout
  • fetch
  • merge
  • pull
  • push
  • clone

Create a Local Repository

1. Go to your home directory

$ cd
$ cd Users/username

2. Create a new "working directory" and cd into it

$ mkdir my-repo
$ cd my-repo

3. Initialize it as a local Git repository

# make sure you are in the right directory!
$ pwd
$ git init
$ git status

Add files

1. Create a new file in your new folder named kitten.txt

$ touch kitten.txt

2. Check the status of your repo with git status

$ git status

3. Tell Git to track our new file with git add

$ git add kitten.txt
$ git status

Success! The file you just added is now tracked by Git

Changes and commits

1. Open kitten.txt, add some text, and save it

$ git status

2. Stage the change and check the status

$ git add kitten.txt
$ git status

3. Commit the change with a good commit message that explains and describes what you did

$ git commit -m "First commit. Added kitten.txt to repository."


What did we just do??

How is all this different from just saving a file?
  • When we add a new file, we tell Git to add the file to the repository to be tracked.
  • This is also called staging a file. A snapshot of our changes is now in the staging area (aka the index, aka the cache), ready to be saved.
  • A commit saves the changes made to a file, not the file as a whole. The commit will have a unique ID so we can track which changes were committed when and by whom. (Good commit messages help, too.)

Look at your progress

$ git log

commit 6853adc0b6bc35f1a8ca0a6aa5e59c978148819b
Author: Your name <>
Date:   Tues May 23 16:01:22 2017 -0700

  First commit. Added kitten.txt to repository.

You are now using Git.

Give yourself a high five, like Liz Lemon.

Now try...

  • Make changes to kitten.txt and make some more commits.
  • Add another file (or image!) to your project and commit that.
  • Change more than one file at a time, and practice making commits where you stage only one file, or both files together.
  • Try the git diff command when you have unstaged changed.
  • Look at your history with git log as you add more commits (and try adding the --oneline option)

Don't forget to run git status regularly so that you can see what is happening at each stage!

The Magical Realms of Git

The Workspace

Working Tree

What you see in your editor and where you make your changes

The Staging Area

Index / Cache

A snapshot of your working tree at a particular point in development

lets you gather changes for the next commit

Your Local Repo

Your copy of a project, initialized as a Git repository

(i.e., it has a .git directory)

The Remote Repo

The shared copy of the repo that lives on a remote server

Very often this is GitHub, but it doesn't have to be.

Conventionally named origin but doesn't have to be.

It's all about the history

What should I use version control for?

Anything. But not everything.

version control ALL THE THINGS!


You decide what goes into version control.You can, and should, leave some things out.

libraries, .dotfiles, api keys...

The.gitignore file at the root of your project directory

Check out for some suggestions.

We all make mistakes

Those WERE the Droids I was looking for!

Don't worry. Git is your friend.

Undoing changes in your working copy

If you haven't added/committed yet

Open kitten.txt and make some changes or add something new. Then:

$ git checkout kitten.txt

Look at kitten.txt in your editor: your changes are gone (you've gone back to the previous commit state).

Un-staging a file

  1. In your text editor, create a new file, and name it possum.txt
  2. Switch back to your terminal.

$ git add possum.txt
$ git status
$ git reset possum.txt
$ git status

The file is removed from staging, but your working copy will be unchanged.

Undoing changes you've already staged

Open kitten.txt in your editor and add some new text.

$ git add kitten.txt
$ git reset HEAD kitten.txt
$ git status # the file has been unstaged.
$ git checkout kitten.txt
# resets the working copy to its state at the last commit

Now look at the same file in your editor again: your changes are gone, and the file is removed from staging.

Er, what if I already committed it?

Undoing committed changes

Git lets you go back to any previous commit.

Open kitten.txt and add some new text

$ git add kitten.txt
$ git status
$ git commit -m "Make a change I will soon regret making"
$ git log --oneline
# you should see (at least) two commits here at this point
# copy the short form of the hash id

Soft reset

Undoing just the commit

$ git reset --soft 53d23c4
$ git log --oneline

Notice that the commit is gone from your log, but your changes are still in your editor.

Hard reset

Undoing the commit AND the changes

$ git reset --hard 53d23c4
$ git log --oneline

Notice that the commit is gone from your log, AND your changes are removed in your editor.


blue birds on branhces

A branch is essentially another copy of your repo that will allow you to isolate changes and leave the original copy untouched. You can later choose to combine these changes in whole or part with the "master" copy, or not.

Branches are good for features!



  • Develop different code on the same base
  • Conduct experimental work without affecting the work on master branch
  • Incorporate changes to your master branch only if and when you are ready...or discard them easily

Branches are cheap!


Create a new branch called feature

$ git checkout -b feature

Add new lines to kitten.txt

$ git add kitten.txt
$ git commit -m "Adding changes to feature"
$ git log --oneline


What we just did, in picture form:


Switching branches

See all your local branches. Your active branch, the one you're "on," is marked with an *

$ git branch

Switch to master branch and look at the commit history

$ git checkout master
$ git log --oneline

Switch to feature branch and look at the commit history

$ git checkout feature
$ git log --oneline


Merge to get changes from one branch into another

Switch to master and merge changes

$ git checkout master
$ git merge feature
$ git log --oneline

Merging Branches

When you merge, you create a new commit on the branch you just merged into

What could possibly go wrong?

What is a merge conflict?

what a merge conflict looks like

You will see this in the affected file your text editor

Here are lines that are either unchanged from the common ancestor,
or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Your changes are reflected here in this section.
Their changes are here in this section, in conflict with yours.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.


Merge conflicts

Change the first line in kitten.txt in master branch

$ git add kitten.txt
$ git commit -m "Changing kitten in master"

Now change the first line in kitten.txt in feature branch

$ git checkout feature
  # open kitten.txt and change the first line
$ git add kitten.txt
$ git commit -m "Changing kitten in feature"


Merge conflicts, cont.

Merge the changes from master into the feature branch

$ git merge master #remember, you are on the feature branch here

You will be notified of a conflict. Go to the file in your editor and fix the problem. Then add and commit your edits.


The merge conflict occurred because the feature branch (which is based off of master) both had divergent histories for the same file.

The big picture

Share Your Code on GitHub

github is social coding

Git + Friends = GitHub

GitHub has over 20 million users,
and over 57 million repositories

What is GitHub for?

  • GitHub allows users to host Git repositories publicly and privately
  • Open source projects host or mirror their repositories on GitHub
  • Push your own code up for others to use or contribute to
  • Read, copy, and learn from the code in other people's repositories
  • Contribute to open source projects (like the Girl Develop It website!)


Create your first remote repository

You will need to be logged into your GitHub account to do this.

image from GitHub help pages


Create your first repository

How to create a new repository. Image from


Set up remote repo to sync with your local repo

After you click the big green button to create your repo, follow GitHub's instructions for next steps.

$ git remote add origin
$ git push -u origin master

# that -u is an option that signals that you are setting
# a tracking reference to the remote branch as the default;
# you only need to use this flag the first time

Now check out your GitHub repo online!

What can I do with a GitHub Account?

FORK a repo: Find some code you want to use and grab a copy of it.

(Then you'll also need to CLONE the repo — that is, make your own local copy of it)

PUSH to a remote repo you own: post some code you want others to see.

submit a PULL REQUEST to the owner of a repo you'd like to contribute to.



not this


If you want to use or contribute to a repository, you can fork it.

A fork is just a copy of a repository, saved to GitHub.

Let's practice forking! How to fork a repository. Image from


To get a local copy of the fork you just made, use the git clone command.

$ cd ../

$ git clone

$ cd tiny-repo
$ git remote -v


There are now THREE copies of this repo that you have access to.

the original (on Github) => upstream
your fork (on GitHub) => origin
your clone => your local repo, just like you're used to

Establishing a connection to an upstream repo

To sync your fork with the original repo, you need to add another remote named upstream

$ git remote -v
$ git remote add upstream
$ git fetch upstream
Downloads Git references not present in your local repository, but does not modify your files (think of it like getting a table of contents rather than the contents themselves)

Shared Repos

If team members are contributing to a single repo, each member of the team will want to make sure that she has everyone else's changes before pushing her own changes to the GitHub repo.

Always pull before you push!


Commit local changes first

$ git commit -m "My latest commit"
Get changes that have been pushed to the remote repo

$ git pull origin master
Git may prompt you to fix any conflicts, then commit

$ git commit -m "Fixing merging conflicts"
Now you are ready to push local changes to GitHub

$ git push origin master

Pull Requests

  • After you fork and clone a repository all pushed changes will go to your fork.
  • These changes will not affect the original [upstream] repository!
  • If you would like your changes to be incorporated into the original repo, you can submit a pull request.
  • A pull request is a GitHub feature that lets you ask the owner of the upstream repo to pull your changes in (since you don't have permission to push)

Starting a pull request

You need to do this on GitHub, not from the command line.

How to initiate a pull request. Image from

Previewing and sending pull request

How to preview and send a pull request. Image from

Managing pull requests

If you are the owner of repo, you will review and decide whether to merge in the pull requests you receive.

You can learn more from the
Github Collaborating Tutorials.

Editing pull requests

To make changes to an existing pull request, commit changes to the same branch, and push them to GitHub. They'll be added to the PR automatically.

$ git pull origin my-pr-branch
$ git commit -m "Fix typos"
$ git push origin my-pr-branch

Making multiple pull requests

Because any new commits to a branch will be added to that branch's pull request, you need to make any new, unrelated changes to a new branch.

$ git checkout master
$ git checkout -b new-feature-branch
$ git commit -m "Add a fancy new feature"
$ git push origin new-feature-branch

Be sure the new branch is based off of the master branch, and not your other working branch.

Vocabulary Recap

  • Git is version control software.
  • Github is an online community where you can collaborate with others on projects using Git.
  • A repository is a folder where you keep all the files you want to track (normally a fully encapsulated project).
  • local refers to the version of the repository on your computer/local development environment
  • fork is a copy of someone else's repository that you have
  • cloning a repo means taking it from github and putting it onto your local
  • origin refers to the version of the repository that it was cloned from (normally on github)
  • upstream: if you have forked a repo, this refers to the original parent repository

Vocabulary Recap, cont

  • A branch is the name for a separate line of development within a repo, with its own history.
  • A commit is an object that holds information about a particular change. You make commits on branches
  • HEAD refers to the most recent commit on the current branch.
  • A pull request is a means to create an approval process for merging one branch into another on Github

Git Learning Resources


Git Push Origin Hamster