git - Best workflow for software development with many release versions -

we changing our workflow git avoid maximum of errors , regressions...

i read one: http://nvie.com/posts/a-successful-git-branching-model/

to make short summary:

• the master branch has tag representing production version.
• the develop branch next release prepared. branch tests run every night. , branch nightly build.
• feature-something branch features next made, , merged @ end on develop branch. branch should in developers repositories only.
• fix-something branch hot fixes made, can merged on develop , master
• the release-1.2 branch next release prepared last fix , changes made. merged on master , development when ready production.

i it, seems there 1 or 2 things incompatible of our requirements:

• first, our software has clients on 1.0 version example , on 1.2. not migrating client 1.0 onto 1.2 simple fact not supporting unity 3.4 more on later version. of our clients still using it.

but now, imagine found bug in core of our product, , have fix every version. seems complicated this workflow without duplicating commits...

we thought like:

with new modified workflow when fixes applicable on every production branches, have merge onto every branch. why thought have branch main release version.

but workflow? cons of workflow? pros? think can bit confusing...

• the other point think not compatible workflow pull- request. want use pull-request system, is, when finishes feature or fixes bug, has make pull request on branches wants make work merged on it.

but wondering - as explained in article linked - if fact every branch features or bugs should on developer computer makes use of pull-request impossible? think have push branch on github before requesting pull-request, right?

finally, think workflow? fine small team of 4-10 developers? have suggestions make better? have better workflow?

so you'll have maintain 2 parallel stable branches. while git makes branching reasonably easy, maintaining parallel versions of software consumes significant resources. expect painful in case.

some general hints concerning scenario:

• estimate lifespan of 2 parallel stable branches. longer live, more effort cost in end.
• think how activity expect on of branches. in particular, 1.0 series occasional importand bug fix, or there significant development activity there. in latter case, should try keep both branches close each other possibly can.

i can imagine 2 variants:

• 1.0.x gets rare important bugfixes. then, develop branch should close 1.2 , merged in there on every 1.2 release, , can cherry-pick rare bugfixes directly 1.0 branch.

• 1.0.x gets significant features. should develop features on branch close 1.0.x. separate develop branch.

before embarking on overly complex branching model (which may confuse team), sure read this article.