Although totally independent from Git itself, I think this is the point
where shared libraries come in to the picture.
For example, you may want to "outsource" the common work to a shared
library, and maybe add this library either as a compile time dependency, or
as a git-subtree; both would mean that you have to manage N+1 repository,
where N is the number of customers and +1 is your library.
On 25 Sep 2013 11:36, "Michael Weise" <michael.we...@ek-team.de> 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 to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
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.