Joseph Huttner <jhuttner@xxxxxxxxxxxx> writes: > I am in search of a new Git workflow. Previously, my team was > essentially using using gitflow by Vincent Driessen (nvie). It worked > very well, but the needs of project have changed, so here are the new > requirements: > > 1. A "Beta" environment that contains stable code for all features > being considered for "Production." > 2. A "Production" environment. Rock-solid, well-tested code only. > > The catch is that after a feature has been stomped on in Beta, it > **may** go to Production, but only if Product Managers still think it is > an important feature. In other words, there is no guarantee that a > feature in Beta will ever make it to Production. It may be axed > completely, in which case it would never get to Production and would be > taken out of Beta. Also, there is no guarantee that features that do > make it to Production will go in in the order that they went in to Beta. Is it just me, or does the above sound exactly like how git itself is managed, when "Beta" and "Production" are read as "next" and "master"? > A few notes that may matter: > > a) Six developers on team and growing. Will be 9 by the summer. 120 active developers on team for the last 6 months, among which 35 people have more than 5 commits. > b) Codebase is 110K in-house lines. 157k lines counting only '*.[ch]' files. > c) Typically, a feature is worked on by 1-3 developers at a time. Total > development work on a feature can be anywhere from two hours to two > months. The median is about two weeks. Quite similar. > d) Currently, per week, about 15 bug reports come in for today's > equivalent of the Beta branch. Git being a volunteer project it is probably harder to compare; we have busy weeks and quiet weeks. For the past 6 months, I count 230 merges to the 'mater' that merges fully cooked topics, so that is roughly 8-9 topics a week. > Ideally, using the new workflow, releases to Beta would be a few times > per week. Releases to Production would be once per month. This is the > same as our current release cycle. I do merges to 'next' roughly once per day (sometimes twice a day, sometimes once every other day), and 'master' roughly twice a week. All of the above makes me suspect that imitating what I do and other people work with me might be one possible approach. -- 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