Hi Alex, thanks for the explainations. I maybe misunderstood the way rebase works, so thank you for clarifying.
I did have a look into the git documentation already (brilliant!), but I reached a point where it doesn't cover my particular case, so I decided to ask on the mailing list / group where people with experience could do that. There have been a lot of hints to diffenrent documentation, so I'll work my way through it. While I still have no idea on how exactly to use git with our project, I now better understand how git works and what is technically possible. Cheers Michael On Wed, 25 Sep 2013 05:43:09 -0700 (PDT) Alex Lewis <alex.lewis...@gmail.com> wrote: > Hi Michael, > No problem. Yes rebase *or merge*. I'll add an explanation here for both, > apologies if you already know the difference. > > Rebase: Replay one branch on top of another. > Merge: Take the commits from each branch and combine them to form a new > commit. > > E.g. > Before... > m > o---o---o---o > \--*---* > b > > Rebase: > m > o---o---o---o > \---*---* > b > Or will often be displayed in tools as > m b > o---o---o---o---*---* > > If you wanted the changes on the branch to be included in the history of > master you will still need to merge (which would be a fast-forward merge). > > Merge : > m > o---o---o---o---# > \--*---*------/ > b > > So at "#" master will now include the changes in the branch *combined* with > the code on master. > > The Git Documentation <http://git-scm.com/documentation> is very good at > explaining this and the rest of Git. Also you may want to try this > interactive guide/demo <http://pcottle.github.io/learnGitBranching> as a > way to learn the git commands and see their effect visually (and pretty :) > I thoroughly recommend looking at both, maybe the Git docs first followed > by the interactive guide. > > HTH > > Cheers, > Alex > > On Wednesday, 25 September 2013 13:23:56 UTC+1, Michael Weise wrote: > > > > Hi Alex, > > > > thanks for your quick and helpful answer. > > > > I was just going to ask some question on how exactly to work with "branch" > > and "diff" ... > > ... and then David already gave the answer and added the missing > > puzzle-piece: "rebase" :-) > > > > Thanks a lot guys, this was exactly the kind of information I was looking > > for! > > > > Michael > > > > > > Am Mittwoch, 25. September 2013 12:16:33 UTC+2 schrieb Alex Lewis: > >> > >> 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. -- Michael Weise <michael.we...@ek-team.de> -- 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.
