Jason Garber wrote:
Hello, Time is valuable, so any of it is appreciated. I'm looking for sound advice on a good strategy for maximizing git's branching and merging capabilities to assist us in frequent web-app deployments. -- I am running a project (in git) that has ~20,000 source files and several full-time developers making changes constantly. The project is a web-app, so the files are a mix of textual source code and (usually) small binary files. We were using Subversion for some time, but eventually the deficiencies (like "svn status == 90 seconds" and no merge tracking) caused me to look for a better solution. After a lot of research, I ended up here, and we are in the process of moving all of our projects to git. Thanks, by the way! We have always maintained three copies of each project - [Development, Preview, Production]. Changes were typically made in Development sites and tested. Then (manually) copied to the Preview sites and tested. Finally, they would be manually copied to the Production site. It becomes very difficult to tell (manually) who changed what line of what file for each task that needs to be moved into Production. Some tasks are long-running, some are short, but in general, it's a mess. This is quite different from traditional software development where releases are done on a more "predictable" basis. Unfortunately in our case, releases are done on a sub-daily basis (yes, I'm working on that). We need a lot of agility in whatever strategy we choose. -- Here are some requirements: - Separate change-sets. Keep track of the changes introduced by each task separately. - Have changeset ABC stay in the Preview level for a variable amount of time. - Create, Preview, and move to Production changeset DEF while changeset ABC sits in the Preview level.
git will handle that for you.
- Developer sanity :)
Can't help you there, although lots of rest and relaxation usually helps ;-)
Here are some intents: - To maintain a branch called "Production" which represents what is in production - To maintain a branch called "Preview" which represents what is being previewed
Sounds sensible, and seems similar to what Junio's doing with the official git repo. I'd suggest you skip using "Development" branch though, and implement features on topic branches instead. Branching is ridiculously cheap in git, and merging branches is really fast. Doing it this way will make it a lot more convenient for you when trying out separate features, as you'll have all the related commits already aligned and separate from other development. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - 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
