Retooling Your Workflow

2,900 views
2,815 views

Published on

Are you handling client communication with email, updating your clients’ sites with FTP, making manual backups when you think of it, and crossing your fingers that everything gets done and nothing breaks? I’ve been there, and I’m here to tell you: it doesn’t have to be that way. In this talk, you’ll learn how to incorporate the git version control system and a ticketing system into your workflow to bring sanity and peace of mind to your development process, and why you don’t want to work on any collaborative project without them.

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

No Downloads
Views
Total views
2,900
On SlideShare
0
From Embeds
0
Number of Embeds
394
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Retooling Your Workflow

  1. 1. Retooling YourWorkflow Rebecca Murphey • @rmurphey Saturday, November 13, 2010
  2. 2. [Note: Some slides have had content obscured for the sake of confidentiality. Sorry.] Saturday, November 13, 2010
  3. 3. Or: Tools for measuring the quality of a client. Saturday, November 13, 2010
  4. 4. Or: Tools for getting access to more exciting, better-paying work. Saturday, November 13, 2010
  5. 5. Or: CYA. Saturday, November 13, 2010
  6. 6. I learned to tolerate terribleness. TheProblem Saturday, November 13, 2010
  7. 7. TheLessons Saturday, November 13, 2010
  8. 8. A ticketing system brings sanity to client requests. Emailisevil Saturday, November 13, 2010
  9. 9. Saturday, November 13, 2010
  10. 10. Saturday, November 13, 2010
  11. 11. Saturday, November 13, 2010
  12. 12. Saturday, November 13, 2010
  13. 13. Saturday, November 13, 2010
  14. 14. Saturday, November 13, 2010
  15. 15. Either the client needs to provide it, or I will. Versioncontrol isnon-negotiable Saturday, November 13, 2010
  16. 16. store step-by-step snapshots of your work $ mate index.html [make your changes] $ git status [see what’s changed] $ git commit -am ‘changing jQuery version’ [commit any modified files already in the repo] $ git push origin master [send your changes to the server] Saturday, November 13, 2010
  17. 17. Saturday, November 13, 2010
  18. 18. Saturday, November 13, 2010
  19. 19. see what you’ve done $ git log [see a history of the repo] $ git log -p [see a full diff for each log entry] $ git log --stat [see a short version of what changed per entry] $ git log -SmethodName [see commits whose diffs included ‘methodName’] Saturday, November 13, 2010
  20. 20. Saturday, November 13, 2010
  21. 21. Saturday, November 13, 2010
  22. 22. streamline the process of deploying new code to a server with tags [locally ...] $ git tag -a v1.3 $ git push --tags [tell the server about the tag!] [then, on your server] $ git pull $ git checkout v1.3 Saturday, November 13, 2010
  23. 23. rapidly roll back bad code on the server [on your server] $ git checkout v1.3 [all hell breaks loose] $ git checkout v1.2 [now to figure out what broke] Saturday, November 13, 2010
  24. 24. identify the change that made your code break $ git bisect start $ git bisect good v1.2 [marks v1.2 tag as good] $ git bisect bad master [marks current code as bad] [git will now present you with commits to test; each should be marked with ‘git bisect good’ or ‘git bisect bad’ until you arrive at the commit that broke] Saturday, November 13, 2010
  25. 25. work on experimental changes without breaking your stable code $ git checkout -b newfeature $ git branch [confirm you’re on the newfeature branch] [work on your new feature and commit as normal; commits will not touch the “master” code] Saturday, November 13, 2010
  26. 26. $ git pull --rebase [gets any changes others have made] $ git rebase master [do this often & resolve conflicts early if you’re working with others!] $ git checkout master $ git merge newfeature [merge your changes back into master] stay up to date with changes in the core code Saturday, November 13, 2010
  27. 27. $ git add --patch [choose which of your changes to add] $ git commit -v [see your diff when writing your commit message] $ git stash [stash your changes for now] $ git stash pop [restore your last stashed changes] $ git rebase -i master~10 [edit (!) the last 10 commits] more insanely useful things Saturday, November 13, 2010
  28. 28. Saturday, November 13, 2010
  29. 29. Saturday, November 13, 2010
  30. 30. Just use the command line. Saturday, November 13, 2010
  31. 31. Aboutthoseclients... Saturday, November 13, 2010
  32. 32. Step 1: Fire bad clients. Srsly. Saturday, November 13, 2010
  33. 33. Saturday, November 13, 2010
  34. 34. Step 2: Don’t ask for permission. $ mkdir newproject $ cd newproject $ git init Saturday, November 13, 2010
  35. 35. Step 3: Help clients see the value. Saturday, November 13, 2010
  36. 36. Github makes it stupid simple. Gettingstarted Saturday, November 13, 2010
  37. 37. Saturday, November 13, 2010
  38. 38. Saturday, November 13, 2010
  39. 39. Saturday, November 13, 2010
  40. 40. Saturday, November 13, 2010
  41. 41. Saturday, November 13, 2010
  42. 42. Saturday, November 13, 2010
  43. 43. rebeccamurphey.com @rmurphey http://pinboard.in/u:rmurphey/t:git/ http://pinboard.in/u:rmurphey/t:workflow/ Originally presented at indieconf 2010, Raleigh, N.C. Saturday, November 13, 2010

×