Problem: Developers face a steep learning curve when they choose to adopt version control.S 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.

1. Work Flow for Solo Developers and Small Teams
@emmajanehw
http://drupalize.me
http://developerworkflow.com/
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.

2. Agenda
• What problems version control can solve for you
• Work flow examples
• Branch management strategies
• Q&A / therapy session

3. What’s your role?

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

5. What’s your workflow?

6. What’s your branch management strategy?

7. How do we make Git do that?
Git Shell, cross-platform

8. Git is 90% process and 10% technology.
• If you can diagram the problem you are trying to solve; you are ready to start
playing with software. If you can’t draw the picture, you’re not ready for the
toolkit.
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.

9. 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 affecting other people and systems

10. Terminology: locations
• remote repository
• trunk or main
• head or tip
• local repository
• client
• working copy

11. Terminology: actions and tasks

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

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

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

15. 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”

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

17. Solo developer workflow

18. Partner workflow with no central server

19. Centralized workflow with no local commits

20. Decentralized with human gatekeeper

21. Decentralized with automated gatekeeper

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

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

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

25. Work flow and branch management

26. Work flow and branch management

27. Work flow and branch management
peer review

28. Work flow and branch management
peer review
public / live
server

29. Work flow and branch management
peer review
public / live
server

30. Work flow and branch management
peer review
public / live
server
dev / testing
server

31. Work flow and branch management
peer review
public / live
server
dev / testing
server
master
master
master

32. Work flow and branch management
peer review
public / live
server
dev / testing
server
master
master
master
dev
dev
dev

33. Work flow and branch management
feature feature
hotfix featur
peer review
public / live
server
dev / testing
server
master
master
master
dev
dev
dev

34. Work flow and branch management
feature feature
hotfix featur
peer review
public / live
server
dev / testing
server
master
master
master
dev
dev
dev

35. 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 flows between team members.
• Time: 10 minutes

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/