• Like
  • Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Retooling Your Workflow

  • 2,495 views
Uploaded 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 …

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.

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
No Downloads

Views

Total Views
2,495
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

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. Retooling Your Workflow Rebecca Murphey • @rmurphey Saturday, November 13, 2010
  • 2. [Note: Some slides have had content obscured for the sake of con dentiality. Sorry.] Saturday, November 13, 2010
  • 3. Or: Tools for measuring the quality of a client. Saturday, November 13, 2010
  • 4. Or: Tools for getting access to more exciting, better-paying work. Saturday, November 13, 2010
  • 5. Or: CYA. Saturday, November 13, 2010
  • 6. The Problem I learned to tolerate terribleness. Saturday, November 13, 2010
  • 7. The Lessons Saturday, November 13, 2010
  • 8. Email is evil A ticketing system brings sanity to client requests. Saturday, November 13, 2010
  • 9. Saturday, November 13, 2010
  • 10. Saturday, November 13, 2010
  • 11. Saturday, November 13, 2010
  • 12. Saturday, November 13, 2010
  • 13. Saturday, November 13, 2010
  • 14. Saturday, November 13, 2010
  • 15. Version control is non-negotiable Either the client needs to provide it, or I will. Saturday, November 13, 2010
  • 16. $ 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] store step-by-step snapshots of your work Saturday, November 13, 2010
  • 17. Saturday, November 13, 2010
  • 18. Saturday, November 13, 2010
  • 19. $ 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’] see what you’ve done Saturday, November 13, 2010
  • 20. Saturday, November 13, 2010
  • 21. Saturday, November 13, 2010
  • 22. [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 streamline the process of deploying new code to a server with tags Saturday, November 13, 2010
  • 23. [on your server] $ git checkout v1.3 [all hell breaks loose] $ git checkout v1.2 [now to figure out what broke] rapidly roll back bad code on the server Saturday, November 13, 2010
  • 24. $ 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] identify the change that made your code break Saturday, November 13, 2010
  • 25. $ 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] work on experimental changes without breaking your stable code Saturday, November 13, 2010
  • 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. $ 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. Saturday, November 13, 2010
  • 29. Saturday, November 13, 2010
  • 30. Just use the command line. Saturday, November 13, 2010
  • 31. About those clients ... Saturday, November 13, 2010
  • 32. Step 1: Fire bad clients. Srsly. Saturday, November 13, 2010
  • 33. Saturday, November 13, 2010
  • 34. $ mkdir newproject $ cd newproject $ git init Step 2: Don’t ask for permission. Saturday, November 13, 2010
  • 35. Step 3: Help clients see the value. Saturday, November 13, 2010
  • 36. Getting started Github makes it stupid simple. Saturday, November 13, 2010
  • 37. Saturday, November 13, 2010
  • 38. Saturday, November 13, 2010
  • 39. Saturday, November 13, 2010
  • 40. Saturday, November 13, 2010
  • 41. Saturday, November 13, 2010
  • 42. Saturday, November 13, 2010
  • 43. rebeccamurphey.com @rmurphey http://pinboard.in/u:rmurphey/t:git/ http://pinboard.in/u:rmurphey/t:work ow/ Originally presented at indieconf 2010, Raleigh, N.C. Saturday, November 13, 2010