I've just started to work on a software project with lots of "dirty" code
with very little to no management, no bug tracking, no documenatition at
all. As one of many actions, I decided it would be a good idea to use a
version control system and git looks like a suitable choice.
Some background info about myself: I'm an electrical engineer, have done
some programming here and there, but this is my first big "real" software
project. I do know stuff about hardware, have compiled plenty of programs
from source, BUT I'm not familiar with concepts that "real programmers" ;-)
know about, so I'll be thankful for some hints. I've never used a version
control system before (except for downloading, e.g. "git clone ...").
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
I wonder if I can solve part of the problem with version control:
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
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".
What do you recommend? Is there another approach worth considering?
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
For more options, visit https://groups.google.com/groups/opt_out.