Thinking in Git
Hi
- Emily Dunham
- edunham on irc.freenode.net
- edunham@edunham.net
- @qedunham
- talks.edunham.net/gwo2016/git
Note
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.
Agenda
- How to look at software development
- What's Git?
- Essential Git concepts & commands
- GitHub
- Demo!
Note
You won't memorize all the commands in 2 hours but this will help you ask
the right questions.
Thinking about Software Development
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
Note
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
Note
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
Imagine...
You can time travel through the history of any project!
Note
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
# git@github.com:organization/reponame.git
# https://github.com/organization/reponame.git
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
Warning
This deletes your history. Only do it if you really want to stop
having a Git repo here.
Imagine...
What if you had to publish every change as soon as you made it?
How Git sees your project
Unstaged | Staged | Committed
Note
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.
Imagine...
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)
bar
$ git commit --dry-run
Undo?
- Keeping uncommitted changes
- Go back to the latest committed version
Imagine...
Time travelers get some signs and instructions when they arrive
Note
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
$ man git-commit
-a, --all
-i, --interactive
--reset-author
--date=<date> (see DATE FORMATS in man page)
--allow-empty
--amend
-o, --only
-S, --gpg-sign
Note
-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?
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
Undo?
# 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>
Note
next: remotes
Reverting makes a revert commit.
Reversability > hiding mistakes
Imagine...
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>
Undo?
$ git tag -d <tagname>
# And remove it from a remote repo
$ git push origin :refs/tags/<tagname>
Imagine...
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
Note
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>
Note
GitHub's "network" graph and gitk are good for this
Undo?
# 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>
Imagine...
Someone else could work on the same repo in a parallel universe
Note
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 = git@github.com:monte-language/monte.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "edunham"]
url = git@github.com:edunham/monte.git
fetch = +refs/heads/*:refs/remotes/edunham/*
Undo?
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>
Note
"Undoing" push to remote is... trickier
next: tags
What's a merge?
- Brings changes from one branch to another
Note
"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")
Note
COMMIT OR STASH CHANGES FIRST
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
Undo?
$ git merge abort
$ git reset --keep HEAD@{1}
What's a rebase?
Changing history. Means others will have to force pull.
Note
Don't do this unless you know what you're doing... But here's how to
know what you're doing.
Rebasing
$ git rebase -i <commit range>
HEAD~4
# 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.
Note
Make sure you have your git editor set!
Undo?
I should never have done that
$ git reset --hard ORIG_HEAD
I'm stuck in a broken rebase, get me out
GitHub
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
https://github.com/join
- Use the same email as your git config
HTTP vs SSH Clones
Permission denied (publickey).
fatal: Could not read from remote
repository.
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
Forking
- 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
Additional GitHub tricks
- .github/CONTRIBUTING.md
- .github/ISSUE_TEMPLATE.md
- .github/PULL_REQUEST_TEMPLATE.md
- README
- Display test results on PRs
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.
Questions?
- Emily Dunham
- edunham on irc.freenode.net
- edunham@edunham.net
- @qedunham
- talks.edunham.net/gwo2016/git
Other Stuff
checkout
point HEAD at the tip of the specified branch
$ git checkout <revision> file
gitrevisions
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
0001-first-commit.patch
0002-second-commit.patch
# 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