Thanks, Stephen. I guess I'm looking for more input on the advantages and disadvantages of using a QA and production branch vs just doing everything out of master. Trying to go through the following: http://news.ycombinator.com/item?id=1617425 scottchacon.com/2011/08/31/github-flow.html We have some weeks where we release very frequently and some weeks where we release only once a week and have to do production fixes in the meantime. Sure other people have similar experiences. On Thu, Dec 1, 2011 at 1:55 PM, Stephen Bash <bash@xxxxxxxxxxx> wrote: > ----- Original Message ----- >> From: "bradford" <fingermark@xxxxxxxxx> >> To: git@xxxxxxxxxxxxxxx >> Sent: Thursday, December 1, 2011 1:26:10 PM >> Subject: Workflow Recommendation - Probably your 1000th >> >> You guys probably receive a ton of workflow related questions. I'm >> trying to convert from svn to git. In order to complete, I would >> like to be able to provide a workflow to our team. We typically go >> from dev -> qa -> production (Java and Rails projects). The problem >> is that sometimes QA can get backed up and we'll need to release >> something to production while QA is doing their thing. What is a >> good workflow? I would like to not use git-flow, because it's another >> tool. > > Hey wow... I read that Driessen's workflow post [1] a long time ago, but hadn't run into the git-flow tools until a few days ago. Guess I was just oblivious... Anyway, if it's any consolation, my company runs a model very much inspired by Driessen's post without using git-flow itself. > > [1] http://nvie.com/posts/a-successful-git-branching-model/ > >> I've read suggestions to use environment branches (master, >> staging, production). I've also read not to do this and just use >> master, tagging your production releases. How well would our setup, >> where things can get backed up, work with the latter? Are there any >> alternative suggestions? > > In our workflow we flip Driessen's model on its head. master is the newest code, while we branch off maintenance branches just before each release. We tag each release so it's easy to identify which versions in the field contain a given bug or fix (multiple minor versions come off a single maintenance branch). Our QA guys follow the maintenance branches (they're relatively stable). We recently had to do a hot-fix release which I think would be similar to your "release to production". Basically we found the last commit on the maintenance branch that was well tested, created a new branch from there, did the hot fix, QA did some real fast testing (sounds like you'd skip this step), and we shipped that. As always that hot-fix release gets tagged, so in the future we can still reference that particular build (and in this case the branch merged back into the maintenance branch -- we've had other situations where the branch was simply deleted after tagging). > > In the grand scheme of things our model isn't that different than Driessen's; we just name the branches differently. Commits go on the oldest branch that's safe for them, and then everything merges to the newer branches. Tags provide easy reference for where on a given branch a release came from. > > Hope that helps. > > Stephen -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html