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 
sentences :)

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?
> Regards
> Michael

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

Reply via email to