{"thread":{"id":"16186","subject":"Looking for the perfect git workflow","startedAt":"2008-11-05T20:10:07Z","lastAt":"2008-11-05T20:10:07Z","messageCount":1,"participants":["Roderik van der Veer |Smartlounge|"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94993","messageId":"4911FD9F.9010103@smartlounge.be","threadId":"16186","inReplyTo":null,"subject":"Looking for the perfect git workflow","fromName":"Roderik van der Veer |Smartlounge|","fromEmail":"roderik.van.der.veer@smartlounge.be","sentAt":"2008-11-05T20:10:07Z","receivedAt":"2008-11-05T20:10:07Z","isPatch":false,"sender":{"key":"roderik.van.der.veer@smartlounge.be","avatar":null},"body":"Hello,\n\nI'm trying to work out the best way to use git in the workflow for our \nprojects. We have\nmigrated from CVS in 2007 and are happy with it, but we have a need for \na more structured\nway of working with our different repositories.\n\nLet me describe the project to begin with, we have developed a \njava+velocity based cms\nsystem, and all out client sites are based upon this cms. The CMS is in \nconstant\ndevelopment, so there are no set releases, only new features when a \ncustomer has a need\nfor it, or bugfixes. Our project structure, that we cannot changed for \nbackward\ncompatibility is something like this:\n\n   * project x\n         o src\n               + cms\n               + components\n                     # forum\n                     # blog\n                     # etc\n               + shop\n               + project x\n         o Webroot\n               + images\n               + html\n               + velocity\n                     # cms\n                     # components\n                           * forum\n                           * blog\n                           * etc\n                     # shop\n                     # project x\n\n\nWe have a git repository for the base cms system containing everything \nbut the \"project\nx\" folders and the html folder. This git repository contains the base \nfiles (database\ntransaction layer etc) but also global modules like the \"blog\" module. \nThe projects\nextend these base files to create the client's website, the project \nfiles are contained\nin folders different from the base folders. An added difficulty is that \nevery java source\nfolder, has a velocity template folder structure, so for the module \n\"blog\" there are two\nfolders \"blog\" in src and \"blog\" in webroot. The html folder in webroot \ncontains the html\nfiles and images created by a third party and are updated by a rsync \nscript from their\nserver (they cannot use git). So to summarise:\n\n   * project x\n         o src\n               + cms (BASE)\n               + components\n                     # forum (BASE - FORUM)\n                     # blog (BASE - BLOG)\n                     # etc (BASE - ETC)\n               + shop (BASE - SHOP)\n               + project x (PROJECT)\n         o Webroot\n               + images (BASE)\n               + html (THIRD PARTY)\n               + velocity\n                     # cms (BASE)\n                     # components\n                           * forum (BASE - FORUM)\n                           * blog (BASE - BLOG)\n                           * etc (BASE - ETC)\n                     # shop (BASE - SHOP)\n                     # project x (PROJECT)\n\n\nThe cvs and basic git workflow was:\n\nchanges from BASE went into the project like this: BASE -> a custom \nrsync script ->\nPROJECT\nchanges for BASE from PROJECT were merged back by hand, eighter in \nmaster, or in a\nfeature branch\n\nSince moving to git we started using the feature branches for big new \nfeatures, and just\nused master for bugfixes. We developped the client sites using the \nmaster branch combined\nwith some feature branches. The moment the site was live, the feature \nbranches were\nconsidered stable and supported, and were merged into master.\n\nSo, what's the problem,\n\n1. regressions, because to get a bugfix, you get stuffed with some new \nfeature or\nrefactoring. Just keeping everything as branches means you have a lot of \nwork to build a complete version for the project.\n2. merging back by hand is a pain, since you can't forget any templates etc.\n3. since BASE contains all the global, non site specific modules, every \nproject has the\nSHOP code, even if it isn't a webshop.\n\nWhat have we looked at:\n\n1. git submodules -> since every module has two folders, and we don't \nwant two git\nrepositories for one module\n\n2. A currently running experiment has an origin remote (the project repo \non our central\nserver) for it's master and some feature branches. And a remote to the \nBASE repo, with a\nchecked out branch for that specific project.\n\n   * PROJECT X\n         o BASE - remote\n               + project-x\n         o ORIGIN - remote\n               + master\n               + feature x\n               + feature y\n\nWhen we start the project x project, we merge the BASE/project-x branch \ninto\nORIGIN/master and start from there. This way we can cherry pick changes \nto BASE, and\ncontrol the flow from BASE/master to BASE/project-x and from \nBASE/project-x into\nORIGIN/master\n\nThis works fairly good except that plain \"git push\" wants to put the \nlocal version of master into\nBASE/master (and that is really not the way we want it) and it's bound \nto happen that someone forgets to add extra params to the command. And \nwe have no real way of dealing with problem number 3 (the modules)\n\nSo in short, i'm looking for some insight, to create a foolproof \nframework to deal with\nthis kind of setup.\n\nRegards,\nRoderik\n\n-- \n==========================================\nRoderik van der Veer\nroderik.van.der.veer@smartlounge.be\n==========================================\nSmartlounge\nJP Minckelersstraat 78\nB-3000 Leuven\ntel: +32 16 311 412\ngsm: +32 486 36 66 39\n==========================================\nhttp://www.smartlounge.be\n==========================================\ninternet application development & hosting\n"}]}