Git Makes Me Angry Inside

Git Makes Me Angry Inside
Emma Jane Westby
Education Development Coordinator
Drupalize.Me
@emmajanehw
http://drupalize.me
Slides at: http://tinyurl.com/dcto13-git
Saturday, 13 July, 13
Problem: Developers face a steep learning curve when they choose to adopt version control.
Solution: There is a version control strategy to suit your workflow, even if you've always
thought it was too hard to bother.
Is your project folder filled with files like this: page.old.2.bak.php? Does Git make you angry
inside? Do you resent that everyone except you regularly visits the magical place referred to
as "The Command Line"? Are you afraid of the vagrant who stole your puppet? In this session
you will get a gentle introduction to working efficiently as a developer in small teams, or as a
solo developer. We'll focus on real world examples you can actually use to make your work
faster and more efficient.
Yes, this is an introductory session. This is for people who feel shame that they don't know
how to "just cd into yer root durrr" and get mad when people say "just diff me a patch" as if
it's something as easy as making a mai thai even though you have no rum. No, you don't have
to have git installed to attend. You don't even need to know where the command line is on
your computer.

Why Stick Around
• Learn how Git thinks, without being exposed to the command line.
• Learn how to structure your work ﬂow to take advantage of Git.
• Learn how basic commands are applied to common work ﬂow scenarios.
• Q&A / therapy session

What’s your role?
You need to start with the people....

What are your tasks?
download
work
create
snapshot
share
work
What are the tasks that your team work on?
For example: download work, make changes, upload work to a shared space.

What’s your workﬂow?
There are a lot of valid workﬂows.

What’s your branch management strategy?
As your people are working together, they need to have private, and shared spaces to do
their work. This is where a branch management strategy gets layered in.

How do we make Git do that?
Git Shell, cross-platform
We’re not going to talk about the speciﬁcs of how to run commands today. But these are a
few examples of the GUIs that are available for different platforms. (You don’t *have to be*
stuck on the command line if you don’t want to be.)
Before we get started: let’s take a second to ﬁnd out who you are. Why are you here, and how
are you currently struggling with version control?

Git is 90% process and 10% technology.
• Git was written by kernel developers, for kernel developers. Chances are high
you’re not a kernel developer. Stop blaming yourself, and start blaming Git for
your struggles.
• Not all is lost! If you can diagram the problem you are trying to solve; you will
be able to ﬁnd the right Git commands.
• Before we start drawing pictures, let’s take a look at some of the concepts
version control helps us with.
Out of the box, Git does basically nothing for you. It’s your processes that will allow you to
apply the tools you need to make version control work for you.
Then go through each of the points listed.
Transition: let’s take a look at some of the terms you’ll run into when working with Git to give
us a shared language.

Version control (sort of) makes automation easier
• Backup and restore
• Synchronize across multiple platforms
• Short-term “undo” to test implications of changes
• Long-term “undo” to reverse bugs or regressions
• Track changes to see why/how software evolved
• Track ownership to give “credit” to change makers
• Sandbox code to test changes without aﬀecting other people and systems
There are a lot of valid reasons to use version control. The biggest gain bigger teams will see
is in automation of process. But you don’t need to automate things to take advantage of
version control.
Read through the list of things version control helps with.

Terminology: locations
• remote repository
• trunk or main
• head or tip
• local repository
• client
• working copy
There are a lot of terms in version control. Creating a map of where things live can make the
documentation a lot easier to deal with.
Repo: database of changes to your ﬁles.
Server: computer storing the repo
Client: computer connecting to the repo
Working copy: local copy where changes are made
Trunk/main: The current, primary source for unchanged code
Head: the latest revision in a repository (tip: latest in a branch...HEAD moves, tip doesn’t).

Terminology: actions and tasks
With our locations mapped out, let’s take a look at the common tasks or “actions” you can
take.
Basic actions:
adopt / download: clone, merge, fetch, checkout, pull/rebase
review: log, status
compare: diff HEAD, diff, diff --cached
reset: checkout, checkout HEAD, reset --hard (throw away in-between commits), revert (save
in-between commits)
save: add -u, commit, commit -a
distribute: push

Set the stage!
Before we can set our workﬂow we need to know who we’re dealing with and
what they’re supposed to be doing.
People ﬁrst. In this next section, we’ll start with the folks on your team (not the software).

Who’s on your code team?
Write down a list of all of the people on your code team. This list may
include:
• developers
• designers
• project managers
• clients
Who are the folks on your team? Designer? Developer? Site builder?

Where do you ﬁt in?
Maybe you do everything. Maybe you only do some things. Write a list of all
the tasks you are actually responsible for. This might include:
• Writing code.
• Reviewing code.
• Pushing tested code to the server.
• Fixing broken code.
Slide is “as advertised”.

What are your tools and restraints?
Often there are other things we need to ﬁt into our workﬂow. Create a third list
of any tools and restraints you are aware of. This list might include:
• Version control software (we’ll always assume Git)
• Code hosting system (Bitbucket, GitHub, self-hosted)
• Server ecosystem (dev / staging / live)
• Code editors & integrated developer environments (vim, Dreamweaver,
Sublime, PHPstorm)
• Automated testing systems or review “gates”

What’s your workﬂow?
With the team members identiﬁed, it’s time to sketch out how these people
(ideally) work together.
Now that we know the people, let’s talk about how they work together. There are lots of valid
ways of working together, let’s take a look at a few of them.

Solo developer workflow
Solo dev workflow:
create project, add files, do work, upload files

Partner workﬂow with no central server
James starts a grocery list; Emma already had a grocery list started so she asks to see James’s
list. She adds her items to James’s list and hands it back.

Centralized workﬂow with no local commits
the “old” style of version control has a single place where all work is checked into. Every time
work is saved, it’s uploaded to the shared space. You can implement this workﬂow with
distributed version control too, but you wouldn’t want to.

Decentralized with human gatekeeper
This is pretty typical: it’s a decentralized workﬂow. The developers pull/clone. Do their work
locally and then ask their “gatekeeper” to check their work and merge it into the central repo.
Once the central repo has the changes, the devs grab a fresh copy and continue their work.

Decentralized with automated gatekeeper
The decentralized with automated gatekeeper is almost the same, except it’s a computer
making the decision on whether or not code should be accepted. This is ﬁne for quantitative
reviews, but shouldn’t be used for qualitative reviews...unless there are pre-merge peer
reviews also happening.

Sketch out your workﬂow
• Identify the roles on your team.
• Identify the relationships between the team members.
• Draw arrows to show how code ﬂows between team members.

How will you manage your branches?
With the workflow described, it’s time to look at how the code will be
segregated into different branches.
This is where the fun starts! Managing branches in a distributed workflow.

Popular strategies
• http://nvie.com/posts/a-
successful-git-branching-model
• http://scottchacon.com/
2011/08/31/github-ﬂow.html

Work ﬂow and branch management

peer review

peer review
public / live
server

peer review
public / live
server
dev / testing
server

peer review
public / live
server
dev / testing
server
master
master
master

peer review
public / live
server
dev / testing
server
master
master
master
dev
dev
dev

feature feature
hotﬁx featur
peer review
public / live
server
dev / testing
server
master
master
master
dev
dev
dev

Sketch out your branch management strategy
• Identify the roles on your team.
• Identify the relationships between the team members.
• Draw arrows to show how code ﬂows between team members.
• Time: 10 minutes

Q&A + Git Therapy Session

You can make Git do what you want...
now that you know what you want.
@emmajanehw
http://drupalize.me
Slides: http://lb.com/dcto13-git
How to git: http://lb.cm/howto-git-videos

Git Makes Me Angry Inside

More Related Content

Viewers also liked

Similar to Git Makes Me Angry Inside

More from Emma Jane Hogbin Westby

Recently uploaded

Git Makes Me Angry Inside