Getting more from Git

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

@alicebartlett This talk is about Git

@alicebartlett I have some humble ambitions

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

@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

@alicebartlett Me

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

@alicebartlett

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

@alicebartlett 204 lines of code added

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

@alicebartlett

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

@alicebartlett “Fixes to download”

@alicebartlett ¯\_(ツ)_/¯

@alicebartlett So that is what bad looks like

@alicebartlett What are we aiming for?

@alicebartlett 1. Atomic commits 2. Meaningful commit messages

@alicebartlett What are “atomic commits”?

@alicebartlett One commit per unit of change

@alicebartlett A style change

@alicebartlett A whitespace refactor A style change

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

@alicebartlett A commit should be a single unit of work

@alicebartlett It should make sense in isolation

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

@alicebartlett The other thing is commit messages

@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.

@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.

@alicebartlett WHY

@alicebartlett Fixes to download

@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.

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

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

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

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

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

@alicebartlett 1. Bikeshed over naming things

@alicebartlett 1. Bikeshed over naming things 2. Write documentation

@alicebartlett 1. Bikeshed over naming things 2. Write documentation 3.
Refactor

@alicebartlett 1. Bikeshed over naming things 2. Write documentation 3.
Refactor 4. Write tests 5. … etc

@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.

@alicebartlett Git commit histories are part of this picture

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

@alicebartlett 1. They never change

@alicebartlett 1. They never change 2. They live alongside your
code

code 3. They’re searchable with Git grep

code 3. They’re searchable with Git grep 4. They allow you to document your change at the time that you made it

code 3. They’re searchable with Git grep 4. They allow you to document your change at the time that you made it 5. They are hosting independent

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

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

@alicebartlett PUT IT IN THE COMMIT MESSAGE

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

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

@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

@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

@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”

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

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

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

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

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

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

Alice Bartlett http://somewebsite.com Linus Torvalds

@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

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

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

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

@alicebartlett The creation of Git was a bit dramatic

@alicebartlett BitKeeper was a closed source proprietary version control system

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

@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

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

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

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

@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

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

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

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

@alicebartlett Git was a big paradigm shift

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

@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

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

@alicebartlett Git CVS and SVN

@alicebartlett • No network connection needed

@alicebartlett • No network connection needed • Common operations like
committing are quicker

committing are quicker • You can try things in private

committing are quicker • You can try things in private • There is no single point of failure because there’s no central server

committing are quicker • You can try things in private • There is no single point of failure because there’s no central server • Much easier to give people access to noodle around

@alicebartlett Decentralised was radical at the time.

@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…

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

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”

@alicebartlett Another thing Git does amazingly well is branching

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

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

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

@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

@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

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

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

@alicebartlett Why are we so bad at Git?

@alicebartlett Firstly, it is hard to use

@alicebartlett

@alicebartlett Jargon

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

@alicebartlett You are in a detached HEAD state

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

@alicebartlett Update remote refs with associated changes

@alicebartlett That’s the description for Git push!

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

@alicebartlett

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

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

2. What is Git? 3. Tips for rewriting your Git

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

@alicebartlett 1. Atomic commits 2. Meaningful commit messages

@alicebartlett Start End

@alicebartlett Start End Start End

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

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

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

@alicebartlett // Working directory

@alicebartlett // Working directory // Staging index

@alicebartlett // Working directory // Staging index // Commit history

@alicebartlett Every commit has a parent which it points to

@alicebartlett git add git add --patch

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

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

@alicebartlett // Working directory // Staging index // Commit history

@alicebartlett

@alicebartlett $ git add

@alicebartlett $ git commit

@alicebartlett $ git commit -am "sqlite stuff"

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

@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

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

$ git add --patch

$ 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,?]?

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,?]? Nice diﬀ of your changes

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,?]?

@alicebartlett Stage this hunk [y,n,q,s,e,?]?

@alicebartlett Stage this hunk [y,n,q,s,e,?]? 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

@alicebartlett git commit --amend

@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.

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

@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.

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

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

377dfcd00dd057542b112cf13be6cf1380b292ad 20-05-2016: Fix broken sign up buttno CSS $ git
commit --amend

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

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

@alicebartlett git reset

@alicebartlett Use git reset when you want to undo changes

@alicebartlett $ git commit $ git add

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

@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

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

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

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

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

@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

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

@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

@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

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

@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

@alicebartlett feature branch master

@alicebartlett feature branch master HEAD

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

@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

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

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

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

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

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

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

@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 <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # # [… etc… ]

@alicebartlett A list of commits 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 <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # # [… etc… ]

@alicebartlett A list of commands 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 <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # # [… etc… ]

pick 637bf758 Add commentwer mock pick fb274f86 Whitespace Lets merge these two commits as they’re both just whitespace changes

squash fb274f86 Whitespace pick 637bf758 Add commentwer mock We can use “squash” to do that

squash fb274f86 Whitespace pick 637bf758 Add commentwer mock Let’s also ﬁx this typo using the re-word option

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

@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

@alicebartlett feature HEAD pick a8f83c27 Remove CommentFactory documentation pick cf19c147
Whitespace changes squash fb274f86 Whitespace reword 637bf758 Add commentwer mock

squash fb274f86 Whitespace reword 637bf758 Add commentwer mock pick feature HEAD

squash fb274f86 Whitespace reword 637bf758 Add commentwer mock squash feature HEAD

squash fb274f86 Whitespace reword 637bf758 Add commentwer mock reword feature HEAD

@alicebartlett feature HEAD pick a8f83c27 Remove CommentFactory documentation pick cf19c147
Whitespace changes squash fb274f86 Whitespace reword 637bf758 Add commenter mock

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

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

@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! Old Mac Donald had a farm eee-eye-eee-eye-oh

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! Old Mac Donald had a farm eee-eye-eee-eye-oh Initial commit

that farm she 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! Old Mac Donald had a farm eee-eye-eee-eye-oh Initial commit Change gender"

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! Old Mac Donald had a farm eee-eye-eee-eye-oh Initial commit Change gender" Farm wheat

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! Old Mac Donald had a farm eee-eye-eee-eye-oh Initial commit Change gender" Farm wheat Use singular they

@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

@alicebartlett $ git rebase -i HEAD~4

@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

pick a Initial commit pick c Farm wheat pick d Use singular they

@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 <conflicted_files>", 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

MERGE CONFLICT!!!

@alicebartlett $ git rebase --abort

@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 <conflicted_files>", 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

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

We deleted our “Change gender” commit

But our “Farm wheat” change expected it

@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! [...]

@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! [...]

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

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

@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

@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

@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

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

@alicebartlett Thank you @alicebartlett

@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/

Getting more from Git

Getting more from Git

More Decks by Alice Bartlett

Other Decks in Technology

Featured

Transcript