Committing to two remote projects from Git.

Question

I have a project in Codeigniter, managed via Git and Github, that consists of my 'boilerplate' customizations and libraries (like a centralized Render library) that I use for all of my CI projects - let's call that 'Baseline'.

At the same time that I'm developing and refining the Baseline CI project, I'm also developing the current client project, which we'll call 'Client'.

My question is - what's the most efficient way to develop both the Baseline project and the client project simultaneously? For example, I may create a new controller and model in the Client project, but then add new helpers, some generic views and add to a couple of the libraries that I think need to be added to Baseline. Do I need to perform two commits, one for the Baseline (and push that to the remote Baseline repo), then commit again for the Client project?

I've been trying to figure out how to use submodules or branching to accomplish the same thing, but submodules seem to require their own directory structure in Git, and with branching I'm not sure how it would work.

Help?

Answer 1

Since I'm guessing the separate-directory-structures setup that submodules require is no-go for you, here's what I'd suggest instead:

1. Have one repository (A) that is your "baseline" project. Do all of your work on the baseline in that repository, and commit it there.

2. Clone that repository to another, (B), and do all of your work for the client project there. Keep (A) as a remote (if you git clone (A), it'll be set as origin automatically; you could add the github remote as github instead of origin).

3. Then, when you make updates to the baseline (A) repository, commit them to (A), and then use git pull to pull them from (A) to (B). (Never push from (B) to (A), since you don't want client code in the baseline repo.)

So yes, you will need to commit your baseline updates and your client updates separately, but you won't have to commit the same code twice.

Answer 2

I would recommend using branches or submodules.

With branches, you would have a baseline branch and a client branch. Whenever you switch to client after updating baseline, merge baseline into client.

With submodules, either repository could be the top-level module, with the other as its child. Both layouts make some logical sense (with baseline on top, client depends on it and is therefore a child; with client on top, it uses baseline as a library, so that should be the child; it's up to you).

I would recommend the branching, though.