On Tue, 5 Feb 2013 04:33:25 -0800 (PST)
Jacques Knipper <jacques.knip...@gmail.com> wrote:

> I want to migrate a lot of project from CVS to GiT.

It's called Git or git, not GiT.

> 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.

> 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.

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

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