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 link<http://deans-avr-tutorials.googlecode.com/svn/trunk/ManagingLargeProjects/Output/ManagingLargeProjects.pdf> which *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 suggestions. 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. Alex 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
