CODEWITHSUNDEEP
xcodegit
johnbakers
johnbakers

Reputation: 24771

Using one repository for multiple projects

I am new to git and while I can see the immense benefits of the branch/merge process on individual projects, it also seems to me that another useful application of Git is to use it for centralizing the core custom code and templates that you often use in all your projects, with each project starting off as its own branch.

For example I have a large set of custom code that is just a starting place that I use for all apps. If I tweak it here and there, or find bugs and fix them, I want that to replicate through all projects that use the code.

By working on tweaks in a separate branch off the master, then merging back to the master, and then merging the master with other branches that occupy separate projects, it would seem I can achieve this quite well.

Are there any major drawbacks to this approach to Git?

Also while I know that submodules exist, I prefer not to use them at this time since they are not natively supported in Xcode.

Upvotes: 1

Views: 2248

Answers (1)

vonbrand
vonbrand

Reputation: 11831

Several projects will tend to advance on their own terms. If you have all together on the same branch, you see intermingled commits, and there isn't any sense of history to be discerned. If you place each project on a separate branch, you'll have to jump from one to the other, and there won't be any advantage against separate git repositories (git is very lightweight!).

A DVCS does add overhead (if there are several repositories with the same contents, it certainly adds disk space; but that is dirt cheap nowadays...). It has the advantage that you can work anywhere, freely (no need to wait for a slow connection), and (at least with git) the operations are normally so fast that until you get used to it you have this lingering fear that you are being cheated and nothing has been done...

For development, the fact that branching and merging works and is cheap means experiments and exploration are encouraged. The fact that commits are instantaneous and use up very little space leads to microcommits (one logical change, even a minimal bugfix or typo, per commit), instead of "a morning worth of work" dumps. This makes history understandable, and tools like git bisect extremely useful.

I have a bunch of git repositories with stuff I want to preserve history on, but not necessarily ever share with anybody else. Some more important of that stuff I keep also in remote repositories (not much more than git and ssh at the other end, and a bit of discipline to push there now and then, are required) for backup. In that sense, I use git more as a local VCS, which also has the advantage that I can share with others ;-)

Upvotes: 1

Related Questions