On 25 September 2013 19:36, Michael Weise <michael.we...@ek-team.de> wrote:
> I decided it would be a good idea to use a
> version control system and git looks like a suitable choice.

Yes and yes! I am an EE and write some C.

I agree with Alex's comments. It might be much cleaner to handle some of the
customer difference logic in the executable C, rather than conditional
compiles. You could implement a set of meaningful flags, and use
combinations of those flags to describe the requirements for each customer.
The rest of my message ignores this issue; it is intended to encourage you
that git is a useful tool to help you try all solution approaches, including
this one.

> One problem I'm facing is that we have different customers who get different
> versions of our program (programming language is C). Currently these
> versions are implemented with lots of #ifdefs that make the code hard to
> read.
> I wonder if I can solve part of the problem with version control:

Yes, git is suitable for this.

> Let's say I have source code for customer A that works fine. Now customer B
> wants the same program, but with subtle changes in different places of the
> code.
> How would I handle that?
> a) One approach is to create a second branch for customer B and apply the
> changes. But when I have to make changes that apply to both (or lets say
> n=12) branches, how would I do that?
> This would lead to a situation, where I have (at least) 12 branches for 12
> customers, which might diverge more and more over time (not generally a
> problem, but maybe incompatible to the idea behind version control?).
> b) Another approach is to keep one codebase with all the #ifdefs and use
> version control "in the classical way".

Your options a) and b) are not mutually exclusive, I'd encourage doing both,
in one git repository. git is a good tool for managing both alongside one

I would start by putting the existing code into git [your option b) ] and then
use git to manage your experiments with moving towards a) at your own pace.

Assuming that most of the code is used for all customers, my approach would
be first from the existing code to create a 'clean' branch with no
customer #ifdefs.
Then create another code corresponding to the effect of the #ifdefs only for
customer B. The diff between that code and the 'clean' branch would then
become branch 'B' off the tip of 'clean'. Later changes just for customer B
will be stored in branch 'B'.

When necessary you can make improvements on the 'clean' branch, and
then "rebase" any customer branches to branch off whatever point in
'clean' that is necessary to pick up those changes.

git can diff between branches, and between commits, so you can always see
the diffs, and cherry pick those diffs to other branches (customer or 'clean')
wherever they might be needed.

My favorite git tip, because it took me far too long to understand
this: branches
are not code, just pointers to code. Whenever you want to do anything you are
not sure of to a branch, don't stress, simply duplicate the branch
(not the code,
you just create another pointer to the same code) and manipulate that one. If
something unexpected happens, the original is unchanged as a fallback.
When you get the desired result, just delete the fallback.

It took me some time to get comfortable with git. Now that I am, I find it
indispensable. I recommend the graphical tools, and doing lots of non-critical
experiments after making a safety copy of the .git directory somewhere.

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