Does Git make you angry inside? In this workshop you will get a gentle introduction to working efficiently as a Web 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. Windows? OSX? Linux? No problem, we'll get you up and running with Git, no matter what your system. Yes, this is an introductory session. This is for people who feel shame that they don't know how to "clone my github project", wish they too could "get the gist", 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.

1. Git Makes Me Angry Inside
@emmajanehw
http://drupalize.me
http://developerworkflow.com/
room password: psav1755
Does Git make you angry inside? In this workshop you will get a gentle introduction to
working efficiently as a Web 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.
Windows? OSX? Linux? No problem, we'll get you up and running with Git, no matter what
your system. Yes, this is an introductory session. This is for people who feel shame that they
don't know how to "clone my github project", wish they too could "get the gist", 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.

2. “I’ve Tried, And I Can’t Learn This Stuff”
It’s not your fault. Honest.
The way we teach web stuff isn’t the way that you probably need to be exposed to the
information in order to learn it.
Blame the teachers, not yourself.
Or maybe not blame but, be persistent when working to solve important and sticky problems.

3. How we typically teach people how to tech has
nothing to do with adult education best practices.
RTFM: read the manual
Here are all the commands, here are all the options. Memorize everything, and figure out
later how to apply the knowledge.

4. Self-taught learning involves a lot of Googling,
guessing, and teeth gnashing.
Guess at what the problem is.
Search on the internet.
Find someone else’s description of how they solved, what you hope is a similar problem.

5. Adults learn best when they can be selfish.
Andragogy assumes the following about the design of learning:
Adults have the need to know why they are learning something.
Adults learn through doing.
Adults are problem-solvers.
Adults learn best when the subject is of immediate use.

6. This is not your problem:
My client wants me to memorize all the parameters
for using Git at the command line.
Your problem might sound like: My client keeps changing his mind, and but they don’t want
to pay me to redo the work.
Your problem doesn’t sound like: My client wants me to memorize all the parameters for
using Git at the command line.

7. Solve. Real. Problems.
Define your real problem clearly.
Learn how to use a tool to get your problem solved.
Try solving the problem. Take notes about how smooth it was to solve your problem. Write
recommendations to your future self on how you’d solve the problem in the future now that
you know what you know.

8. Agenda
• Work flow and branch management
• Disaster mitigation
• Q&A / therapy session

9. Your problems are 90% social.

10. What’s your role?

11. What are your tasks?
download
work
create
snapshot
share
work

12. What’s your workflow?

13. How do we make Git do that?

14. Set the stage!
Before we can set our workflow we need to know who we’re dealing with and
what they’re supposed to be doing.

15. 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
Time: 5 minutes

16. Where do you fit 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.
Time: 1 minute

17. What are your tools and restraints?
Often there are other things we need to fit into our workflow. 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”

18. What’s your workflow?
With the team members identified, it’s time to sketch out how these people
(ideally) work together.

19. Solo developer workflow

20. Partner workflow with no central server

21. Centralized workflow with no local commits

22. Decentralized with human gatekeeper

23. Decentralized with automated gatekeeper

24. Sketch out your workflow
• Identify the roles on your team.
• Identify the relationships between the team members.
• Draw arrows to show how code flows between team members.
• Time: 10 minutes

25. Branch management
• http://nvie.com/posts/a-
successful-git-branching-model
• http://scottchacon.com/
2011/08/31/github-flow.html

26. Disaster mitigation
• What Version of the File Is On My
Server?
• What Was I Thinking When I Wrote
This?
• *&^! That’s Wrong
• Untested Code (Eventually) Breaks
Stuff
• My Client Changed Their Mind ...
Again
• I Changed Something, And Stuff
Broke
• My Computer Died ... Now What?
• Two Clients Want Something
Similar...Leverage Your Work
• My [Collaborator] Overwrote My
Work
• http://developerworkflow.com

27. Problem:
What version of the file is on my server?
• “diff” -- what's the difference?
• never edit directly on the server, always “pull” from another location
• install only code which has a version associated with it (e.g. module.info)

28. Problem:
What Was I Thinking When I Wrote This?
• add in-code documentation
• use frequent commit messages, but only share (or “push”) relatively stable
code
• put radically different, or unrelated, ideas into different branches
• put related ideas, which are allowed to evolve, into the same branch, but add
tags to show milestones
• for very significant milestones, you may want to have different (numbered)
branches

29. Problem:
Untested Code (Eventually) Breaks Stuff
• create a development environment on another machine.
• copy your data down (backup and migrate)
• keep everything versioned (have a central repository that is web-accessible
which you can “pull” changes from for both your local env + dev server)
• upload your tested configuration changes.

30. Problem:
My Client Changed Their Mind ... Again
• You need a giant undo button to be able to roll back your code to a previous
state.
• build all three designs (get basics right, then modify only bits but tag between
each)
• add lots of “milestones” to your code so that you can see easily where things
changed

31. Problem:
I Changed Something, And Stuff Broke.
• Make only very small changes before making commits.
• Commits in distributed version control systems are like an “undo” button you
can apply after restarting your computer.
• Make only related changes within one commit. e.g. only font changes; vs.
only colour changes

32. Problem:
My Computer Died...Now What?
• having your configuration files saved (and perhaps versioned) means you can
quickly recover an entire system

33. Problem:
Two Clients Want Something Similar...
• one central repo
• create branches for each client
• where it makes sense, merge common functionality back into the main
branch / trunk

34. Problem:
My [Collaborator] Overwrote My Work.
• You’re working with a very tiny team and you think you don’t need a whole
source control system.
• Except you keep overwriting each others’ work.
• Create a centralized repository that you both check your work into and push
from that centralized server to the “live” site.
• On a regular basis “pull” your partner’s work from the centralized repo.

35. Homework
Write a list of all the problems you'd like to solve. Make sure your “problem”
includes:
• A description of all the people involved.
• A description of what makes the problem “bad”.
• A description of what the situation would look like once “fixed”.

36. Q&A + Git Therapy Session

37. You can make Git do what you want...now that you
know what you want.
@emmajanehw
http://drupalize.me
http://developerworkflow.com/