The first thing I'd like to say is nice one for considering VCS from day
one, even many "real programmers" have not considered it up front. As for
your choice of Git, I don't think you'll regret it :)
In short I think the answer is sadly a bit of a) and b) and that's the art
of writing good software. I don't know C well enough to know how easy or
achievable this is but if you can aim for something where you can
compartmentalise (modularise) functionality be it customer specific or
agnostic. I found this
*might* be useful on how to do that. All of this would be on your "master"
branch regardless of whether it was common or customer specific. Hopefully
you can then just have various build scripts that will combine those
modules into customer specific builds. Your branches in this case would be
used to apply bug fixes, patches, etc. to a specific release of the
software. E.g. You couldn't give the customer the latest build of the
software (Version 2.1.2) including the fix you've needed to apply as it
includes new features, changes to API's, etc. It needs to be version 1.4.1
+ bug fix (I.e. soon to be 1.4.2, or 1.4.1_1 depending on how you want to
number your releases). In this case you would branch from the 1.4.1
release, apply your fix and release from that branch. That branch would
live around for as long as a customer is using that version and any
subsequent bug fixes, enhancements, etc. would be done on that branch. If
those changes apply to the latest version of the code as well you could
merge those changes into master.
There are *many* ways this can be achieved, all with pros and cons. Like I
say I don't know enough about C to suggest whether #ifdefs are the "right"
way to modularise the code and I'm sure people will respond with other
One thing I will say is try to always consider whether you're trying to use
Git for versioning or trying to compensate for the design of the code or
the way in which it is built. So having a branch per customer is probably
airing towards trying to compensate for the structure of the code, not
about a good versioning process. That probably sounds very vague and
useless, I'm just finding it very difficult to put it into succinct
Hope this helps.
On Wednesday, 25 September 2013 10:36:39 UTC+1, Michael Weise wrote:
> Hello folks,
> 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
> to read.
> 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 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".
> 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.