gistfile1.txt

== 0. Create and checkout local development branch

You've probably done this already.

    git checkout master                             # now on master
    git checkout -b development origin/development  # track remote dev branch

== 1. Adding features for bug 12000

This is optional, but highly encouraged. You can just develop right on your
development branch. Branching for each feature (or bug) just means you have
a bit more flexibility (eg, working on multiple features at a time).

    git checkout development              # now on development
    git checkout -b 12000                 # branch from development for bug
    [edit & commit]
    git checkout development && git pull  # pull latest on dev from github
    git rebase development 12000          # rebase our changes on top of dev
                                          # this automatically checks out 12000
    git checkout development
    git merge 12000                       # should be a fast-forward
    git push                              # pushes dev branch to github

== 2. Deploy to staging

  The staging environment is the deploy of the development branch. It contains
  new features and fixes that aren't time critical. 95% of the time this is what
  you want.

    cap staging deploy    # deploys development branch

== 3a. Port development changes to master

  When changes from the development branch have been QA'd and are production
  ready, it's time to merge them into master.

    git co master
    git merge development   # should be a fast-forward
    git merge bb51d2        # alternatively, if there are recent changes to dev
                            # that you don't want in prod, just pick the commit
                            # you want. eg, the last staged & tested version

== 3b. Hot-fix to production (master branch)

  If you've got a critical fix that needs to be pushed to production without
  waiting for all the changes in staging to go live, hot-fix directly off the
  master branch.

    git co master
    [edit & commit]
    git push                  # push master to github
    git checkout development
    git merge master          # port changes into dev branch. DO NOT REBASE.

4. Deploy to prerelease

    Prerelease is a deploy of the master branch. If you've just merged things
    from development, you'll want to deploy to prerelease to sanity-check the
    changes before they go to prod. You'll also do this when you've hot-fixed
    something on master and want to check it before it goes to production.

    cap prerelease deploy   # deploys master branch

5. Deploy to production

  Once master has been checked in the prerelease environment, it can be deployed
  out to production. We tag so that we can keep track of the last deployed
  release.

    git checkout master
    git tag '2009-03-03'    # tag for release
    git push --tags         # push your tag to github
    cap production deploy