Thinking in Git


  • Emily Dunham
  • edunham on
  • @qedunham


Git is the most popular source code management and version control system in the open source community. Its complexity and power make it the best choice for most projects, while simultaneously giving it a daunting learning curve for newcomers. This talk will assume no background knowledge of version control, and will teach the basics of Git and GitHub in order to give you an accurate mental model of what the tool does, and help you fix mistakes then ask the right questions if you run into problems using it later.


  • How to look at software development
  • What’s Git?
  • Essential Git concepts & commands
  • GitHub
  • Demo!


You won’t memorize all the commands in 2 hours but this will help you ask the right questions.

Thinking about Software Development

  • Changing files
    • Some changes manual, other changes automatic

    • Changes for different reasons
      • Add feature, fix bug, test idea
      • Sometimes have several reasons at once, want changes separate

Why version control?


How do you track changes?


Goals of Distributed Version Control

  • Get the same file out that you put in
  • Work in parallel with others
  • Recombine individual work into one project
  • Track and quantify changes over time

Using Git


We’re going to talk about a lot of commands now.

Don’t be afraid. Don’t expect to know everything at first.

These slides are online; the link will show up again at the end.

Setting Up

  • Tell Git who you are:

    $ git config --global "John Doe"
    $ git config --global
  • You’ll need SSH keys later
    • ssh-keygen -t rsa -b 2048, or
    • ssh-keygen -t ecdsa
  • Install Git (also tk and tcl if you want the GUI)

  • Set preferred editor
    • export GIT_EDITOR=vim in ~/.bashrc or equivalent
  • Pick a project to work on


The name and email you tell Git will be visible to everyone you share your commits with. If you use a public GitHub repo, that’s the entire world.

ECDSA – elliptic-curve digital signature algorithm – gives much smaller keys with comparable security

GitHub can handle ECDSA, GitLab only does RSA as of 5.1.0


You can time travel through the history of any project!


This assumes that you have some number of projects you work on, each one has a history of changes, and those histories are tracked separately. A repository is the basic unit of a directory whose changes we want to track.

What’s a repository?


Database of snapshots of your code

Universe whose history you can travel through

Getting a repo

$ git init # Make a brand new repo

$ git clone <git clone url> # Start with a copy of another


Looking at a repo

$ ls .git/

$ git show
fatal: bad default revision 'HEAD'
# To be expected with nothing in the repo

$ git show
fatal: Not a git repository (or any of the
       parent directories): .git
# not in a repo

$ git log

Undo repository creation


This deletes your history. Only do it if you really want to stop having a Git repo here.

$ rm -rf .git


What if you had to publish every change as soon as you made it?

How Git sees your project

Unstaged | Staged | Committed



It would be simpler to understand the system if we only let you commit one file at a time, but it’s more important to have total control of what changes go into what commit.

Git gives you a staging area where you can get a set of changes just right, before setting them in stone.


You decide exactly where time travelers are allowed to land.

What’re staged changes?

  • Think “backstage”, changes “waiting in the wings”
  • Files or parts of files can be added or removed

Staging changes

$ echo "hello Great Wide Open" > foo
$ git add foo

Looking at staged changes

$ touch bar
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..."
   to unstage)
    new file:   foo
    Untracked files:
      (use "git add <file>..." to include
       in what will be committed)
$ git commit --dry-run


  • Keeping uncommitted changes
$ git rm --cached foo
  • Go back to the latest committed version
$ git reset HEAD foo


Time travelers get some signs and instructions when they arrive


Staging changes is all about deciding exactly what state it should be easy to go back to. Creating a commit adds some useful metadata to a snapshot of your repository.

Thinking about snapshots

  • Changes to a file plus pointers to unchanged files
  • Each snapshot knows the state of all tracked files
  • More efficient than just copying

What’s a commit?

snapshot of changes, author, date, committer (can differ from author), parent commit


Making a commit

$ git commit
$ man git-commit
-a, --all
-i, --interactive
--date=<date> (see DATE FORMATS in man page)
-o, --only
-S, --gpg-sign


-o is for only files from command line disregarding the stash Specifying file names disregards staged changes, plus stages all current contents

Looking at commits

# details on latest or specified
$ git show

# Summary of recent, or a range
$ git log

$ man gitrevisions # ranges

What about commits per file?

$ git blame <file>

Commit display options

$ git show

$ git show --oneline

# see PRETTY FORMATS section of
$ man git-show

# Check the GPG signature
$ git show --show-signature

# Want a GUI?
$ gitk


# just one file
$ git checkout <commit> <filename>
$ git add <filename>
$ git commit -m "i put that file back how it was"

Or undo the whole commit

$ git revert <commit to revert to>


next: remotes Reverting makes a revert commit. Reversability > hiding mistakes


Time travelers get a list of especially interesting locations to visit

What’s a tag?

  • Marker attached to a specific commit
  • Typically used for version or release number

Adding a Tag

$ man git-tag
$ git tag -m <msg> <tagname>

Default is lightweight tag – just a reference for SHA-1 of latest commit

Pass -s or -u <key-id> to GPG-sign

Looking at Tags

# List all available tags
$ git tag

# List tags matching regex
$ git tag -l 'regex'

# I want this version!
$ git checkout <tag name>


$ git tag -d <tagname>

# And remove it from a remote repo
$ git push origin :refs/tags/<tagname>


You can work on separate sets of changes that don’t affect each other

What’s a branch?


A parallel path of development, starting from a commit that’s in the tree


Point out why the arrows are “backwards”

Making a branch

# track remote branch by default if one matches
$ git checkout -b <branchname>

# Shorthand for:
$ git branch <branchname>   # create
$ git checkout <branchname> # check out

# Pushing a branch to a remote
$ git push <remotename> <branchname>

Looking at branches

$ git branch

$ git show <branchname>



GitHub’s “network” graph and gitk are good for this


# delete only if fully merged
$ git branch -d

# Delete, I Don't care what I lose
$ git branch -D

# delete remote branch
$ git push <remotename> :<branchname>


Someone else could work on the same repo in a parallel universe


Whenever you get multiple people working on the same project, they’ll want to make different changes and then bring them back together. To do this, Git needs to let history continue in two different directions and then bring the changes from each back together.

What’s a remote?


Another clone of more or less the same repo

(remember when we cloned to get a copy?)


Adding a Remote

$ man git-remote

$ git remote add <name> <url>


Looking at Remotes

$ git config -e

# OR

$ git remote show <name>

From one of my git configs...

[remote "origin"]
  url =
  fetch = +refs/heads/*:refs/remotes/origin/*
[remote "edunham"]
  url =
  fetch = +refs/heads/*:refs/remotes/edunham/*


Do you prefer text editor...

$ git config -e
# delete or change remote

... or commands?

$ man git-remote
$ git remote rename <old> <new>
$ git remote remove <name>


“Undoing” push to remote is... trickier next: tags

What’s a merge?

  • Brings changes from one branch to another


“a group of developers is called a merge conflict”

Making a Merge

# Branch you're changing
$ git checkout mywork

$ git merge master

# Merge conflicts?
$ git status
    On branch mywork
    You have unmerged paths.
      (fix conflicts and run "git commit")



Merge Conflicts

<<<<<<< HEAD
This content was in mywork but not master
This content was in master but not mywork
>>>>>>> master
  • Replace all that stuff with what the content should be.
  • git add the file.
  • Check that you’ve got everything with git status, then commit.
  • Or consider git mergetool for an interactive option.

Looking at Merges

$ git diff <commit before> <merge commit>

# before merging, see changes
$ git log ..otherbranch
$ git diff ...otherbranch
$ gitk ...otherbranch


$ git merge abort
$ git reset --keep HEAD@{1}

What’s a rebase?


Changing history. Means others will have to force pull.


Don’t do this unless you know what you’re doing... But here’s how to know what you’re doing.


$ git rebase -i <commit range>
                # last 4 commits

# Oops I forgot to pull
$ git pull --rebase

Looking at the rebase

# Rebase 1a20f51..147c812 onto 1a20f51
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
# These lines can be re-ordered; they are executed from top to bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.


Make sure you have your git editor set!


I should never have done that

$ git reset --hard ORIG_HEAD

I’m stuck in a broken rebase, get me out

$ git rebase --abort



Not Exactly Git


  • Less distributed paradigm
  • Git never told us who to trust
  • Git doesn’t care who you are

Watch Linus’s talk for more detail

Getting Started

  • Use the same email as your git config

HTTP vs SSH Clones

Permission denied (publickey).
fatal: Could not read from remote

Please make sure you have the
correct access rights and the
repository exists.

HTTP clone prompts for username and password

SSH clone uses key from your account


  • Parallel repos (or possibly divergent)

Pull Requests

  • Formalizes “Hi, please merge my changes”

Annoying Tricks

  • Branches keep adding their content to PRs
  • Group management and access rights
  • No project license required


Extra Features

  • Wiki
  • Gist
  • Issue trackers
  • Graphs
  • Repo descriptions and automatic README display

Continuous Integration


Playing Well With Others

  • Change history locally, never globally
    • Never force push (unless you have to)
  • Focused commits with clear commit messages

  • Follow project standards for branching, tagging, etc.



  • Emily Dunham
  • edunham on
  • @qedunham

Other Stuff


$ git checkout branch

point HEAD at the tip of the specified branch

$ git checkout <revision> file


$ man gitrevisions
  • Commit hash

  • Refname
    • HEAD^n is nth parent of tip of current branch
    • branchname~n is nth generation ancestor of that branch
  • Regex on commit message * :/broken

  • revision:path

git bisect

Binary Search:

git bisect start
git bisect bad <commit>
git bisect good <commit>
git bisect next
git bisect reset <commit>

git cherry-pick

$ git checkout <branch that needs special commit>
$ git cherry-pick <special commit from another branch>

git format-patch

$ git format-patch origin/master
# I wonder what this patch does
$ git apply --stat 0001-first-commit.patch

# Let's merge!
$ git apply 0001-first-commit.patch

# Does your project use signed-off-by?
$ git am --signoff < 0001-first-commit.patch