HI, > Well, you wouldn't be cherry picking from develop into master. So everything in dev must work and be in a 100% working state in order to make a release? That means we need to somehow veto changes in feature branches before merging them with dev? So if we were to do this cheery picking people changes from dev would rarely occur (if at all), you want to be merging full branches if possible.
> I get confused w/ this one, will get back to you on this one. :) I's guess hat you would want to keep the history. I think using this option may make more sense in a more commercial/less open project in that you may not want the internal developers commit history to be part of the source code release but have a more succinct "this feature was added" style history? But I really don't know enough about it to know. > However, before a release branch is killed off you MUST tag it. So to apply a patch to a previous you would branch a tag, apply the needed fix, make another release and tag it. You would then merge the fix back into dev and delete the branch. What if changes in dev meant that your fix couldn't be merged I assume you would then need to keep the branch around until it was no longer used/supported? Thanks, Justin
