outline.txt

= Introduction

= Version Control

What is version control and why should you use it?

Version control:
  - every code change is a distinct entity called a commit
    it has an attached record of who made the change, when they made it, and
    why they said they made the change

Why?
  - diff: show you what you’ve changed so you can review it
  - backups: can go back to a known good state if things start crashing,
    or an idea turns out not to work
  - undo: can selectively roll back individual changes
  - history: safely delete code to keep things clean instead of commenting
    it out, knowing you can get it back later if you want
  - context: commit messages can explain design decisions, link to bug
    reports
  - merges: if you make unrelated changes to different files, the version
    control system will merge them instead
  - fast way of sharing code: syncing with someone else only requires
    transmitting recent changes, not the complete source code
  - annotate: show who originally wrote the code, or changed it recently,
    so you know can ask them for help
  - bisect: find source of bugs by checking different versions to see when
    the bug first shows up

A nice orderly way of storing and managing source code
whose only real competitor is complete chaos

- Indispensable when working with others: automatic merges
- Useful even if the only other people working on the project are past you
  and future you: the code was working 10 minutes ago. What did I just
  change?

= Version control with git

GitHub does everything we talked about, in a nice Web UI
- [Screenshots of github for everything here]
- Commit log
- Commit details
- Tags attached to commits
- Blame

To use Github, you have to use git
- Originally written by Linus Torvalds to store linux source code
Can get very complicated very quickly
- Used to use Mercurial
- Found git ridiculously complicated
- Started a job that used git
- Worked through O’Reilly book

Basic config
- name and email
- show diff in git commit screen

Walk through the basics
- git init
- git add
- git status
- git commit
  - how to cancel
  - Keep subject <= 50 chars: https://git-scm.com/docs/git-commit#_discussion
- git log to check that the change is there
- the version number is a magic, abbreviatable string called a Commit SHA
- we’ll get into that more later
If you want to use the web interface for everything:
- git remote add
- git push
- SSH keys are convenient

Working with friends
- demo giving Mike write access to something
- git pull [--ff-only] [--rebase]
- how to escape from a merge
- fixing merge conflicts

Working with strangers
- you don’t have direct write access, so make your own copy
- commit changes
- compare
- submit pull request
- be prepared to deal with jerks; this is the software industry

Getting out of trouble
- commit before doing anything that might get messy
- it’s always safe to commit your changes
- reflog
- git reset --hard

= Digging deeper

The version number is not a number
no way to assign a linear sequence of version numbers
when many people could be simultaneously making commits offline
and pushing them all to the same place

blobs, trees, and cat-file -p
using ^ to compute a commit SHA by hand for a hello-world repo

= Conclusion

Exercises:
  - Install git
  - Create a new repo locally
  - Check out the repo for this presentation on github
  - Make a change
  - Send the change in a pull request
  - Mike and I will pretend to be strangers, and will merge your PRs

  * * *

Things we’re not covering:

[ ] continuous integration
[ ] rebasing

Other ideas:

[ ] fast-import magic