Update HACKING with update git aliases.
Selecting to upgrade a service in the local charm upgrade inspector upgrades the services charm
Merge pull request #151 from mitechie/update-git-docs

- Update the fetch-pr alias per suggestion from Gary to add the +ref.
- Rename the juju-sync to sync-juju to start the trend of available sync-* commands
- Add a sync-trunk which will do a rebase from your develop branch.
- Update docs on how to keep your feature branch up to date based on the latest upstream trunk.
Ability to deploy units to specific machines.
Update push command for git 1.9
Merge pull request #154 from mitechie/update-push-docs
added tests for the local charm upgrade functionality
Merge pull request #152 from frankban/add-to-machine-spec

Ability to deploy units to specific machines.

Support ToMachineSpec in goenv backend 
ServiceDeploy and AddServiceUnits calls.

Also update the pyenv for compatibility.

Drive by fix to code indentation/style.

QA:

Ensure the sandbox mode works well:
- make prod;
- deploy a service, add units, check
  everything is fine.

Live test the functionality on an ec2
environment:
- juju bootstrap -e ec2 --upload-tools
- juju deploy -e ec2 juju-gui --to 0
- juju expose -e ec2 juju-gui
- juju set -e ec2 juju-gui juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git add-to-machine-spec"
- when the GUI is ready, log in, open the JS console;
- deploy a new service (e.g. mysql) as usual dragging the badge from
  the browser. This is done to ensure the usual way to deploy services
  from the GUI still works well: a new machine should be created to host
  mysql;
- add another unit to mysql using the inspector: at this point you should have
  mysql deploying to machines "1" and "2"
- using the console add a new machine, another new machine including an LXC
  container, and a new LXC on machine "1":
  app.env.addMachines([{}, {containerType: 'lxc'}, {containerType: 'lxc', parentId: '1'}]);
- use `juju status -e ec2` to ensure the new machines/containers have been 
  created: machine "3" and "4", containers "4/lxc/0" and "1/lxc/0"
- deploy wordpress to "1/lxc/0" by running the following:
  app.env.deploy('cs:precise/wordpress-21', 'wordpress', null, null, 1, null, '1/lxc/0');
- add another unit to wordpress, placing it on machine "3":
  app.env.add_unit('wordpress', 1, '3');
- define the following callback that will help visualizing
  the data returned by the API calls:
  var callback = function(data) {console.log(data)};
- ensure an error is returned when trying to deploy multiple units on
  the same machine:
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 3, null, '4/lxc/0', callback);
- deploy haproxy to machine "4" and container "4/lxc/0":
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 1, null, '4', callback);
  app.env.add_unit('ha', 1, '4/lxc/0');

Done, destroy your environment, thank you!
Merge pull request #153 from hatched/upgrade-from-local-charm

To QA
--------
**Use real env (ec2, lxc)**
- Deploy a local charm
- Drag the same local charm to the canvas, an inspector which gives you the option to upload or upgrade should come up
- Upload and deploy another version of the charm (so you now have two services with the same charm)
- Wait for both to come up.
- View the inspector for both services and take note of the charm url. One should be a higher version than the other.
- Drag the same local charm to the canvas and select a single service to upgrade.
- Wait 10s or so
- Click that services inspector and it should have a different charm url now.