> > I want to migrate a lot of project from CVS to GiT. 
> It's called Git or git, not GiT. 
I beg your pardon :)

> > I found cvs2git, which is working fine, but I'm confused about a few 
> > things... 
> > 
> > We are currently using CVS in a strange, but historic way. 
> > 
> > Let's take an specific example : I have a project called x. 
> > In my CVS repository, each file is tagged for each software revision, 
> > the file x/myfile.xml got 3 tags for 3 revisions. 
> > : 1.1 
> > : 1.2 
> > : 1.3 
> > 
> > Like this, we are able to work on V1.0.0.0 as V2.0.0.0 as V3.0.0.0. 
> > We just need to extract all files from this project corresponding to 
> > the wanted revision. 
> > This is all about working on new feature, debugging and maintenance. 
> > 
> > To compile, we have a server which checkout file for each revision. 
> > 
> > We want to take advantages of GiT, and implements devlopment, 
> > integration and production branch. 
> > 
> > I've read a lot of articles speaking about GiT, branching, tagging... 
> > but I can't find a real solution for that type of GiT workflow... 
> Well, it seems that you just doesn't *feel* how your workflow should 
> map to Git as you have no experience with Git yet. 
> If I understood your use case correctly, you have nothing which would 
> be somehow special to Git -- see below. 

> Is it possible to have theses 3 branches, and a sub branch for each 
> > package revision? 
> Using branches is just the only way you do this in Git as Git is about 
> branching ;-) 

The basic idea is that your code base evloves and at some point you 
> decide that its current state is mature enough to eventually produce 
> a new release after certain polishing and bug squashing. 
> Normally you fork a new branch at this point and name it something like 
> release-1.1.  You then can continue developing on the mainline branch 
> and do only bugfix commits on the release-1.1 branch (which can be 
> backported back to the mainline branch using `git cherry-pick`). You 
> can have any number of such release-X.Y branches in parallel, of course. 
> A classical essay on this approach is [1].  It contains nice pictures 
> so consider reading it.  Note that it's not the only possible workflow, 
> and at least you might adjust certain details if you decide to adopt it. 
OK, I understand, a way to use git in my case is to use branching for 
software release.
But how to set branch for development, integration and production in 
parallels of releases branch?

I abviously need to be able to work on any release of any packages at any 

Maybe you have already answered to me, and I apologize if it's the case, 
but I need some lights on it I guess :)


> > Do I need to use tags? With them I can't imagine to maintain like... 
> > 10 revisions of a project... 
> No, tags are (supposed to be) immovable and are used to mark certain 
> milestones.  Say, when you finally decide to cut a release out of the 
> tip of your release-1.1 branch, you might tag it as v1.1. 
> > What is exactly submodules? Can I use them for my workflow? 
> Submodules provide a way yo have several external Git repositories 
> being checked out along with your main repository, which is useful if 
> your project depends on other (external) projects. 
> Apparently, this feature has nothing to do with your workflow. 

Ok, I got it :)

> 1. http://nvie.com/posts/a-successful-git-branching-model/ 

I know this very helpful link.

Thank you very much for your help.

You said "you have nothing which would be somehow special to Git"
What do you mean exactly? Do  you have some others helpful tips for this 
kind of workflow?

Again, thank you :)

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.

Reply via email to