git workflow

gistfile1.txt

### Git Workflow

Answering the following questions helps you choose a branch workflow:

* Where do important phases of development occur?
* How can you identify (and backport) groups of related change?
* Do you have work which often needs to be updated in multiple distinct long-lived branches?
* What happens when emergency patches are required?
* What should a branch for a particular purpose (including user-tactical) be named?
* What is the lifecycle of a branch?

### Scenarios

## 4 developers, 4 features - ready to test

D1 is working on F1, D2 is working on F2 ... D being developer, F being feature

This creates 4 working feature branches, potentially 4 feature staging servers, 
    1 staging server, and 1 production server

This could look like this:

  * D1 is ready to stage their code @ 9am MST
  * D2 is ready to stage their code @ 9:10am MST
  * D3 is ready to stage their code @ 9:15am MST
  * No need to point out D4..(infinity)


## Emergency Patch time

We need to do a bug fix on master - we need to get this onto master fast,
    and the new patch can only be HEAD+PATCH

* This needs to be staged and tested
* This needs to be rebased back into everyone's feature branches + stagings

## Deployment breaks production

It happens, how does our branching scheme help us here? What the fuck do we do?


## Iteration scheduling and releases via branch merges

A deployment to master shouldn't just be pushing master to a server. It will
    quickly need to be more complex to solve our problems. We also have
    rollbacks to deal with.

mas.....

reference: http://sethrobertson.github.io/GitBestPractices/#workflow