Git Makes Me Angry Inside
1 like1,633 views
This document outlines a workshop that provides an introductory understanding of using Git for web developers, aimed at both individuals and teams. It emphasizes practical problem-solving and adaptation to various operating systems, while addressing common frustrations and teaching strategies for adult learners. The session includes hands-on activities, workflows, and troubleshooting tips to enhance efficiency and collaboration in software development.
![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](https://image.slidesharecdn.com/gitmakesmeangryinside-phptek-130514162902-phpapp01/85/Git-Makes-Me-Angry-Inside-26-320.jpg)
![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.](https://image.slidesharecdn.com/gitmakesmeangryinside-phptek-130514162902-phpapp01/85/Git-Makes-Me-Angry-Inside-34-320.jpg)
Git Makes Me Angry Inside
- 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.
- 11. What are your tasks? download work create snapshot share work
- 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.
- 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/