If you want to keep your process relatively similar then I think it might look something like...
development (repo) - master (<=> trunk) - branches from master. - tags on master. de (repo) - master (<=> trunk) - branches from master (if necessary, probably a good practice to create a branch when merging from development repo) - tags on master. etc. The *de* repo would have *development* repo as a remote. So the equivalent to the process you outlined would be... In *de*: 1. git remote add development ssh://user@host:port/path/development.git 2. git fetch development <tag> (you can use tab-complete to give you list of tags) 3. git checkout -b dev-<tag>-merge FETCH_HEAD 4. <sort out the issues>, *git commit* to finish off the changes. 5. git checkout master 6. git merge dev-<tag>-merge 7. <fix any conflicts> 8. git branch -d dev-<tag>-merge (delete the branch used to merge from * development* as you don't need it any more). 9. git tag -a <de_tag> Or something along those lines I think, doing this off the top of my head :) Others might be able to something better. HTH Alex On Tuesday, 3 September 2013 06:40:55 UTC+1, Sascha Egerer wrote: > > Hi, > > we are currenlty planning to migrate a big project from SVN to GIT. > The project in rolled out to multiple countries (currently about 15) and > each country is based on the "master" but has slight modifications. It's > not possible to localize everthing. > So our current SVN setup looks like this: > > SVN > - master > - trunk > - branches > - feature-111-foo-bar > - bugfix-222-foo-bar > - hotfix-333-foo-bar > - tags > - 1.0.0 > - 1.1.0 > - 1.1.1 > - 1.2.0 > - 1.2.1 > - de > - trunk > - branches > - trags > - 1.0.0 > - 1.1.0 > - 1.1.1 > - 1.2.1 > - us > - trunk > - branches > - trags > - 1.0.0 > - 1.2.1 > > The workflow is the following: > Development is completely done in the master repository. > If a country says "hey version 1.1.0 look good for us. we want to roll > this out in our country" we are merging the tag into the country > repository. After the merge some required changes > are also commited to the trunk. After we have finished the country > adjusted a tag will be created for the country. > So there is no real development in the country based repositories. And we > do just merged the requested tags into the countries. > > The question is now what is the best way to do this in git. > 1. Create a branch for each country in the origin repository > - then merge "master tags" into the country branch and create a "country > tag" > 2. Create a own git repository for each country that is added as remote > - pull origin tags and merge them into the country repo. then merge the > tag and create a tag in the country repo > > What would you suggest? Do you have similar setups? > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
