Getting more from Git

Alice Bartlett
Principal Engineer, Customer Products team
@alicebartlett
Getting more
from Git

View Slide

View Slide

@alicebartlett
This talk is about Git

View Slide

@alicebartlett
I have some humble ambitions

View Slide

@alicebartlett
1. Let’s all get a bit better at Git
2. Let’s have an interesting 40 minutes

View Slide

@alicebartlett
I think we could all do better with our
Git mastery. To understand what “bad”
looks like, I have found someone to
make an example of

View Slide

@alicebartlett
Me

View Slide

@alicebartlett
Let’s look at my commits from
ten years ago…

View Slide

@alicebartlett

View Slide

@alicebartlett
This is the codebase for the FT’s web
app. It is 9 years old, and still going
strong.

View Slide

@alicebartlett
204 lines of
code added

View Slide

@alicebartlett
and the commit
message reads only:
“sqlite stuff”

View Slide

@alicebartlett

View Slide

@alicebartlett
if (false && window.history.pushState) {
…
}

View Slide

@alicebartlett
“Fixes to download”

View Slide

@alicebartlett
¯\_(ツ)_/¯

View Slide

@alicebartlett
So that is what bad looks like

View Slide

@alicebartlett
What are we aiming for?

View Slide

@alicebartlett
1. Atomic commits
2. Meaningful commit messages

View Slide

@alicebartlett
What are “atomic commits”?

View Slide

@alicebartlett
One commit per unit of change

View Slide

@alicebartlett
A style change

View Slide

@alicebartlett
A whitespace refactor
A style change

View Slide

@alicebartlett
A whitespace refactor
A bug ﬁx (and updated tests)
A style change

View Slide

@alicebartlett
A commit should be a single unit of work

View Slide

@alicebartlett
It should make sense in isolation

View Slide

@alicebartlett
Then your Git history becomes the story
of your project, added to incrementally

View Slide

@alicebartlett
The other thing is commit messages

View Slide

@alicebartlett
Update link style
User research showed that
many people did not spot
links in the copy. This
commit updates the link style
to the new underlined style
which performed better.

View Slide

@alicebartlett
// Scannable summary
// Body that
// explains
// *why*
Update link style
User research showed that
many people did not spot
links in the copy. This
commit updates the link style
to the new underlined style
which performed better.

View Slide

@alicebartlett
WHY

View Slide

@alicebartlett
Fixes to download

View Slide

@alicebartlett
Fix background download
There is a bug in the
window.history.pushState
implementation in Android Honeycomb
so always use the location hash
instead until that is fixed.

View Slide

2. What is Git
3. Tips for rewriting your Git history
1. Why should you care

View Slide

@alicebartlett
As you know, Git is a program that runs
on your computer

View Slide

@alicebartlett
You use it to manage the process of
writing code

View Slide

@alicebartlett
You use it to tell the story of your
project

View Slide

@alicebartlett
As engineers, there are lots of things we
do to manage our codebases

View Slide

@alicebartlett
1. Bikeshed over naming things

View Slide

@alicebartlett
2. Write documentation

View Slide

@alicebartlett
3. Refactor

View Slide

@alicebartlett
3. Refactor
4. Write tests
5. … etc

View Slide

@alicebartlett
None of these things are necessary to
ship a feature. But they are necessary
for helping other people understand our
code and maintain it.

View Slide

@alicebartlett
Git commit histories are part of
this picture

View Slide

@alicebartlett
Your commits, if you do them well,
oﬀer unique beneﬁts over other
ways of explaining your code:

View Slide

@alicebartlett
1. They never change

View Slide

@alicebartlett
2. They live alongside your code

View Slide

@alicebartlett
3. They’re searchable with Git grep

View Slide

@alicebartlett
4. They allow you to document your
change at the time that you made it

View Slide

@alicebartlett
4. They allow you to document your
change at the time that you made it
5. They are hosting independent

View Slide

@alicebartlett
Public Service Announcement:
Stop putting all the information
about a change in GitHub pull
requests.

View Slide

@alicebartlett
Public Service Announcement:
Stop relying on linking to tickets for
context.

View Slide

@alicebartlett
PUT IT IN THE
COMMIT
MESSAGE

View Slide

@alicebartlett
My second reason you should care about
writing good commits is: it will make you
a better software developer

View Slide

@alicebartlett
Firstly, you’ll able to debug things
quicker because your project will have a
searchable history

View Slide

@alicebartlett
Secondly, in order to write down why
you introduced a change to a codebase,
you have to actually understand why
you introduced a change

View Slide

@alicebartlett
Explaining why is an important thing to
do as an engineer — it forces you to
understand things you could otherwise
have gotten away with not
understanding

View Slide

@alicebartlett
One of the reasons little
baby me found writing
good commits hard was
that when I started
writing code, a lot of my
process was “try things
until it works”

View Slide

@alicebartlett
This meant it took me a lot longer to
gain a deeper understanding of how
things work

View Slide

@alicebartlett
Taking the time to ﬁgure out why
something works is a good investment
in your future

View Slide

1. Why should you care?
• The code is better - which is better for you
because you have to maintain it
• It makes you smarter

View Slide

2. What is Git

View Slide

@alicebartlett
Did you know that before Git, we all
using other version control systems?

View Slide

@alicebartlett
Linus Torvalds developed Git in 2005 to
manage development of the Linux
Kernel.

View Slide

@alicebartlett
Before we get into this, let’s just talk
about Linus.

View Slide

Alice Bartlett
http://somewebsite.com
Linus
Torvalds

View Slide

@alicebartlett
He is known for emails to the Linux mailing list
containing comments that I don’t want to
repeat here but they are very very unpleasant

View Slide

@alicebartlett
Part of Linus’s personal brand is that he
is very smart

View Slide

@alicebartlett
When he created Git, it was described as
a tool expressly designed to make you
feel less intelligent than you thought you
were

View Slide

@alicebartlett
Up until 2005, Linux
development had used a
version control system
called BitKeeper, and
prior to that, they just
emailed tarballs around

View Slide

@alicebartlett
The creation of Git was a bit dramatic

View Slide

@alicebartlett
BitKeeper was a closed source
proprietary version control system

View Slide

@alicebartlett
There was a free to use client, but it was
closed source too.

View Slide

@alicebartlett
One of the Linux contributors, Andrew
Tridgell, decided to create an open
source BitKeeper client as he didn’t
think it was right to use a closed source
client to work on an open source project

View Slide

@alicebartlett
This upset the BitKeeper team, who
then revoked access to their free to use
client

View Slide

@alicebartlett
Which meant development on the Linux
kernel had to pause while a new version
control system was found

View Slide

@alicebartlett
In a talk two years later, Linus called
Tridgell “stupid and ugly” for doing this

View Slide

@alicebartlett
So Linus creates Git - he knows a lot
about ﬁle system performance so he’s
able to make it about an order of
magnitude faster than its competitors
across lots of operations — reading,
committing and diﬀing

View Slide

@alicebartlett
Incidentally, the version
control system for Git is
(obviously) Git.

View Slide

@alicebartlett
The world’s ﬁrst ever Git commit
message is in the Git repository…

View Slide

@alicebartlett
https://github.com/git/git/commit/
e83c5163316f89bfbde7d9ab23ca2e25604af290
Initial revision of
"git", the information
manager from hell
Linus Torvalds, 7 Apr 2005

View Slide

@alicebartlett
Git was a big paradigm shift

View Slide

@alicebartlett
So much so, that thinking about how
things used to be now is actually quite
confusing

View Slide

@alicebartlett
Let’s take a quick look at
some of the ways Git was
really diﬀerent from CVS
and Subversion, two
popular alternatives back
In 2005

View Slide

@alicebartlett
One of the design choices for Git which
is very diﬀerent to its major competitors
is that it is distributed

View Slide

@alicebartlett
Git CVS and SVN

View Slide

@alicebartlett
• No network connection needed

View Slide

@alicebartlett
• Common operations like committing are
quicker

View Slide

@alicebartlett
quicker
• You can try things in private

View Slide

@alicebartlett
quicker
• There is no single point of failure because
there’s no central server

View Slide

@alicebartlett
quicker
• There is no single point of failure because
there’s no central server
• Much easier to give people access to noodle
around

View Slide

@alicebartlett
Decentralised was radical at the time.

View Slide

@alicebartlett
In 2007, Linus gave a talk at Google
about Git and the beneﬁts of distributed
version control and he got about three
questions that were all variations of…

View Slide

@alicebartlett
“Isn’t distributed code bad actually?”

View Slide

Joel Spolksy speaking in 2010
https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/
“Possibly the biggest
advance in software
development
technology in the
[past] ten years”

View Slide

@alicebartlett
Another thing Git does amazingly well is
branching

View Slide

@alicebartlett
In both CVS and SVN, branching was
incredibly tedious

View Slide

@alicebartlett
All branches existed in a global
namespace, you couldn’t have a little
private branch to do your experiments
on

View Slide

@alicebartlett
Branches were considered a really
advanced technique in CVS and SVN, so
most people just didn’t use them.

View Slide

@alicebartlett
If you’re not using branches though
revising your history becomes super
annoying for your colleagues who will
already have your ﬁrst set of changes

View Slide

@alicebartlett
If you're not using branches, and you
only have a central repository,
committing becomes really diﬀicult
because all the tests have to pass, and
the commit must make sense in
isolation

View Slide

@alicebartlett
So things like atomic commits are not
possible unless you get things right ﬁrst
time!

View Slide

@alicebartlett
OK so — we agree:
1. Doing version control properly is
important
2. Git is really good, actually.

View Slide

@alicebartlett
Why are we so bad at Git?

View Slide

@alicebartlett
Firstly, it is hard to use

View Slide

@alicebartlett

View Slide

@alicebartlett
Jargon

View Slide

@alicebartlett
Branches, commits, trees, repositories,
working tree, staging, remotes, the
stash, cherry picking, hunks, rebasing...

View Slide

@alicebartlett
You are in a detached HEAD state

View Slide

@alicebartlett
So to ﬁgure this stuﬀ out you have to go
read the manual. But the manual is also
really confusing!

View Slide

@alicebartlett
Update remote refs with
associated changes

View Slide

@alicebartlett
That’s the description for Git push!

View Slide

@alicebartlett
https://git-man-page-generator.lokaltog.net/

View Slide

@alicebartlett

View Slide

@alicebartlett
This is why we’re so bad at Git. Because
its user interface is badly designed.

View Slide

2. What is Git?
• A version control system created to manage
the Linux kernel
• Radically diﬀerent to pre-existing version
control systems
• Bad user interface

View Slide

2. What is Git?

View Slide

@alicebartlett
Here is what we’re aiming for...

View Slide

@alicebartlett
1. Atomic commits
2. Meaningful commit messages

View Slide

@alicebartlett
Start End

View Slide

@alicebartlett
Start End
Start End

View Slide

@alicebartlett
1.git add --patch
2.git commit --amend
3.git reset [sha]

View Slide

@alicebartlett
Unfortunately I’m going to have to
explain some jargon here…

View Slide

@alicebartlett
In Git there are three data structures
that represent your work

View Slide

@alicebartlett
// Working directory

View Slide

@alicebartlett
// Staging index

View Slide

@alicebartlett
// Staging index
// Commit history

View Slide

@alicebartlett
Every commit has a
parent which it points to

View Slide

@alicebartlett
git add
git add --patch

View Slide

@alicebartlett
Before you can commit something, you
have to add it to the list of things you
want to commit.

View Slide

@alicebartlett
In git jargon you “stage” it by using git add

View Slide

@alicebartlett
// Staging index
// Commit history

View Slide

@alicebartlett

View Slide

@alicebartlett
$ git add

View Slide

@alicebartlett
$ git commit

View Slide

@alicebartlett
$ git commit -am "sqlite stuff"

View Slide

@alicebartlett
When you have some lines in your ﬁle
that you want to commit but some that
you don’t — use git add --patch

View Slide

@alicebartlett
Using git add --patch means that
even if you’ve failed to work atomically,
ie you have ended up with multiple
changes in the same ﬁle, you can still
commit atomically

View Slide

@alicebartlett
Start End
Start End

View Slide

@alicebartlett
git add --patch will ask you which
bits of a ﬁle you want to add. It calls
these “bits” hunks.

View Slide

$ git add --patch

View Slide

$ git add --patch
diff --git a/config/playlist.js b/config/playlist.js
index 7e54d1a..eba4bf5 100644
--- a/config/playlist.js
+++ b/config/playlist.js
@@ -28,14 +28,6 @@ const playlistConfigs = {
videos: byDuration
})
},
- popular: {
- query: queries['popular-videos'],
- dataReader: ({ data: { video: { popular = []}} = {}} = {}) => ({
- videos: popular
- })
- },
section: {
query: queries['section-videos'],
dataReader: ({ data: { section = {}} = {}} = {}) => {
Stage this hunk [y,n,q,s,e,?]?

View Slide

$ git add --patch
videos: byDuration
})
},
- popular: {
- videos: popular
- })
- },
section: {
Nice diﬀ of
your changes

View Slide

$ git add --patch
videos: byDuration
})
},
- popular: {
- videos: popular
- })
- },
section: {

View Slide

@alicebartlett

View Slide

@alicebartlett
y: yes add this to the things I want to commit
n: no, leave this hunk alone
q: quit
s: split this hunk into smaller hunks
e: manually edit the hunk
?: tell me about these options

View Slide

@alicebartlett
git commit --amend

View Slide

@alicebartlett
So git commit is something you’ll have
used many times if you’ve used git.
git commit --amend lets you amend
your last commit.

View Slide

@alicebartlett
Super useful if you committed too soon, or
you want to modify the commit message

View Slide

@alicebartlett
When you use git commit --amend you
completely replace the last commit with a
new one and it will commit everything
that’s currently staged.

View Slide

377dfcd00dd057542b112cf13be6cf1380b292ad
20-05-2016: Fix broken sign up buttno CSS

View Slide

oops :(

View Slide

$ git commit --amend

View Slide

$ git commit --amend
439301fe69e8f875c049ad0718386516b4878e22
20-05-2016: Fix broken sign up button CSS

View Slide

439301fe69e8f875c049ad0718386516b4878e22
20-05-2016: Fix broken sign up button CSS

View Slide

@alicebartlett
git reset

View Slide

@alicebartlett
Use git reset when you want to undo
changes

View Slide

@alicebartlett
$ git commit
$ git add

View Slide

@alicebartlett
git reset moves
changes back
through these
structures
What gets moved
depends on the
arguments you call
reset with

View Slide

@alicebartlett
Calling git reset with no
additional arguments moves
any changes on the Staging
Index back to the Working
Directory.
Nothing happens to the
commit history.
git reset

View Slide

@alicebartlett
Calling git reset will
move all changes from any
commit after the id you’ve
given it back to the Working
Directory
git reset

View Slide

@alicebartlett
Calling git reset will
move all changes from any
commit after the id you’ve
given it back to the Working
Directory
git reset
Commit

View Slide

@alicebartlett
You can also call git reset with the
--hard option.
This will reset the pointers to
commit and DELETE the
contents of you working Directory.
Any uncommitted changes in your
working directory or staging index
are lost
git reset --hard

View Slide

@alicebartlett
You can also call git reset with the
--hard option.
This will reset the pointers to
commit and DELETE the
contents of you working Directory.
Any uncommitted changes in your
working directory or staging index
are lost
git reset --hard
Gone!

View Slide

@alicebartlett
1. git add and git add --patch to selectively move
changes from Working Directory to Staging
2. git commit --amend to quickly change commit messages
3. git reset to move work backwards in workﬂow

View Slide

@alicebartlett
1.git rebase
2.git rebase --interactive

View Slide

@alicebartlett
Start End
Start End
In the last bit we covered making and undoing
commits, now we’re going to look at changing
larger bits of your commit history

View Slide

@alicebartlett
git rebase allows you to literally
rewrite your history. This is very useful
as often, through making changes, new
or better ways of doing things or
ordering changes reveal themselves

View Slide

@alicebartlett
Rebasing replays your changes over a
branch.
You take the patch of one commit and
apply it to a diﬀerent commit

View Slide

@alicebartlett
feature branch
master
Rebasing is changing the
base of your branch from
one commit to another,
making it look as if you had
created a branch from a
diﬀerent commit
HEAD

View Slide

@alicebartlett
feature branch
master

View Slide

@alicebartlett
feature branch
master
HEAD

View Slide

@alicebartlett
feature branch
(merge commit)
master
feature branch
master
Rebase
Merge

View Slide

@alicebartlett
feature branch
If you're working on a feature and want to bring in
changes from master that happen in the interim,
rebasing stops you from having lots of merge commits
merge commit

View Slide

@alicebartlett
The golden rule of rebasing is:
ONLY USE IT ON LOCAL UNPUBLISHED
BRANCHES

View Slide

@alicebartlett
1.git rebase
2.git rebase --interactive

View Slide

@alicebartlett
Rebasing on it’s own is kind of
interesting, but the really useful stuﬀ
happens with
git rebase --interactive

View Slide

@alicebartlett
git rebase --interactive takes
rebasing and turns it into a very boring
text adventure game

View Slide

@alicebartlett
On the feature branch and we run:
git rebase --interactive origin/master
feature branch
master

View Slide

@alicebartlett
So - we’re going to replay these
commits here: feature branch
master

View Slide

@alicebartlett
pick a8f83c27 Remove CommentFactory documentation
pick cf19c147 Whitespace changes
pick 637bf758 Add commentwer mock
pick fb274f86 Whitespace
# Rebase 66d43b29..fb274f86 onto 66d43b29 (5 commands)
#
# 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
# d, drop = remove commit
# l, label = label current HEAD with a name
# t, reset = reset HEAD to a label
# m, merge [-C | -c ] [# ]
#
# [… etc… ]

View Slide

@alicebartlett
A list of
commits
#
# Commands:
# m, merge [-C | -c ] [# ]
#
# [… etc… ]

View Slide

@alicebartlett
A list of
commands
#
# Commands:
# m, merge [-C | -c ] [# ]
#
# [… etc… ]

View Slide

@alicebartlett
Lets merge these two
commits as they’re
both just whitespace
changes

View Slide

@alicebartlett
squash fb274f86 Whitespace
We can use “squash”
to do that

View Slide

@alicebartlett
Let’s also ﬁx this typo
using the re-word option

View Slide

@alicebartlett
reword 637bf758 Add commentwer mock
Let’s also ﬁx this typo
using the re-word option

View Slide

@alicebartlett
Once you close that rebase ﬁle Git will
step you through each of the commands
from top to bottom, stopping when your
input is required

View Slide

@alicebartlett
feature
HEAD

View Slide

@alicebartlett
pick
feature
HEAD

View Slide

@alicebartlett
squash
feature
HEAD

View Slide

@alicebartlett
reword
feature
HEAD

View Slide

@alicebartlett
feature
HEAD
reword 637bf758 Add commenter mock

View Slide

@alicebartlett
OK — time for a more complicated
rebase example...

View Slide

@alicebartlett
This is about the nursery rhyme
“Old Mac Donald”

View Slide

@alicebartlett
Old Mac Donald had a farm
eee-eye-eee-eye-oh
and on that farm he had some cows
eee-eye-eee-eye-oh!
With a moo moo here!
and a moo moo there!
here a moo!
there a moo!
everywhere a moo moo!
eee-eye-eee-eye-oh

View Slide

@alicebartlett
eee-eye-eee-eye-oh
eee-eye-eee-eye-oh!
here a moo!
there a moo!
eee-eye-eee-eye-oh
Initial commit

View Slide

@alicebartlett
eee-eye-eee-eye-oh
and on that farm she had some cows
eee-eye-eee-eye-oh!
here a moo!
there a moo!
eee-eye-eee-eye-oh
Initial commit
Change gender"

View Slide

@alicebartlett
eee-eye-eee-eye-oh
and on that farm she had some wheat
eee-eye-eee-eye-oh!
With a swish swish here!
and a swish swish there!
here a swish!
there a swish!
everywhere a swish swish!
eee-eye-eee-eye-oh
Initial commit
Change gender"
Farm wheat

View Slide

@alicebartlett
eee-eye-eee-eye-oh
and on that farm they had some wheat
eee-eye-eee-eye-oh!
With a swish swish here!
and a swish swish there!
here a swish!
there a swish!
everywhere a swish swish!
eee-eye-eee-eye-oh
Initial commit
Change gender"
Farm wheat
Use singular they

View Slide

@alicebartlett
Initial commit
Change gender"
Farm wheat
Use singular they
Let’s delete this
from commit. We
don't need it, it
doesn’t help tell the
story of our project

View Slide

@alicebartlett
$ git rebase -i HEAD~4

View Slide

@alicebartlett
pick a Initial commit
pick b Change gender "
pick c Farm wheat
pick d Use singular they
Initial commit
Change gender"
Farm wheat
Use singular they

View Slide

@alicebartlett
Initial commit
Change gender"
Farm wheat
Use singular they
pick a Initial commit
pick c Farm wheat
pick d Use singular they

View Slide

@alicebartlett
Auto-merging old-mac-donald.txt
CONFLICT (content): Merge conflict in old-mac-donald.txt
error: could not apply C... Farm wheat
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git
rebase --abort".
Could not apply C... Farm wheat

View Slide

MERGE
CONFLICT!!!

View Slide

@alicebartlett
$ git rebase --abort

View Slide

@alicebartlett
Auto-merging old-mac-donald.txt
CONFLICT (content): Merge conflict in old-mac-
donald.txt
error: could not apply C... Farm wheat
Resolve all conflicts manually, mark them as
resolved with
"git add/rm ", then run "git
rebase --continue".
You can instead skip this commit: run "git rebase
--skip".
To abort and get back to the state before "git
rebase", run "git rebase --abort".
Could not apply C... Farm wheat
Initial commit
Change gender"
Farm wheat
Use singular they

View Slide

@alicebartlett
Why has
this happened?
Initial commit
Change gender"
Farm wheat
Use singular they

View Slide

@alicebartlett
Initial commit
Change gender"
Farm wheat
Use singular they
We deleted our
“Change gender”
commit

View Slide

@alicebartlett
Initial commit
Change gender"
Farm wheat
Use singular they
But our “Farm wheat”
change expected it

View Slide

@alicebartlett
$ git show b
commit b
[...]
eee-eye-eee-eye-oh
-and on that farm he had some cows
+and on that farm she had some cows
eee-eye-eee-eye-oh!
[...]

View Slide

@alicebartlett
$ git show c
commit c
[...]
eee-eye-eee-eye-oh
-and on that farm she had some cows
+and on that farm she had some wheat
eee-eye-eee-eye-oh!
[...]

View Slide

@alicebartlett
eee-eye-eee-eye-oh
<<<<<<< HEAD
=======
and on that farm she had some wheat
>>>>>>> c... Switch to wheat
eee-eye-eee-eye-oh!

View Slide

@alicebartlett
eee-eye-eee-eye-oh
and on that farm he had some wheat
eee-eye-eee-eye-oh!

View Slide

@alicebartlett
eee-eye-eee-eye-oh
and on that farm he had some wheat
eee-eye-eee-eye-oh!
And now we’re good to go — we can
add that change and continue run
git rebase --continue

View Slide

@alicebartlett
And you have single handedly
saved the planet and destroyed the
gender binary in a two commit
messages while also overcoming a
merge conﬂict and maintaining a
clean Git history. Not bad.
Initial commit
Farm wheat
Use singular they

View Slide

@alicebartlett
1. git rebase to pull in any changes from another branch for
a neater history without any merge commits
2. git rebase --interactive to edit and restructure
multiple commits before you push them

View Slide

3. Tips for Git history management
• Use git add --patch to help iron out your
messy working process from the history
• Gateway drug: git commit --amend
• Use git reset to undo things in the history
• Use git rebase for redo things in the history

View Slide

2. What is Git

View Slide

@alicebartlett
Start End
Start End

View Slide

@alicebartlett
Thank you
@alicebartlett

View Slide

@alicebartlett
1. Noun Project Faces by Sarah Rudkin: https://
thenounproject.com/sarahdrudkin/collection/faces/
2. Linus Torvalds at Google 2007: https://www.youtube.com/
watch?v=4XpnKHJAok8
3. Tekin Süleyman’s A Branch In Time: https://
www.youtube.com/watch?v=1NoNTqank_U
4. Git man page generator: https://git-man-page-
generator.lokaltog.net/

View Slide

Getting more from Git

Getting more from Git

Alice Bartlett

More Decks by Alice Bartlett

Other Decks in Technology

Featured

Transcript