Beginner's question on how to use git for multiple parallel versions

Hello all,

I’ve got a project that I want to do version management on with git but being a beginner in cvs/svn/dvcs etc. terminology I don’t know yet how to set it up. My project needs to exist as several parallel copies, i.e. there is a “main version” in which I do my development but it needs to end up being available as a couple of different configurations. For instance, say there is a file table.xml then this needs to contain different rows for versions A and B. Likewise, a file process.bpel needs to be named identical for each version but contain different content depending on whether it is distributed as version A or version B. Any changes made in non-version specific files should be visible in all copies, but changes made to version-specific files need to remain isolated to that particular version.

I read about branching, merging, rebasing and cherry-picking commits but I don’t get it yet. Can anyone enlighten me on how I should approach this in a way that I can maintain easily throughout future development for my situation?

Thanks in advance for any pointers,

Best,

Chris

On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:

What you are asking for is this, I think:

% git checkout A % cat table.xml <table A> % echo "<table A v2>" > table.xml % git commit -a -m "fix table on Branch A"

% git checkout B % cat table.xml <table B> % echo "<table B v2>" > table.xml % git commit -a -m "fix table on Branch B"

% git checkout master % cat table.xml <non-version-specific table info> % cat process.bpel main line process stuff % echo "add more process stuff" >> process.bpel % git commit -a -m "fix process stuff on mainline"

% git checkout A % git merge master % cat process.bpel main line process stuff add more process stuff

% git checkout B % git merge master % cat process.bpel main line process stuff add more process stuff

Is that not it?

Bill

Dear Bill,

Thanks for your prompt reply. It may very well be exactly what I need, but I'm afraid that I don't understand the syntax just yet (am still in the phase orienting on what version management is and how it should be set up).

Could you please add to your answer whether I am using branches or another git technique (terminology?) and whether these are instructions that I can use to commit a change once the system has already been set up or if these actually are the instructions for defining the multiplicity of my project versions?

Sorry for the newbie-ness and thanks in advance,

Best,

Chris

-----Original Message-----
From: Bill Lear [mailto:rael@zopyra.com] 
Sent: maandag 4 januari 2010 14:29
To: Christian C. Schouten
Cc: git@vger.kernel.org
Subject: Re: Beginner's question on how to use git for multiple parallel
versions

On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:

What you are asking for is this, I think:

% git checkout A % cat table.xml <table A> % echo "<table A v2>" > table.xml % git commit -a -m "fix table on Branch A"

% git checkout B % cat table.xml <table B> % echo "<table B v2>" > table.xml % git commit -a -m "fix table on Branch B"

% git checkout master % cat table.xml <non-version-specific table info> % cat process.bpel main line process stuff % echo "add more process stuff" >> process.bpel % git commit -a -m "fix process stuff on mainline"

% git checkout A % git merge master % cat process.bpel main line process stuff add more process stuff

% git checkout B % git merge master % cat process.bpel main line process stuff add more process stuff

Is that not it?

Bill

On Monday, January 4, 2010 at 14:35:25 (+0100) Christian C. Schouten writes:

In my example, I used branches, but did not show how to set them up. Here is the complete example, complete with repository and branch creation; you would start your project here:

# Set up repo and add first file to main branch: % mkdir my_project % cd my_project % git init % echo "main line process stuff" > process.bpel % git add process.bpel % echo "<non-version-specific table info>" > table.xml % git add table.xml % git commit -a -m "First commit on master branch"

# Create branch A and branch B: % git branch A % git branch B

# Modify file on branch A: % git checkout A % echo "<table A>" > table.xml % git commit -a -m "Modify table on Branch A"

# Modify file on branch B: % git checkout B % echo "<table B>" > table.xml % git commit -a -m "Modify table on Branch B"

# Now go back to master and make some changes on common file: % git checkout master % cat process.bpel main line process stuff % echo "add more process stuff" >> process.bpel % git commit -a -m "fix process stuff on master"

# Now go to branch A and pull in the common file: % git checkout A % git merge master % cat process.bpel main line process stuff add more process stuff

# Now go to branch B and pull in the common file: % git checkout B % git merge master % cat process.bpel main line process stuff add more process stuff

That should be just about all you need.

Bill

Hi,

On Mon, Jan 4, 2010 at 2:29 PM, Christian C. Schouten <info@zark3.net> wrote:

One way to achieve that is to use branches. You create a mainline branch that will contain what is common for all versions, and then create a few specific branches from it. Each branch will contain their own files, as well as modifications to some common files if it is necessary.

Changes that a common to all branches should be committed to the mainline, which is merged to each version specific branch.

Git allows to quickly switch between branches, so you stay in all worktree all the time. Moreover, if you made modifications to some file on branchA but then realized that it should be commit to another branch, you can switch to another branch as usual as long as the modified files are the same on both branches. (If it is not the case, you can use git stash).

Dmitry