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

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

[Christian C. Schouten]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

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

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

[Bill Lear]

On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:
>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.

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

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

[Christian C. Schouten]

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

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

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

[Bill Lear]

On Monday, January 4, 2010 at 14:35:25 (+0100) Christian C. Schouten writes:
>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?

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

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

[Dmitry Potapov]

Hi,

On Mon, Jan 4, 2010 at 2:29 PM, Christian C. Schouten <info@zark3.net> wrote:
>
> I&#8217;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&#8217;t know yet how to set it up.
> My project needs to exist as several parallel copies, i.e. there is a &#8220;main version&#8221; in
> which I do my development but it needs to end up being available as a couple of different
> configurations.

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