Git Makes Me Angry Inside - DrupalCon Prague

10,032 views

Published on

You are a clever and talented person. You create beautiful designs, or perhaps you can architect a system that even a cat could use. Your peers adore you. Your clients love you. But (until now) you haven't *&^#^ been able to make Git bend to your will. It makes you angry inside that you have to ask your co-worker, again, for that *&^#^ command to share your work.

It's not you. It's Git. Promise.

We'll kick off this session with an explanation of why Git is so freaking hard to learn. Then we'll flip the tables and make YOU (not Git) the centre of attention. You'll learn how to define, and sketch out how version control works, using terms and scenarios that make sense to you. Yup, sketch. On paper. (Tablets and other electronic devices will be allowed, as long as you promise not to get distracted choosing the perfect shade for rage.) To this diagram you'll layer on the common Git commands that are used regularly by efficient Git-using teams. It'll be the ultimate cheat sheet, and specific to your job. If you think this sounds complicated, it's not! Your fearless leader, Emma Jane, has been successfully teaching people how-to-tech for over a decade. She is well known for her non-technical metaphors which ease learners into complex, work-related topics that previously felt inaccessible.

Yes, this is an introductory session. 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. Yes, you should attend if you've been embarrassed to ask team-mates what Git command you used three weeks ago to upload your work...just in case you're supposed to remember.

If you're a super-human Git fanatic who is frustrated by people who don't just "git it", this session is also for you. You'll learn new ways to effectively communicate your ever-loving Git, and you may develop a deeper understanding of why your previous attempts to explain Git have failed.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,032
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
20
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Git Makes Me Angry Inside - DrupalCon Prague

  1. 1. 25 September, 2013 GitMakes Me Angry Inside 1
  2. 2. Emma Jane Drupalize.Me IRC: emmajane @emmajanehw 2
  3. 3. I’ve tried! I can’t learn this stuff. 3 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.
  4. 4. Git was built for and by Linux kernel developers. 4 Quick show of hands: How many people will raise their hand when asked? Great. And how many people here are Linux kernel developers?
  5. 5. How we typically teach people how to tech has nothing to do with adult education best practices. 5 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.
  6. 6. Adults learn best when they can be selfish. 6 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.
  7. 7. “Please memorize all Git commands and use only rebasing when merging your work.” No client ever 7 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.
  8. 8. Start with the whole to solve real problems. 8 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.
  9. 9. Bloom’s Taxonomy http://lb.cm/bt 9
  10. 10. Agenda • Sample team workflow • Branch management strategies • Q&A / therapy session 10
  11. 11. How do we make Git do that? Git Shell, cross- platform 11
  12. 12. Your problems are 90% social. 12
  13. 13. What’s your role? 13
  14. 14. What are your tasks? download work create snapshot share work 14
  15. 15. What’s your workflow? 15
  16. 16. 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 16
  17. 17. 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. 17
  18. 18. 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
  19. 19. What’s your workflow? With the team members identified, it’s time to sketch out how these people (ideally) work together. 19
  20. 20. Centralized workflow 20
  21. 21. Decentralized with human gatekeeper 21
  22. 22. Decentralized with automated gatekeeper 22
  23. 23. 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
  24. 24. 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
  25. 25. Popular strategies • http://nvie.com/posts/a- successful-git-branching-model • http://scottchacon.com/ 2011/08/31/github-flow.html 25
  26. 26. Work flow and branch management 26
  27. 27. Work flow and branch management 26
  28. 28. Work flow and branch management peer review 26
  29. 29. Work flow and branch management peer review public / live server 26
  30. 30. Work flow and branch management peer review public / live server 26
  31. 31. Work flow and branch management peer review public / live server dev / testing server 26
  32. 32. Work flow and branch management peer review public / live server dev / testing server master master master 26
  33. 33. Work flow and branch management peer review public / live server dev / testing server master master master dev dev dev 26
  34. 34. Work flow and branch management feature feature hotfix featur peer review public / live server dev / testing server master master master dev dev dev 26
  35. 35. Work flow and branch management feature feature hotfix featur peer review public / live server dev / testing server master master master dev dev dev 26
  36. 36. 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 27
  37. 37. Q&A + Git Therapy Session 28
  38. 38. 29
  39. 39. THANK YOU! WHAT DID YOU THINK? Locate this session at the DrupalCon Prague website: http://prague2013.drupal.org/schedule Click the “Take the survey” link 29
  40. 40. Terminology: locations origin local repository index, cache, or stage working tree 30 Upstream Origin: where you downloaded the code from Working copy: your local copy Trunk (aka main): The current, primary source for unchanged code. Head: the latest revision in the repository.
  41. 41. Actions and tasks 31
  42. 42. You can make Git do what you want...now that you know what you want. @emmajanehw http://drupalize.me http://developerworkflow.com/ 32

×