Sounds good. The only problem being I find a bug in version C. I fix it in version C, now I want to merge that change back to the master and then out to A,B and then D. I'm still reading my Git book but I'm thinking of doing it this way: Master has it's own repository. Each version has it's own repository that is created by cloning the Master and then removing all the files that are not specific removed from the repository. When changes are made to the master then simply copy all the non-specific files to each of the versions. Then I can run my unit/functional tests agains each version and if they all pass - deploy. Jez. On 2 Mar 2010, at 13:16, Michael J Gruber wrote: > Jez Caudle venit, vidit, dixit 02.03.2010 13:06: >> Hi I'm new to Git and I've read the manual and tried my best to >> understand it. >> >> I have a project that is going to have many versions, all the same >> except for the config file, the unit/functional tests and some >> display information. >> >> I have seen that I can create branches and then merge them. I >> wondered if I could create a branch, change the config file >> information and then decree that the config file in the new branch is >> not merged. >> >> I read about sub modules but they didn't seam relevant. >> >> Am I barking up the wrong tree here? > > You're fellow dogs may need more details in order to decide that ;) > > In general, I would recommend one branch (be it master) for changes > which apply to all clients (I guess that's what you mean by "versions, > all the same except..."), and one branch each for specific changes (to > config etc.). > > Then just make sure to merge in the right direction, i.e. merge the > general, common branch into the specific ones. > > Cheers, > Michael -- 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