[quote=“ThomasM”]I’m new to Git and my first ideas are a clone of JUCE (master) and my changes (e.g. modified Introjucer or the Jucer) in branches.
When I update the master (fetch and rebase), I can merge the master to my branches. The common way is, to make
a branch, try it and than merge it with the master.
The idea is, to have every time a clean (or clone) version of JUCE.
Good way, bad way?[/quote]
So you are keeping the unmodified JUCE repository in the “master” branch of your local JUCE repository? You don’t need to fetch and rebase, you can simply use pull. If you have your own branches with modifications to JUCE, then what you want to do after a pull to master is a rebase of your branch against the master branch. This way it will always look like your changes are placed on top of the tip, and all JUCE merges will be fast-forwards.
Yes. You use git-subtree to make the JUCE repository part of your repository. This way you only have to maintain one repository instead of two (or more). When you bring JUCE in this way, you can make changes to the JUCE source tree as if they were part of your own repository (actually, they are). When you want to bring JUCE up to date you split the JUCE subtree to a separate branch, then rebase that branch against the JUCE master, and finally use git-subtree pull to bring it back into your mainline (I use the --squash option).
If you look at the repositories in my signature you will see they are all totally self contained, including JUCE and VFLib.