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.0.0.0R : 1.1 > 2.0.0.0R : 1.2 > 3.0.0.0R : 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.
