Retooling Your Workflow

Retooling Your Workflow Rebecca Murphey • @rmurphey Saturday, November 13, 2010

[Note: Some slides have had content obscured for the sake of con dentiality. Sorry.] Saturday, November 13, 2010

Or: Tools for measuring the quality of a client. Saturday, November 13, 2010

Or: Tools for getting access to more exciting, better-paying work. Saturday, November 13, 2010

Or: CYA. Saturday, November 13, 2010

The Problem I learned to tolerate terribleness. Saturday, November 13, 2010

The Lessons Saturday, November 13, 2010

Email is evil A ticketing system brings sanity to client requests. Saturday, November 13, 2010

Saturday, November 13, 2010

Version control is non-negotiable Either the client needs to provide it, or I will. Saturday, November 13, 2010

$ 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

$ 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

[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

[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

$ 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

$ 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

$ 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

$ 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

Just use the command line. Saturday, November 13, 2010

About those clients ... Saturday, November 13, 2010

Step 1: Fire bad clients. Srsly. Saturday, November 13, 2010

$ mkdir newproject $ cd newproject $ git init Step 2: Don’t ask for permission. Saturday, November 13, 2010

Step 3: Help clients see the value. Saturday, November 13, 2010

Getting started Github makes it stupid simple. Saturday, November 13, 2010

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

http://coderwall.com	292
http://speakerrate.com	59
http://lanyrd.com	12
http://www.slideshare.net	2

Retooling Your Workflow

by Rebecca Murphey on Nov 13, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 365

Statistics

Retooling Your Workflow — Presentation Transcript