On Wednesday, December 12, 2012 4:44:07 PM UTC+1, Bryan Migliorisi wrote: > Hey all, > > Just learning Git and I am trying to understand the best workflow for our > team. For arguments sake, assume we are using Github for > our private repositories and using Heroku for hosting. > > I'd like to have a workflow where our development team commits changes to > a development branch. Someone (likely me) will be responsible for cherry > picking commits from the development branch (or branches maybe?) and > pulling them into a QA branch which is then pushed to our Heroku QA > repository\app. > > Once QAed and approved, I'd like to pull (merge?) the entire QA branch > into the production branch and push that to our Heroku production > repository. > > > Some questions: > > 1. At a high level, does this make sense and is there a better way? > The goal is mostly to allow concurrent development while allowing us to > selectively deploy specific changes. > 2. Is it best to have separate repositories for each developer and > have them push changes, once complete, to the main development repo? Or > should everyone just commit their code to the main development repo? > 3. Related to above: Should each developer have a separate branch or a > separate repository? > 4. Are there any tools to facilitate a workflow like this? Obviously > command line is immensely powerful. Ive been using SourceTree > and liking it so far. Also hear Tower is great. GitHub for Mac(\Windows) > is pretty limiting. > > I've read a few blogs\articles describing some workflows similar to this > but I havent really been able to wrap my head around it entirely. Any > links would be appreciated. > > Thanks in advance! > > > Just a quick note:
There are two "famous" tools or approaches for this, although I guess most people end up evolving their own workflow. The first one is called git-flow<http://nvie.com/posts/a-successful-git-branching-model/>, and is somewhat rigorous, and comes with ready scripts<http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/> for managing the workflow. The second one is the Github Flow<http://scottchacon.com/2011/08/31/github-flow.html>, which is a lot simpler, but doesn't work so well for teams that have old-fashioned release processes and QA departments. Neither of these are *the right* *way* for you, but maybe they'll give you some ideas. --
