Git Makes Me Angry Inside
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Git Makes Me Angry Inside

  • 987 views
Uploaded on

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

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
987
On Slideshare
984
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 3

https://twitter.com 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Git Makes Me Angry Inside@emmajanehwhttp://drupalize.mehttp://developerworkflow.com/room password: psav1755Does Git make you angry inside? In this workshop you will get a gentle introduction toworking efficiently as a Web developer in small teams, or as a solo developer. Well focus onreal world examples you can actually use to make your work faster and more efficient.Windows? OSX? Linux? No problem, well get you up and running with Git, no matter whatyour system. Yes, this is an introductory session. This is for people who feel shame that theydont know how to "clone my github project", wish they too could "get the gist", and get madwhen people say "just diff me a patch" as if its something as easy as making a mai thai eventhough you have no rum. No, you dont have to have git installed to attend. You dont evenneed 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 theinformation 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 hasnothing to do with adult education best practices.RTFM: read the manualHere are all the commands, here are all the options. Memorize everything, and figure outlater 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 parametersfor using Git at the command line.Your problem might sound like: My client keeps changing his mind, and but they don’t wantto pay me to redo the work.Your problem doesn’t sound like: My client wants me to memorize all the parameters forusing 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. Writerecommendations to your future self on how you’d solve the problem in the future now thatyou 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?downloadworkcreatesnapshotsharework
  • 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 andwhat 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 mayinclude:• developers• designers• project managers• clientsTime: 5 minutes
  • 16. Where do you fit in?Maybe you do everything. Maybe you only do some things. Write a list of allthe 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 listof 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 MyServer?• What Was I Thinking When I WroteThis?• *&^! That’s Wrong• Untested Code (Eventually) BreaksStuff• My Client Changed Their Mind ...Again• I Changed Something, And StuffBroke• My Computer Died ... Now What?• Two Clients Want SomethingSimilar...Leverage Your Work• My [Collaborator] Overwrote MyWork• http://developerworkflow.com
  • 27. Problem:What version of the file is on my server?• “diff” -- whats 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 stablecode• put radically different, or unrelated, ideas into different branches• put related ideas, which are allowed to evolve, into the same branch, but addtags 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-accessiblewhich 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 previousstate.• build all three designs (get basics right, then modify only bits but tag betweeneach)• add lots of “milestones” to your code so that you can see easily where thingschanged
  • 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 youcan 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 canquickly 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 mainbranch / trunk
  • 34. Problem:My [Collaborator] Overwrote My Work.• You’re working with a very tiny team and you think you don’t need a wholesource control system.• Except you keep overwriting each others’ work.• Create a centralized repository that you both check your work into and pushfrom that centralized server to the “live” site.• On a regular basis “pull” your partner’s work from the centralized repo.
  • 35. HomeworkWrite a list of all the problems youd 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 youknow what you want.@emmajanehwhttp://drupalize.mehttp://developerworkflow.com/